Integrating device identity into permissioning framework of blockchain

Abstract

A computer-implemented method for configuring a blockchain network, a computer program product for integrating a set of device identities into a permissioned framework of a blockchain network, and a blockchain network. One embodiment can include registering a device at a delineation node of the blockchain network, creating, by a processor of the delineation node, a profile of the device based on the registration, and executing, by the processor of the delineation node, a pass-through service for the device. The registration can include receiving, by a network interface, an unalterable device identity from the device.

Description

Background Technology

[0001] This disclosure relates to the configuration and management of blockchain networks; and more specifically, to the configuration and management of “Internet of Things” (IoT) devices in blockchain networks.

[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 extremely complex devices. Today's computer systems typically consist of a combination of complex hardware and software components, applications, operating systems, processors, buses, memory, input / output devices, and more. Advances in semiconductor processing and computer architecture have driven ever-increasing performance, and even more advanced computer software has evolved to utilize these capabilities for even higher performance, resulting in computer systems today being far more powerful than they were just a few years ago.

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

[0004] According to embodiments of this disclosure, a computer-implemented method for configuring a blockchain network is provided. One embodiment may include registering a device on a mapping node of the blockchain network, having a processor of the mapping node create a device profile based on the registration, and having the processor of the mapping node perform a pass-through service for the device. The registration may include receiving an immutable device identifier from the device via a network interface.

[0005] According to embodiments of this disclosure, a computer program product is provided for integrating a device identifier into a permissioned framework of a blockchain network. The computer program product may include a computer-readable storage medium having program instructions embodied therein. The program instructions enable a processor to provide pass-through security services through nodes, register the device as a registered node on the blockchain network, create a virtual profile on the device in a secure enclave based on the registration, maintain a transaction-related table for the device, and facilitate transaction commits and client communication through the node. In some embodiments, the device may have a physically unclonable feature associated with it. Registration may include the device sending a challenge response to a node regarding the physically unclonable feature. The pass-through security service may include trusted registration of peers in the blockchain network. The transaction-related table may include records of blockchain elements associated with the device, wherein the blockchain elements include channels, endorsement policies, and delegated authority proofs.

[0006] Preferably, the present invention provides a method that further includes updating a transaction-related table for a device, wherein the transaction-related table includes records of blockchain functions associated with the device.

[0007] Preferably, the present invention provides a method in which the blockchain functionality includes an endorsement strategy for maintaining the blockchain network and a delegated authority proof.

[0008] Preferably, the present invention provides a method, the method further comprising: receiving a membership services directive for a device from a node in a blockchain network; and updating a transaction-related table for the device in response to the membership services directive.

[0009] Preferably, the present invention provides a method, the method further comprising: receiving a membership service instruction for a blockchain network from a device; and updating a transaction-related table for the device in response to the membership service instruction.

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

[0011] Preferably, the present invention provides a method in which the pass-through service includes a representative device facilitating transactions.

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

[0013] Preferably, the present invention provides a method in which the pass-through service also includes all communication between the proxy device and other nodes in the blockchain network.

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

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

[0016] Preferably, the present invention provides a method in which the profile includes a virtual profile for a device, wherein the virtual profile includes an encryption key pair for the device, and wherein the encryption key pair is stored in a secure library associated with the drawing node.

[0017] Preferably, the present invention provides a method wherein the security library includes a hardware security architecture.

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

[0019] Preferably, the present invention provides a method in which an immutable device identifier includes a physically unclonable function (PUF) associated with the device.

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

[0021] Preferably, the present invention provides a method in which the device is an Internet of Things (IoT) device, and wherein the depicted node represents the IoT device in maintaining a distributed ledger.

[0022] Preferably, the present invention provides a method in which the depiction node includes a dedicated hardware coprocessor for performing pass-through services.

[0023] According to embodiments of this disclosure, a blockchain network is provided. One embodiment may include a plurality of relatively lower-capacity peers and at least one relatively higher-capacity peer. Each relatively lower-capacity peer may have an immutable device identifier associated with it. The relatively higher-capacity peer may represent the plurality of relatively lower-capacity peers to perform workloads requiring computing power higher than one or more predefined thresholds.

[0024] The above description is not intended to depict every illustrated embodiment or every implementation of this disclosure. Attached Figure Description

[0025] The accompanying drawings included in this application are incorporated in and form a part of the specification. The drawings illustrate embodiments of the present disclosure and, together with the specification, serve to explain the principles of the disclosure. The drawings are merely illustrative of certain embodiments and do not limit the scope of the disclosure.

[0026] Figure 1 An embodiment of a data processing system (DPS) according to some embodiments is shown.

[0027] Figure 2 A cloud computing environment according to some embodiments is described.

[0028] Figure 3 An abstract model layer is described according to some embodiments.

[0029] Figure 4 This is a system diagram of one embodiment of a blockchain network according to some embodiments.

[0030] Figure 5 This is a flowchart illustrating an example of a pass-through service provided by a drawing node in operation, according to some embodiments.

[0031] Figure 6A This is a flowchart illustrating another example of a pass-through service provided by a drawing node in operation, according to some embodiments. Figure 6B This is a flowchart illustrating another example of a pass-through service provided by a drawing node in operation, according to some embodiments.

[0032] Figure 7A An example blockchain architecture configuration according to some embodiments is described.

[0033] Figure 7B A blockchain transaction flow according to some embodiments is shown.

[0034] Figure 8A A flowchart according to some embodiments is shown.

[0035] Figure 8B Another flowchart according to some embodiments is shown.

[0036] Figure 8C An example system is shown that is configured to perform one or more operations described herein, according to some embodiments.

[0037] Figure 8D Another example system is shown, configured to perform one or more operations described herein, according to some embodiments.

[0038] Figure 8E Another example system configured to utilize smart contracts according to some embodiments is shown.

[0039] Figure 8F A system including a blockchain is shown according to some embodiments.

[0040] Figure 9A The process for adding a new block to a distributed ledger, according to an example embodiment, is illustrated.

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

[0042] Figure 9C A blockchain for digital content is illustrated according to an example embodiment.

[0043] Figure 9D A block is shown that can represent the structure of a block in a blockchain, according to an example embodiment.

[0044] This invention can have various modifications and substitutions, the details of which are illustrated by way of example in the accompanying drawings and can be described in detail. However, it should be understood that the purpose is not to limit the invention to the specific embodiments described. Rather, the invention covers all modifications, equivalents, and substitutions that fall within its scope. Detailed Implementation

[0045] This disclosure relates to aspects of the configuration and management of blockchain networks, and more specifically to the configuration and management of IoT devices within blockchain networks. This disclosure is not necessarily limited to such applications, and its various aspects can be understood through discussion of various examples within this context.

[0046] The Internet of Things (IoT) generally refers to a network of dedicated computing systems, such as devices, vehicles, signs, buildings, and other objects embedded with electronics, software, sensors, and / or actuators. This network connectivity enables these systems to collect data and exchange data with other IoT devices and / or computer systems. IoT allows for the remote sensing or control of these objects over existing network infrastructure, creating opportunities for more direct integration of the physical world into computer-based systems and leading to improved efficiency, accuracy, and economic benefits beyond reduced human intervention. When IoT sensors and actuators are used to augment objects in the physical world, this combination becomes an instance of a more general category of network-physical systems, encompassing technologies such as smart grids, virtual power plants, smart homes, smart transportation, and smart cities.

[0047] Currently, the world is experiencing a dramatic increase in the number of IoT devices used in commercial, industrial, and private environments. Workplaces, industrial environments, homes, public buildings, and city streets are increasingly equipped with network-enabled devices capable of connecting to other devices, receiving commands, sending information, and performing specific functions. Some estimates predict that there will eventually be over 50 billion IoT devices (i.e., intelligent devices capable of communicating with each other).

[0048] However, IoT devices are typically designed to be small, inexpensive, and lightweight. They can also be designed for passive operation (e.g., using only wireless power emitted by a reader). These constraints generally translate to IoT devices with relatively smaller local computing power (e.g., processor speed, memory size, and / or storage size below one or more predefined thresholds), especially compared to modern laptops, smartphones, and server computers (e.g., processor speed, memory size, and / or storage size above one or more predefined thresholds).

[0049] This lack of local computing power can lead to difficulties in processing machine-to-machine (M2M) transactions involving IoT devices, such as those on blockchain networks. For example, a significant issue in some types of blockchain networks is the identification and trustworthiness of new peer devices (i.e., the IoT devices in this illustrative example). Related issues for certain types of blockchain networks may include the registration and central management of these peer devices. Various options have been explored to address this problem, ranging from using identification management for IoT and other devices to verifying and confirming device signatures; however, none of these options have proven sufficient for lower-capacity computing systems like many IoT devices.

[0050] Therefore, some embodiments of this disclosure may provide immutable device identifiers, such as physically unclonable features, which can be integrated into the processing node services and / or infrastructure of a blockchain network. Some embodiments may employ immutable device identifiers as a registration mechanism and provide direct access service to enable devices with lower computing power to participate in the blockchain network. These direct access services may include registration, endorsement, ledger maintenance, channel definition and maintenance, database pointer tracking, and delegated authorization proof.

[0051] Some embodiments can integrate immutable device identifiers into the permissioned architecture of a blockchain network with low processing overhead, enabling lower-power devices (such as IoT devices) to meet the requirements of computing nodes in the blockchain network. A feature and advantage of these embodiments is their ability to trust low-power devices and sensors (such as IoT devices) to participate in the blockchain network.

[0052] One feature and advantage of these embodiments is that an immutable device identifier can automatically provide cryptographic proof for an immutable registration key, which can then be used as an identification mechanism in a blockchain network. A representative node can then be selected as a delineating node, which can use this registration key to authenticate IoT devices and establish trust. Once trust is established, the delineating node can provide pass-through services for and / or on behalf of the IoT device, such as registering with the network, maintaining a distributed ledger on behalf of the IoT device, managing channel elements, providing endorsement functions, and other client / peer-related activities. Thus, some embodiments of this disclosure can improve M2M and / or device-to-device communication because the delineating node can provide a localized version of transaction processing, thereby improving network processing efficiency.

[0053] This disclosure can also improve the efficiency of blockchain networks. Descriptor nodes can be used as dedicated nodes to bootstrap certain performance- and computationally intensive workloads (e.g., workloads requiring processor speed, memory size, and / or storage size above one or more predefined thresholds). Some embodiments may further optimize these dedicated nodes by leveraging hardware configurations and / or coprocessors specifically designed for these workloads. For example, a descriptor node may include a dedicated input / output processor (IOP) for offloading some communication overhead from the central processing unit (CPU), a larger amount of random access memory for storing transactions from a large number of IoT devices, and / or a coprocessor for performing encryption on behalf of the IoT devices.

[0054] While embodiments of this disclosure are generally described with reference to practical models of secure transaction processing between M2M and device-to-device (D2D) IoT devices, they can also be applied to a wide variety of other applications. For example, some embodiments can be used as various proxy services to extend licensed networks to end users / consumers using physically unclonable (PUF) enabled mobile devices and / or leveraging corresponding extensions to key management.

[0055] Data processing system

[0056] Figure 1 An embodiment of a data processing system (DPS) 100a according to some embodiments is shown. In this embodiment, the DPS 100a can be implemented as a personal computer; a server computer; a portable computer, such as a laptop or notebook computer, PDA (personal digital assistant), tablet computer, or smartphone; a processor embedded in a larger device such as a car, airplane, teleconferencing system, or appliance; a smart device; or any other suitable type of electronic device. Furthermore, different... Figure 1 The components shown, or components other than these, and the number, type, and configuration of these components can be changed. Furthermore, Figure 1Only representative major components of the DPS 100a are depicted, and each component can have more than Figure 1 The greater complexity is represented in the text.

[0057] Figure 1 The data processing system 100a includes multiple central processing units 110a-110d (generally referred to herein as processor 110 or CPU 110) connected via a system bus 122 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. In this embodiment, the mass storage interface 114 connects 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 disc drive 142. The network interface 118 allows DPS 100a to communicate with other DPS 100b via a communication medium 106. The memory 112 also includes an operating system 124, multiple application programs 126, and program data 128.

[0058] Figure 1 The data processing system 100a embodiment is a general-purpose computing device. Therefore, the processor 110 can be any device capable of executing program instructions stored in the memory 112, and it can itself be composed of one or more microprocessors and / or integrated circuits. In this embodiment, the DPS 100a includes multiple processors and / or processing cores, which is typical for larger, more powerful computer systems; however, in other embodiments, the DPS 100a may include a single processor system and / or a single processor designed to emulate a multiprocessor system. Furthermore, the processor 110 can be implemented using multiple heterogeneous data processing systems 100a, where a main processor and auxiliary processors coexist on a single chip. As another illustrative example, the processor 110 can be a symmetric multiprocessor system comprising multiple processors of the same type.

[0059] When the data processing system 100a starts, the associated processor 110 initially executes program instructions that constitute the operating system 124, which manages the physical and logical resources of the DPS 100a. These resources include memory 112, mass storage interface 114, terminal / display interface 116, network interface 118, and system bus 122. Like the processor 110, some DPS 100a embodiments may utilize multiple system interfaces 114, 116, 118, 120, and bus 122, each of which may include its own separate, fully programmable microprocessor.

[0060] Instructions for operating systems, applications, and / or programs (generally referred to as "program code," "computer-usable program code," or "computer-readable program code") may initially reside in mass storage devices 140, 141, and 142, communicating with processor 110 via system bus 122. In different embodiments, the program code may be implemented on different physical or tangible computer-readable media (e.g., system memory 112 or mass storage devices 140, 141, and 142). Figure 1 In the illustrative example, instructions are stored in a functional form on direct access storage device 140 in a persistent storage manner. These instructions are then loaded into memory 112 for execution by processor 110. However, program code may also reside in a functional form on selectively removable computer-readable medium 142 and may be loaded into or transferred to DPS 100a for execution by processor 110.

[0061] System bus 122 can be any device that facilitates communication between processor 110, memory 112, and interfaces 114, 116, 118, and 120. Furthermore, although in this embodiment system bus 122 is a relatively simple single bus structure providing a direct communication path between system buses 122, other bus structures consistent with this disclosure include, but are not limited to, hierarchical point-to-point links, star or mesh configurations, multiple hierarchical buses, parallel and redundant paths, etc.

[0062] Memory 112 and mass storage devices 140, 141, and 142 work together to store operating system 124, application program 126, and program data 128. In this embodiment, memory 112 is a random access semiconductor device capable of storing data and programs. Although Figure 1 Conceptually, the device is described as a single monolithic entity; however, in some embodiments, memory 112 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory 112 may reside in multi-level caches, and these caches may be further functionally partitioned, such that one cache holds instructions while another cache 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 known in any of the various so-called Non-Uniform Memory Access (NUMA) computer architectures. Furthermore, some embodiments may utilize virtual addressing mechanisms that allow DPS 100a to behave as if it were accessing a large single memory entity, rather than multiple smaller memory entities (e.g., memory 112) and mass storage devices 140, 141, 142.

[0063] Although the operating system 124, application program 126, and program data 128 are shown as being included in memory 112, in some embodiments, some or all of them may physically reside on different computer systems and may be remotely accessed, for example, via communication medium 106. Therefore, although the operating system 124, application program 126, and program data 128 are shown as being included in memory 112, these elements do not necessarily all reside in the same physical device and may even reside in the virtual memory of another DPS 100a.

[0064] System interfaces 114, 116, 118, and 120 support communication with various storage and I / O devices. Mass storage interface 114 supports the attachment of one or more mass storage devices 140, 141, and 142, which are typically spinning disk drives, solid-state drives (SSDs) that use integrated circuit components as memory for permanent data storage (typically using flash memory), or a combination of both. However, mass storage devices 140, 141, and 142 may also include other devices, including disk drive arrays (often called RAID arrays) and / or archival storage media configured to appear as a single large storage device to the host, such as hard disk drives, magnetic tapes (e.g., mini-DV), writable compact discs (e.g., CD-R and CD-RW), digital multifunction discs (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holographic storage systems, Blue LaserDiscs, IBM Millipede devices, etc.

[0065] Terminal / display interface 116 is used to directly connect one or more display units (e.g., monitors 180) to data processing system 100a. These display units 180 may be non-intelligent (i.e., dumb) terminals, such as LED monitors, or they may be fully programmable workstations that allow IT administrators and customers to communicate with DPS 100a. However, note that although display interface 116 is provided to support communication with one or more display units 180, DPS 100a does not necessarily require display units 180, as all necessary interactions with customers and other processes can occur via network interface 118.

[0066] Communication medium 106 can be any suitable network or combination of networks and can support any suitable protocol adapted to transmit data and / or code to / from multiple DPS 100as. Therefore, network interface 118 can be any device facilitating such communication, regardless of whether the network connection uses today's analog and / or digital technologies or is made via some future networking mechanism. Suitable communication medium 106 includes, but is not limited to, networks implemented using one or more of the following: "InfiniBand" or IEEE (Institute of Electrical and Electronics Engineers) 802.3x "Ethernet" specifications; cellular transport networks; wireless networks implementing one of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service ("GPRS"), FRS (Home Wireless Service), or Bluetooth specifications; ultra-wideband ("UWB") technologies (such as those described in FCC 02-48), etc. Those skilled in the art will understand that many different network and transport protocols can be used to implement communication medium 106. Transmission Control Protocol / Network Protocol ("TCP / IP") suites include suitable network and transport protocols.

[0067] cloud computing

[0068] Figure 2 A cloud environment including one or more DPS 100a is illustrated according to some embodiments. It should be understood that although this disclosure includes a detailed description of cloud computing, implementation of the teachings set forth herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0069] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0070] The characteristics are as follows:

[0071] • On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring manual interaction with the service provider.

[0072] • Wide Area Network Access: Capabilities are available on the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0073] • Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Location independence is significant because consumers typically do not control or know the exact location of the resources provided, but can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0074] • Rapid and Flexible: In some cases, the ability to scale outwards and inwards can be provided quickly and flexibly. For consumers, the available capacity often appears unlimited and can be purchased at any time and in any quantity.

[0075] • Measurement services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active customer accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the providers and consumers of the services being used.

[0076] The service model is as follows:

[0077] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with the possible exception of limited customer-specific application configuration settings.

[0078] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created or acquired by the consumer onto cloud infrastructure using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of possible application hosting environments.

[0079] Infrastructure as a Service (IaaS): This provides consumers with the capability to deliver processing, storage, networking, and other basic computing resources that enable them to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating system, storage, deployed applications, and possibly limited control over chosen networking components (e.g., host firewalls).

[0080] The deployment model is as follows:

[0081] • Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0082] Community cloud: Cloud infrastructure shared by several organizations and supporting specific communities with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0083] • Public cloud: Cloud infrastructure available to the general public or large industrial groups and owned by organizations that sell cloud services.

[0084] • Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported together (e.g., cloud bursting for load balancing between clouds).

[0085] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure of a network of interconnected nodes.

[0086] Now for reference Figure 2 The diagram illustrates an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate. These local computing devices include, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, without requiring cloud consumers to maintain resources on their local computing devices. It should be understood that... Figure 1 The types of computing devices 54A-N shown are for illustrative purposes only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0087] Now for reference Figure 3 This demonstrates a cloud computing environment of 50 ( Figure 2 This provides a set of functional abstractions. It should be understood beforehand that... Figure 2 The components, layers, and functions shown are for illustrative purposes only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0088] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host 61; a server 62 based on a RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage device 65; and a network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0089] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0090] In one example, management layer 80 can provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking when utilizing resources in the cloud computing environment, as well as billing or invoicing for consuming these resources. In one example, these resources may include application software licenses. Security provides identification and authentication for cloud consumers and tasks, and protection for data and other resources. Customer Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources, where future needs are anticipated according to the SLA.

[0091] Workload layer 90 provides examples of functionalities that can be leveraged in a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis and processing 94; transaction processing 95; and blockchain nodes 96.

[0092] Blockchain system

[0093] Figure 4 This is a system diagram of one embodiment of a blockchain network 400 according to some embodiments. Advantageously, the blockchain network 400 in this embodiment can provide a PUF (Proof of Validation), which can automatically provide cryptographic proofs for an immutable registration key, serving as an identification mechanism in the blockchain. Network 400 may include multiple relatively low-computing-power IoT devices (IoT devices) 410 (individually and collectively, only some are labeled for clarity) enabled with the PUF; a blockchain network 420 maintaining a distributed ledger 425; and depicted nodes 430. In some embodiments, blockchain network 420 may use existing blockchain infrastructure (such as...) Frameworks (such as Hyperledger, a trademark of the Linux Foundation) are used to create and / or be compatible with existing blockchain infrastructure. Node 430 is described as being able to provide pass-through services to 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-related table 435 associated with registered IoT devices 410, providing channel elements, providing endorsement functions, and other client-related blockchain activities.

[0094] In this embodiment, IoT device 410 may participate in M2M or device-driven transaction networks, such as blockchain network 420. IoT device 410 may then be individually enabled using a PUF, such as SRAM PUF, delayed PUF, butterfly PUF, metal resistor PUF, bistable ring PUF, DRAM PUF, digital PUF, oxide fracture PUF, coated PUF, quantum electronic PUF, magnetic PUF, optical PUF, quantum optical PUF, RF PUF, etc. In some embodiments, the PUF may provide a physically defined “digital fingerprint” output in response to a given input and condition (challenge), which can serve as a unique identifier for IoT device 410.

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

[0096] In this embodiment, the depicted node 430 may be a representative node, typically executed on a DPS 100A with relatively high computing power in a cloud computing environment 50. It can provide pass-through services, such as registering with the blockchain network 420, and maintain a distributed ledger 425 on behalf of relatively low-power IoT devices 410. In some embodiments, this includes channel elements, endorsement functions, and other client-related or peer-to-peer related activities.

[0097] In some embodiments, the depicted node 430 provides a unique interface for communication between virtual and secure devices, where the communication workload between the IoT device 410 and the blockchain network 420 is reduced.

[0098] Therefore, drawing node 430 can perform some or all of the following methods:

[0099] a. Provider Direct Security Service: This method covers all communications from the initial registration of IoT device 410 to / from PUF-enabled IoT devices.

[0100] b. Initial Registration: This method allows IoT device 410 to send a PUF response to the pass-through service to perform a trusted registration with the membership service. This method enables IoT device 410 to be registered as a node on the blockchain network 420.

[0101] c. Virtual Security Profile Creation: During registration, this method allows nodes to create virtual profiles for IoT devices 410 within a secure enclave, without having to use a Trusted Execution Environment (TEE), Trusted Computing Foundation (TCB), or similar architecture to enhance security. Virtual profiles with all cryptographic artifacts can be created on the node, and these virtual profiles can transact with each other on behalf of the IoT devices 410, especially when the IoT devices 410 are operating at low power.

[0102] d. Security Key Management: This method provides a security profile to protect cryptographic artifacts, PUF, and design calls to the Hardware Security Module (HSM). Therefore, (multiple) IoT devices 410 will not need to be dedicated hardware with TEE / TCB and HSM enabled, since PUF-enabled IoT devices 410 are already dedicated hardware with non-clonable addresses.

[0103] The depiction node 430 can use these methods to maintain a transaction-related table (not shown). This table can be in tabular form, maintaining records of the state and configuration of the blockchain network 420, such as channels, endorsement policies, database pointers, and delegated authority proofs. In this embodiment, the depiction node 430 can also participate in transaction completion. That is, in addition to acting as a maintainer of cryptographic artifacts and proxy services, the node 430 can also participate in transaction completion, including transaction submission and client communication.

[0104] In some embodiments, the depicting node 430 may also act as a distributed / centralized certification authority (CA) for a subset of hardware-based identification devices based on public key infrastructure (PKI) membership, and as a proxy for the blockchain network 420. In these embodiments, the depicting node 430 can register and act as a proxy between the hardware-based identification devices and the network. As a result, given the distributed nature, temporary registration, and the considerable number of devices from which transactions will be submitted, an external certification authority may be unaware of the registered device.

[0105] Direct access service

[0106] Figure 5 This is a flowchart illustrating an example method 500 of a pass-through service provided by a depicting node 430 in operation, according to some embodiments. Figure 5In this embodiment, the pass-through service can act as a server through which all IoT and / or low-power PUF devices communicate, which simplifies communication and security. Depicting node 430 can register(multiple) devices, generate(multiple) virtual profiles, and execute all transactions between virtual profiles, etc. More specifically, in operation 505, depicting node 430 can initialize and begin providing the pass-through service. Next, in operation 510, depicting node 430 can receive a registration request from one of the IoT devices 410. In response, the depicting node can confirm the PUF associated with the IoT device 410 at operation 512. In some embodiments, this may include sending a challenge to the IoT device 410 and receiving a response, etc. In some embodiments, the(multiple) correct responses may have been previously measured / calculated by the manufacturer of the IoT device 410 and communicated on a separate secure channel. In other embodiments, the response is defined as correct and is used to prevent future attacks on the blockchain network 420.

[0107] Depending on the implementation, if the challenge / response handshake is successfully verified or completed, then at operation 515, the depicting node 430 can register the IoT device 410 in the virtual server profile. Optionally, the depicting node 430 can also create a public / private key pair for the IoT device 410 at operation 520, and store the key pair in a secure vault at operation 525.

[0108] Next, in operation 530, the depicting node 430 may receive a membership service instruction from either the IoT device 410 or any other 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 request for new communication to an existing channel), in operation 540, the depicting node 430 may create a new entry in the transaction-related table or look up an existing entry in the transaction-related table. In either case, the depicting node 430 will respond to the membership service instruction in operation 550.

[0109] Figure 6A This is a flowchart illustrating another example method 600 of a pass-through service provided by a depicting node 430 in operation, according to some embodiments. In this example, the depicting node 430 acts as an agent (i.e., identifying peer nodes) for IoT device 410. At operation 605, the depicting 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 depicting node 430 may sign the proposed transaction on behalf of one of the IoT devices 410, using its dedicated PKI hardware in some embodiments, using a key pair stored in its security vault associated with and signed by a certification authority. At operation 612, the depicting node 430 may store pointers to the proposed transactions in its transaction association table.

[0110] In operation 615, node 430 can present the proposed transaction to one of the endorsing nodes in the blockchain network 420, which will process the proposed transaction normally according to the protocol of the blockchain network 420. This may include using a certification authority to verify the identity of the IoT device. Next, in operation 620, node 430 can present the endorsed transaction to one of the sorting nodes in the blockchain network 420, which will also process the proposed transaction normally according to the protocol of the blockchain network 420. This may also include using a certification authority to verify the identity of the IoT device 410. In operation 625, the blockchain network 420 can again use the normal protocol of the network to complete the proposed transaction on the distributed ledger 425.

[0111] Figure 6B This is a flowchart illustrating another example method 650 of a pass-through service provided by a delineating node 430 in operation, according to some embodiments. In this example, the delineating node 430 acts as a proxy (i.e., identifying peer nodes) for IoT device 410. At operation 655, the delineating node 430 may receive a channel creation request from one of the IoT nodes 410, directed to another peer node on the blockchain network 420. At operation 660, the delineating node 430 may sign the channel request on behalf of the IoT device 410 using its dedicated PKI hardware in some embodiments and using a key pair stored in its security vault, which is associated with one of the IoT devices 410 and signed by a certification authority. At operation 665, the delineating node 430 may create a record for the requested channel in its transaction-related table.

[0112] Next, in operation 670, node 430 can forward the channel request to the requesting peer node. In operation 675, the peer node can then respond by first verifying the identity of the requesting IoT device 410 using a signature and authentication authority. Then, in operation 680, the peer node will process the channel request transaction normally according to the protocol of the blockchain network 420.

[0113] A feature and advantage of these methods is that, in some embodiments, the depicting node 430 may be transparent to the rest of the blockchain network 420, including endorsing nodes, ordering nodes, and other peer nodes. That is, other nodes can process the proposed transaction(s) and requests(s) as if they came directly from one of the IoT devices 410. Advantageously, this can allow the use of dedicated nodes to improve the performance of compute-intensive workloads and / or workflows. Furthermore, the depicting node 430 in these embodiments can provide an interface for communication between virtual and secure devices, where the communication workload between the IoT devices 410 and the blockchain network 420 is reduced.

[0114] Blockchain architecture

[0115] Figure 7A A blockchain architecture configuration 700 according to some embodiments is illustrated. The blockchain architecture 700 in these embodiments may include certain blockchain elements, such as a set of blockchain nodes 702. In some embodiments, a virtual security profile created on depicted node 430 may also act as a separate blockchain node 720. The set of blockchain nodes 702 may further 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 various activities, such as blockchain transaction increment and verification processes (consensus). One or more of member nodes 704 and 710 may sign transactions based on a signing policy and may provide ordering services for all blockchain nodes in architecture 700. Member nodes 704-710 may initiate blockchain authentication and attempt to write to the immutable blockchain ledger stored in blockchain layer 716, a copy of which may also be stored on the underlying physical infrastructure 714.

[0116] In some embodiments, the blockchain architecture 700 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 then be created according to customized configurations sought by participants and can maintain its own state, control its own assets, and receive external information. The stored program / application code 720 can be deployed as transactions and installed on all blockchain nodes 704-710 via attachment to the distributed ledger.

[0117] The blockchain foundation or platform 712 may include layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.), and supports physical computer infrastructure that can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 716 may expose interfaces providing access to the processor code and the virtual execution environment required to use the physical infrastructure 714. The cryptographic trust service 718 can be used to verify (such as asset exchange transactions) and maintain information privacy.

[0118] Figure 7AThe blockchain architecture configuration can process and execute program / application code 720 via one or more interfaces and services exposed by the blockchain platform 712. Program / application code 720 can control blockchain assets. For example, code 720 can store and transmit data, and can be executed by member nodes 704-710 in the form of smart contracts with conditions or other code elements subject to their execution and associated chaincode. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or comply with other notifications such as changes and updates. The smart contract itself can be used to identify authorization and access requirements related to the ledger and the rules associated with their use. For example, document attribute information 726 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 716. Result 728 may include multiple linked shared documents. Physical infrastructure 714 can be used to obtain any data or information described herein.

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

[0120] Smart contracts can write data to the blockchain in key-value pair format. In some embodiments, smart contract code can also read values ​​stored in the blockchain and use those values ​​in application operations. The smart contract code in these embodiments can then write the outputs of various logical operations to the blockchain. In some embodiments, smart contract code can be used to create temporary data structures in a virtual machine or other computing platform. In these embodiments, the data written to the blockchain can be public or can be encrypted and maintained as private. Temporary data used / generated by the smart contract can be maintained in memory by the provided execution environment and can then be deleted after the data required by the blockchain has been identified.

[0121] In some embodiments, chaincode may include a code interpretation of a smart contract with additional features. In some embodiments, chaincode may be implemented as program code deployed on a computing network, wherein the chaincode is jointly executed and verified by chain validators during a consensus process. Chaincode may receive hashes and may retrieve hashes associated with a data template created using a previously stored feature extractor from the blockchain. If the hash of the hash identifier matches a hash created from the stored identifier template data, the chaincode may send an authorization key to the requested service. Chaincode may write data associated with cryptographic details to the blockchain.

[0122] Figure 7B An example of a blockchain transaction flow 750 between nodes of a blockchain according to some embodiments is shown. 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 execute chaincode functions to initiate the transaction. Output may include the chaincode result, a set of key / value pairs read from the chaincode (read set), and a set of key / value pairs written to the chaincode (write set). If approved, a proposal response 792, along with the endorsing signature, may then be sent back to the client 760.

[0123] In response, client 760 can compile the endorsements into transaction payload 793 and broadcast it to ordering service node 784. Ordering service node 784 can then deliver the ordered transactions as blocks to all peers 781-783 on the channel. Each peer 781-783 can verify the transaction before it is committed to the blockchain. For example, in some embodiments, the peers can check the endorsement policy to ensure that the correct allocation of the designated peer has been signed and verify the signature against transaction payload 793.

[0124] Continue to refer to Figure 7B In some embodiments, client node 760 can initiate transaction 791 by constructing a request and sending it to peer node 781, which can act as an endorser. Client 760 may include an application utilizing a supported software development kit (SDK) that can leverage available APIs to generate transaction proposals. Transaction proposals may also be requests to call chaincode functions, allowing data to be read and / or written to the distributed ledger (i.e., writing new key-value pairs for assets). The SDK can serve as a shim to encapsulate transaction proposals into an appropriate architectural format (e.g., a protocol buffer over a remote procedure call (RPC)) and employ the client's cryptographic certificate to generate a unique signature for the transaction proposal.

[0125] In response, the endorsing peer 781 can verify that: (a) the transaction proposal is well-formed; (b) the transaction has not been committed in the past (replay attack protection); (c) the signature is valid; and (d) the submitter (client 760 in this exemplary embodiment) is properly authorized to perform the proposed operation on the channel. The endorsing peer 781 can input the transaction proposal as arguments to a invoked chaincode function. The chaincode can then be executed on the current state database to produce transaction results, including response values, a read set, and a write set. In some embodiments, the ledger is not updated at this time. Instead, this set of values, along with the signature of the endorsing peer 781, can be passed back to the client 760's SDK as a proposal response 792, which parses the payload to be used by the application.

[0126] In response, the application on client 760 can check / verify the signature of the endorsing peer and compare the proposed response to determine if they are identical. If the chaincode only queries the ledger, the application can check the query response and typically does not submit the transaction to the ordering service 784. If the client application wants to submit the transaction to the ordering service 784 to update the ledger, the application can determine whether the specified endorsement policy has been satisfied before submission (i.e., whether all peer nodes required for the transaction have endorsed the transaction). Here, the client may include only one of the parties in the transaction. In this case, each client may have its own endorser node, and each endorser node will be required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards unendorsed transactions, the endorsement policy will still be enforced by the peers and supported during the submission verification phase.

[0127] After a successful check, in operation 793, client 760 can add the endorsement set to a transaction and broadcast the transaction proposal and response within the transaction message to ordering service 784. A transaction may include a read / write set, the signatures of the endorsing peers, and the channel ID. Ordering service 784 does not need to check the entire contents of a transaction to perform its operation; instead, it can simply receive transactions from all channels in the network, order them by channel in chronological order, and create a transaction block for each channel.

[0128] The plus sign (+) is generated by transaction execution. Transactions in a block can be marked as valid or invalid. Furthermore, in operation 795, each peer node (781-783) can append a block to the channel's chain, and for each valid transaction, a write set is committed to the current state database. Events can be emitted to notify clients that the transaction (call) has been immutably appended to the chain, and to indicate whether the transaction is valid or invalid.

[0129] Permissioned blockchain

[0130] Figure 8AAn example of a permitted blockchain network according to some embodiments is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 802 can initiate transactions to a permitted blockchain 804. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 806, such as auditors. Blockchain network operator 808 manages member permissions, such as registering regulator 806 as an "auditor" and blockchain user 802 as a "client." Auditors can be restricted to querying the ledger only, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0131] In some embodiments, blockchain developer 810 may write chaincode and client applications. In these embodiments, blockchain developer 810 can deploy the chaincode directly to the network via an interface. To include certificates from a traditional data source 812 in the chaincode, developer 810 can use an out-of-band connection to access the data. In this example, blockchain user 802 can connect to a permissioned blockchain 804 via peer node 814. Before any transaction is made, peer node 814 can obtain the user's registration and transaction certificates from a certification authority 816 that manages user roles and licenses. In some embodiments, blockchain users must possess these digital certificates to transact on the permissioned blockchain 804. In other embodiments, blockchain users can use other technologies for authentication, such as via a distributed trust chain. Simultaneously, users attempting to utilize the chaincode may be required to verify their certificates on the traditional data source 812. The chaincode can use an out-of-band connection to this data via a traditional processing platform 818 to confirm the user's authorization.

[0132] Figure 8B Another example of a permissioned blockchain network according to some embodiments is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 822 can submit transactions to a permissioned blockchain 824. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly via APIs, etc. The network can provide access to regulators 826, such as auditors. Blockchain network operator 828 manages member permissions, such as registering regulator 826 as "auditors" and blockchain user 822 as "clients." Auditors can be restricted to querying the ledger only, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0133] In these embodiments, blockchain developer 831 can write chaincode and client-side applications. Blockchain developer 831 can deploy the chaincode directly to the network via an interface. To include certificates from a traditional data source 832 in the chaincode, developer 831 can use an out-of-band connection to access the data. In this example, blockchain user 822 connects to the network via peer node 834. Before any transaction is made, peer node 834 obtains the user's registration and transaction certificates from certification authority 836. In some embodiments, blockchain users must possess these digital certificates to transact on the permissioned blockchain 824. In other embodiments, blockchain users can use other technologies for authentication, such as via a distributed trust chain. Simultaneously, users attempting to utilize the chaincode may be required to verify their certificates on the traditional data source 832. The chaincode can use an out-of-band connection to the data via a traditional processing platform 838 to confirm the user's authorization.

[0134] Figure 8C An example system is shown, according to some embodiments, including physical infrastructure 811 configured to perform various operations. References Figure 8C Physical infrastructure 811 includes modules 888 and 889. Module 819 includes a blockchain 820 and a smart contract 830 (which may reside on the blockchain 820), capable of performing any of the operational steps 878 (in module 812) included in any example embodiment. Step / operation 878 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 830 and / or blockchain 820. Physical infrastructure 811, modules 888, and 889 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Furthermore, modules 888 and 889 may be the same module.

[0135] Figure 8D Another example system configured to perform various operations according to some embodiments is shown. References Figure 8D The system includes modules 812 and 814. Module 814 includes a blockchain 820 and a smart contract 830 (which may reside on the blockchain 820), capable of performing any of the operational steps 878 (in module 812) included in any example embodiment. Step / operation 878 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 830 and / or blockchain 820. Physical modules 812 and 814 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, modules 812 and 814 may be the same module.

[0136] Figure 8EAn example system configured to utilize smart contract configuration between contract parties according to some embodiments is illustrated, along with an intermediary server configured to enforce smart contract terms on blockchain 820. References Figure 8E This configuration can represent a communication session, an asset transfer session, or a process or procedure driven by smart contract 830, which explicitly identifies one or more user devices 852 and / or 856. The execution, operation, and results of the smart contract execution can be managed by server 854. The content of smart contract 830 may require digital signatures by one or more entities 852 and 856, which are parties to the smart contract transaction. The results of smart contract execution can be written to blockchain 820 as a blockchain transaction. Smart contract 830 resides on blockchain 820 and can reside on one or more computers, servers, processors, memory, and / or wireless communication devices.

[0137] Figure 8F A system 860 including a blockchain is shown according to some embodiments. Reference Figure 8D For example, Application Programming Interface (API) Gateway 862 provides a public interface for accessing blockchain logic (e.g., smart contract 830 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 862 is a public interface for executing 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 maintains a copy of the world state and allows clients 852 and 856 to query data on the world state and submit transactions to the distributed ledger in the blockchain network, where, depending on smart contract 830 and the endorsement policy, the endorsing peer will run smart contract 830.

[0138] Block processing

[0139] Figure 9A The process 900 of adding a new data block 930 to a distributed ledger 920 according to some embodiments is shown, and Figure 7B The contents of a new data block 930 in a blockchain according to some embodiments are shown. The new data block 930 may include document link data.

[0140] Reference Figure 9AA client (not shown) may submit transactions to blockchain nodes 911, 912, and / or 913. The client can be an instruction received from any source to formulate an activity on blockchain 922. As an example, the client may be an application acting on behalf of a requester (e.g., a device, person, or entity) to propose a transaction on the blockchain. Multiple blockchain peers (e.g., blockchain nodes 911, 912, and 913) may maintain the state of the blockchain network and a copy of 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 endorsements, verify transactions, and commit transactions to the distributed ledger 920. In some embodiments, blockchain nodes 911, 912, and 913 may perform the roles of an endorsing node, a committing node, or both.

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

[0142] The current state of blockchain 922 and distributed ledger 920 can be stored in state database 924. Here, the current state data represents the latest values ​​of all keys that have ever been included in the chain transaction log of blockchain 922. Chaincode calls execute transactions against the current state in state database 924. To make these chaincode interactions more efficient, the latest values ​​of all keys can be stored in state database 924. State database 924 can include an indexed view of the transaction log of blockchain 922, so it can be regenerated from the chain at any time. State database 924 can be automatically restored (or automatically generated if needed) before accepting transactions.

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

[0144] The ordering service 910 accepts endorsed transactions, orders them into blocks, and delivers these blocks to the committing peers. For example, the ordering service 910 can initiate new blocks when a transaction threshold is reached, a timer times out, or another condition is met. Figure 9A In the example, blockchain node 912 is a committing peer that has received the new data block 930 to store on blockchain 922. The first block in a blockchain can be called the origin block, which includes information about the blockchain, its members, the data stored in it, etc.

[0145] The ordering service 910 may consist of a cluster of ordering nodes. In some embodiments, the ordering service 910 may not process transactions, smart contracts, or maintain a shared ledger. Instead, in these embodiments, the ordering service 910 may accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 920. The architecture of the blockchain network may be designed to make specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) pluggable components.

[0146] In some embodiments, transactions can be written to the distributed ledger 920 in a consistent order. In these embodiments, the order of transactions can be established to ensure they are valid when updates to the state database 924 are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.) where ordering occurs through the solving or mining of cryptographic puzzles, in this example, the parties to the distributed ledger 920 can choose the ordering mechanism best suited to the network.

[0147] In some embodiments, when the sorting service 910 initializes a new data block 930, the new data block 930 can be broadcast to commit peers (e.g., blockchain nodes 911, 912, and 913). In response, each commit peer can verify the transactions within the new data block 930 by checking to ensure that the read set and write set still match the current world state in the state database 924. Specifically, the commit peer can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 924. When the commit peer confirms the transaction, the transaction can be written to blockchain 922 on the distributed ledger 920, and the state database 924 can be updated with the write data from the read-write set. In some embodiments, if the transaction fails (e.g., if the commit peer finds that the read-write set does not match the current world state in the state database 924), the transaction sorted into a block can still be included in the block, but is marked as invalid, and the state database 924 is not updated.

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

[0149] Block data 950 can store transaction information for each transaction recorded in the new data block 930. For example, transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 920, transaction ID, epoch, payload visibility, chaincode path (deployment tx), chaincode name, chaincode version, inputs (chaincode and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identifier, endorser signature, suggestion hash, chaincode events, response status, namespace, read set (a list of keys and versions read through the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Merkel tree query digest, etc. Transaction data can be stored for each of N transactions.

[0150] In some embodiments, block data 950 may also store new data 962, which adds additional information to the hash-linked blockchain in blockchain 922. The additional information may include one or more of the steps, features, processes, and / or actions described or depicted herein. Therefore, new data 962 may be stored in the immutable log of the blocks on the distributed ledger 920. Some of the benefits of storing this new data 962 are reflected in the various embodiments described and depicted herein. Although in Figure 9B In this embodiment, new data 962 is depicted in block data 950, but in some embodiments, new data 962 may also be located in block header 940 or block metadata 960. New data 962 may also include document synthesis keys for linking organizations.

[0151] Block metadata 960 can store multiple fields of metadata (e.g., as byte arrays). Metadata fields may include: a signature on block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, persistent storage of the last offset of the sorting service that sorts the block, etc. The signature, last configured block, and sorter metadata can be added by the sorting service 910. Simultaneously, the block submitter (such as blockchain node 912) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. Transaction filters may include byte arrays of size equal to the number of transactions in block data 950 and verification codes identifying whether a transaction is valid / invalid.

[0152] Figure 9CAn embodiment of a blockchain 970 for digital content is illustrated according to some embodiments. Digital content may include one or more files and associated information. Files may include transaction data, media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. Immutable, append-only aspects of some blockchain embodiments may be desired as security measures to protect the integrity, validity, and authenticity of digital content, making it suitable for use in legal proceedings, where the application of access rules or consideration of the presentation and use of evidence or digital information are other settings of additional interest. In this context, the digital content may be referred to as digital evidence.

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

[0154]

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

[0156]

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

[0158] Blocks 9781, 9782, ..., 978 in the blockchain N Each block may include a block header, a file version, and a value. As a result of hashing in the blockchain, the block header and value may be different for each block. In one embodiment, the value may be included in the block header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0159] The first block 9781 in the blockchain is called the origin block and may include a header 9721, the original file 9741, and an initial value 9761. The hashing mechanism used for the origin block, and indeed in all subsequent blocks, can vary. For example, all the information in the first block 9781 can be hashed together and at once, or each piece of information in the first block 9781, or a portion thereof, can be hashed separately, and then the hash of each separately hashed portion can be performed.

[0160] Header 9721 may include one or more initial parameters, which may include, for example, a version number, timestamp, nonce (current value), root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 9741 and / or the blockchain. Header 9721 may be generated automatically (e.g., via blockchain network management software) or manually by blockchain participants. It is consistent with blocks 9782 to 978... N Unlike the header in the source block, the header 9721 of the source block may not reference the previous block, simply because the previous block does not exist.

[0161] The original file 9741 of the origin block can be, for example, data collected by a device, whether processed or unprocessed, before the device is included in the blockchain. The original file 9741 can be received from a device, media source, or node through the system's interface. The original file 9741 can be associated with metadata, which can be generated manually or automatically by a user, device, and / or system processor, for example. The metadata can be included in the first block 9781 associated with the original file 9741.

[0162] The value 9761 of the origin block can 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 the hash value of the original file 9741, the metadata of the original file 9741, and other information associated with the file. In one implementation, the initial value 9761 may be based on the following unique attributes:

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

[0164] 2) Initiate Device ID

[0165] 3) Start timestamp of the original file

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

[0167] 5) A blockchain network member ID used for the software, to currently control the original file and associated metadata.

[0168] Other blocks 9782 to 978 in the blockchain N It also has a header, filename, and value. However, unlike the header 9721 of the first block, the headers of the other blocks are 9722 to 972. N Each block includes the hash of the preceding block. The hash of the preceding block can be simply the hash of the header of the preceding block, or it can be the hash of the entire preceding block. By including the hash of the preceding block in each remaining block, a block-by-block tracing back from the Nth block to the originating block (and the associated original file) can be performed, as shown by arrow 980, to establish an auditable and immutable chain of custody.

[0169] Each header in the other blocks is 9722 to 972. N It may also include other information such as version number, timestamp, current value, root information, difficulty level, consensus protocol and / or other parameters or information that are typically associated with the corresponding file and / or blockchain.

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

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

[0172] The values ​​9762 to 976 in each of the other blocks N These are unique values, and all are distinct due to the processing performed. For example, a value in any given block corresponds to an updated version of a value in a previous block. The update is reflected in the hash of the block to which the value was assigned. Therefore, the value of a block provides an indication of what processing was performed within the block and also allows for tracing back to the original file via the blockchain. This tracing confirms the chain of custody of the file throughout the blockchain.

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

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

[0175] a) If the file has been processed in any way (e.g., if the file has been edited, copied, modified, accessed, or otherwise acted upon), the new SHA-2 calculated hash value

[0176] b) New storage location of the file

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

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

[0179] Figure 9D An embodiment of a block according to some embodiments is shown, which can represent the structure of a block in Blockchain 990. Block (block) i ) may include the head 972 i Document 974 i Sum of 976 i .

[0180] Header 972i may include previous blocks i-1 The hash value and additional reference information, which can be any type of information discussed herein (e.g., header information including references, attributes, parameters, etc.). In some embodiments, all blocks except the originating block may reference the hash of a previous block. The hash value of a previous block may simply be the hash of the header in the previous block, or the hash of all or part of the information (including files and metadata) in the previous block.

[0181] Document 974 i This may include multiple data sets, such as sequential data 1, data 2, ..., data N. The data is tagged with metadata 1, metadata 2, ..., metadata N, which describe the content and / or characteristics associated with the data. For example, the metadata for each piece of data may include: a timestamp indicating the data, information about the data processing, keywords indicating the people or other content depicted in the data, and / or other information that may help establish the validity and content of the document as a whole, especially its use of digital evidence, such as as described in the embodiments discussed below. In addition to the metadata, each piece of data may be accompanied by references to previous data, REF1, REF2, ..., REF... N This is used to mark data to prevent tampering, gaps, and sequential referencing within the file. In some embodiments, once metadata is assigned to data (e.g., via a smart contract), it cannot be altered while the hash remains unchanged; this can be easily identified as invalid. Therefore, the metadata in these embodiments creates a data log of information that can be accessed and used by participants in the blockchain.

[0182] In some embodiments, the value is 976 iThis can be a hash value or other value calculated based on any type of information discussed earlier. For example, for any given block i, the value of that block can be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata of the file and header data, in another embodiment, the value can be based partly or entirely on that metadata.

[0183] After blockchain 970 is formed, in some embodiments, at any point in time, the immutable chain of custody for a file can be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or tracing process can begin by decrypting the values ​​of the currently most included blocks (e.g., the last (Nth) block), and then continue decrypting the values ​​of other blocks until the origin block is reached and the original file is recovered. Decryption can also involve decrypting the header and file, along with associated metadata, in each block.

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

[0185] In some embodiments, generating a key pair can be similar to creating an account on the blockchain, but does not necessarily require actual registration anywhere. In these embodiments, each transaction executed on the blockchain can be digitally signed by the sender using their private key. This signature helps ensure that only the account owner can track and process documents on the blockchain (if within the permissions determined by a smart contract).

[0186] Computer program products

[0187] This invention can be a system, method, and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0188] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0189] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the respective computing / processing device.

[0190] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages ​​such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, 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, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing the status information of the computer-readable program instructions.

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

[0192] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0193] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0194] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may not occur in the order shown in the figures. For example, two blocks shown consecutively may actually be implemented as a single step, executed simultaneously, substantially simultaneously, with partial or complete time overlap, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0195] General

[0196] Any specific procedural terminology used in this specification is merely for convenience, and therefore the invention should not be limited to use only in any particular application identified and / or implied by such terminology. Thus, for example, routines executed to implement embodiments of the invention, whether as part of an operating system or as a particular application, component, program, module, object, or sequence of instructions, may be referred to as "program," "application," "server," or other meaningful terms. In fact, other alternative hardware and / or software environments may be used without departing from the scope of the invention.

[0197] Therefore, it is intended that the embodiments described herein be considered illustrative rather than limiting in all respects, and that the scope of the invention be determined with reference to the appended claims.

Claims

1. A computer-implemented method for configuring a blockchain network, comprising: Registering a device at a depicting node in a blockchain network, wherein the registration includes receiving an immutable device identifier from the device via a network interface, wherein the immutable device identifier includes a physically unclonable feature associated with the device; The processor of the described node creates a profile of the device based on the registration; and The processor of the described node performs a pass-through service for the device.

2. The method of claim 1, further comprising updating a transaction-related table for the device, wherein, The transaction-related table includes records of blockchain functionality associated with the device.

3. The method of claim 2, wherein, The blockchain functionality includes an endorsement policy and a delegated authority verification mechanism for maintaining the blockchain network.

4. The method according to claim 2, further comprising: Receive membership service instructions for the device from nodes in the blockchain network; as well as In response to the membership service instruction, update the transaction-related table of the device.

5. The method according to claim 2, further comprising: Receive membership service instructions for the blockchain network from the device; as well as In response to the membership service instruction, update the transaction-related table of the device.

6. The method of claim 1, wherein, The pass-through service includes creating channels for communication between peers on the blockchain network.

7. The method of claim 1, wherein, The pass-through service includes facilitating transactions on behalf of the device.

8. The method of claim 1, wherein, The pass-through service includes facilitating communication between the device and other nodes in the blockchain network.

9. The method of claim 8, wherein, The pass-through service also includes proxying all communication between the device and the other nodes in the blockchain network.

10. The method of claim 1, wherein, The registration also includes registering the device with the membership service of the blockchain network.

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

12. The method of claim 1, wherein, The profile includes a virtual profile of the device, wherein the virtual profile includes an encryption key pair of the device, and wherein the encryption key pair is stored in a security vault associated with the drawing node.

13. The method of claim 12, wherein, The security library includes a hardware security architecture.

14. The method according to claim 1, further comprising: Receive a registration request from the device; In response to the registration request: Send a challenge to the device; as well as Verify the response from the device; as well as Upon successful verification, the device is registered.

15. The method of claim 1, wherein, The physically unclonable feature automatically provides cryptographic proof for the immutable registration key; and wherein the immutable registration key is used as an identification mechanism in the blockchain network.

16. The method of claim 1, wherein, The device is an Internet of Things (IoT) device, and the depicting node represents the IoT device in maintaining a distributed ledger.

17. The method of claim 1, wherein, The drawing node includes a dedicated hardware coprocessor for performing the pass-through service.

18. A computer program product for integrating device identifiers 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 to cause the processor to: providing a pass-through security service by the node, wherein The pass-through security service includes trusted registration of peers in the blockchain network; The node registers the device as a registered node on the blockchain network, wherein the device has associated physically unclonable functionality; and The registration includes the device sending a physically unclonable challenge response to the node; The node creates a virtual profile on the device based on the registration in the secure enclave; Maintain a transaction-related table for the device, wherein the transaction-related table includes records of blockchain elements associated with the device, wherein the blockchain elements include channels, endorsement policies, and delegated authority proofs; and The node facilitates transaction submissions and client communication for the device.

19. A blockchain network, comprising: Multiple lower-capability peers, each of which has an associated immutable device identifier, wherein the immutable device identifier includes physically unclonable functionality associated with the device; and At least one relatively higher-capability peer, wherein the relatively higher-capability peer represents the plurality of relatively lower-capability peers performing workloads that require computing power higher than one or more predefined thresholds.

Images