Blockchain node and contract deployment method

Abstract

The present invention generally relates to contract deployment in a network. The network can be based on blockchain technology. The manufacturer usage description (MUD) file of a network node such as an IoT device is extended to include extended information for implementing consensus-based contracts in the network. The blockchain node of the network is used to obtain the MUD file and generate a contract associated with the network node. In this way, contracts can be automatically registered and verified based on the extended information of the MUD file. The extended information lays the foundation for unified, optimized and standardized contract deployment in the network. In this way, the workload required to deploy contracts in a blockchain-based network can be minimized. In addition, potential errors and failures can also be reduced. The extended information can also provide security protection against hostile organizations (for example, by tampering with contracts).

Description

Technical Field

[0001] The present invention generally relates to network communications. For example, the present invention relates to blockchain technology. For another example, the present invention relates to a blockchain node and a method for deploying a contract in a network. Background Art

[0002] Blockchain technology refers to decentralized ledger technology that records any digital asset or transaction without the involvement of a third party in the process. Consortium blockchain (CBC) is a subtype of blockchain technology. It is a network that includes a distributed ledger in which pre-selected peers with appropriate privileges work together to achieve common goals and develop cooperative solutions based on reliable workflows and accountability. Consortium blockchain is also known as collaborative blockchain.

[0003] CBC can support node isolation (e.g., by using authentication and key agreement (AKA) channels) to separate business domains and regulate access to business data and processes. For example, CBC participants can adopt unified standards (e.g., AKA shared records and / or contracts) to achieve more efficient data processing on business domains.

[0004] Figure 7 An example of a CBC-based smart grid is shown. The smart grid includes several different types of energy producers (e.g., solar, nuclear, wind, etc.), several energy providers, and energy consumers. Energy producers, providers, and consumers are connected via a CBC network, which includes multiple blockchain nodes. Energy sharing and / or resale (e.g., when consumption exceeds the capacity of the provider) can be achieved through the CBC network. Energy producers, providers, and consumers can publish appropriate energy transfer records, which are stored in blockchain nodes as ledger nodes for further mutual billing. Ledger nodes are used to encapsulate shared data (e.g., published records) and smart contracts (e.g., business logic applied to records before being added to ledger nodes). A typical smart contract implements verification of the original contract record (or transaction) and converts the fields into types defined as formats accepted by alliance members. Summary of the invention

[0005] Traditional CBC is based on the assumption that all participants are verified in advance (for example, before registration) and malicious behavior is excluded. However, applying this CBC to the business domain may encounter some problems. For example, multi-party interoperability and comprehensive security are difficult to achieve.

[0006] When CBC is applied to a network (e.g., the Internet of Things (IoT)), the CBC is constructed to support a large number of different nodes to generate various records in this CBC network. Nodes are usually provided by various third parties, which may be subject to external threats and may behave improperly.

[0007] For example, in traditional IoT CBC solutions, node owners (e.g., partner organizations) are responsible for registering their own new nodes. With full knowledge of the node's internal capabilities and technology, node owners are often responsible for correctly handling related transactions, including record verification before approval, and acting as a root of trust. Typically, node owners are responsible for creating smart contracts and deploying them to nodes associated with the organization. Alliance partners often have limited knowledge of device-specific smart contracts and the associated capabilities demonstrated by the deployed contracts.

[0008] Contract deployment in traditional CBC networks can be cumbersome, slow, tedious, and error-prone. This can lead to conflicts and misunderstandings, which can be expensive to fix. In addition, consensus that relies on a limited list of validating nodes that is primarily managed by the affiliated organization may not be optimal, and consensus is associated with a relatively low level of trust. In addition, a high rate of new nodes joining or a high rate of leaving existing nodes may lead to system overloads, such as denial-of-service (DoS). In addition, the security of traditional CBC networks may be limited because hostile organizations can deploy contracts that other alliance members cannot fully verify. Therefore, the use of CBC in highly diverse IoT solutions, where new types of nodes are expected to be registered frequently, may be adversely affected by the high complexity, high workload, and suboptimal security of contract deployment in the network.

[0009] In view of the above, there is a need to improve CBC solutions for networks such as IoT networks.

[0010] The purpose of the present invention is to improve the security and scalability of traditional CBC solutions. The present invention aims to automatically and securely register contracts in a CBC-based network.

[0011] These and other objects are achieved by the subject matter of the independent claims. Further implementations are apparent from the dependent claims, the embodiments and the drawings.

[0012] A first aspect of the present invention provides a blockchain node for a network. The blockchain node is used to obtain a manufacturer usage description (MUD) file of a network node. The MUD file includes extended information for implementing a consensus-based contract in the network. The blockchain node is also used to generate a contract associated with the network node based on the extended information of the MUD file.

[0013] It is worth noting that the network node can be a node newly added to the network or a new type of node added to the network. The network node can be an IoT device. In the present invention, the terms "network node" and "node" can be used interchangeably.

[0014] Optionally, the network can be any type of communication network based on blockchain technology (or group consensus technology). For example, the network can be a CBC network. When the network is an IoT network and is based on CBC technology, the network can be called a CBC IoT network.

[0015] Optionally, the blockchain node may be a management node used to manage the network. Alternatively, the blockchain node may be a consensus network node (or simply a consensus node).

[0016] Optionally, the blockchain node can be used to retrieve the MUD file via a MUD uniform resource identifier (URI). The MUD URI can be provided by the network's ledger node.

[0017] Optionally, MUD files can be stored in a MUD server. A MUD server is not necessarily part of the network. For example, a MUD server can be maintained by the owner of a network node.

[0018] It is worth noting that a MUD file can provide a means for a network node (e.g., an end device) to send to the network the types of access and network capabilities required for proper operation. A MUD file can be a file containing YANG-based JSON that describes a network device and associated recommended specific network behaviors.

[0019] In the present invention, the MUD file is extended to include extended information for implementing consensus-based contracts in the network. The extended information may include CBC-related definitions for supporting automatic node discovery and automatic contract creation and certification.

[0020] In this way, blockchain nodes can independently generate contracts based on extended information. This can minimize the amount of work required to register new node types in the network and minimize potential errors and failures caused by human error, synchronization issues, etc.

[0021] In an implementation of the first aspect, the extended information may include record description information used to generate the contract.

[0022] In this way, a unified, reliable and consistent information can be provided to blockchain nodes to generate contracts.

[0023] In an implementation of the first aspect, the extended information may include blockchain-specific description information for selecting a group of consensus network nodes in the network.

[0024] In this way, consensus network nodes can be selectively selected based on blockchain-specific description information.

[0025] In an implementation manner of the first aspect, the extended information may include service domain specific extended information.

[0026] In this way, individual business logic can be specified through business domain specific extension information.

[0027] In an implementation of the first aspect, the record description information may include one or more fields, wherein each field may include one or more of the following:

[0028] - indicates the name of the field;

[0029] - the data type of the field;

[0030] - used to validate the value range of the field;

[0031] -update the refresh rate of the field;

[0032] -Aging value.

[0033] It should be noted that the refresh rate and the aging value may be referred to as an expected refresh rate and an expected aging value.

[0034] In this way, potential errors can be reduced.

[0035] In an implementation of the first aspect, the blockchain specific description information may include one or more of the following:

[0036] - a domain field indicating the relevant domain;

[0037] - A quorum size indicating the minimum number of nodes in the consensus network.

[0038] It is important to note that the quorum size can be understood as the minimum number of consensus network nodes required to reach consensus.

[0039] In this way, different trust levels can be used for consensus in the network.

[0040] In an implementation of the first aspect, the service domain specific extension information may include one or more of the following:

[0041] -Manufacturer specific settings;

[0042] -Signature certificate;

[0043] -The name and strength of the encryption algorithm.

[0044] In an implementation of the first aspect, the extended information and / or the MUD file may be signed by a certificate.

[0045] Alternatively, a certificate can also be understood as a signature.

[0046] Optionally, the extension information and the MUD file can be signed by different certificates.

[0047] In this way, the security level of the extended information itself and / or the MUD file can be enhanced.

[0048] In an implementation of the first aspect, the blockchain node can be used to obtain the MUD file based on a uniform resource identifier (URI).

[0049] Using the URI to obtain the MUD file ensures that every blockchain node in the network obtains the same MUD file.

[0050] Note that any type of link, identifier, or address associated with a MUD file may be used as an alternative to a URI.

[0051] A second aspect of the present invention provides a network. The network includes a network node, a ledger node, a management node, and a group of consensus network nodes. The network node may be a node newly added to the network. The network node is used to provide a URI identifying an associated MUD file to the ledger node. The MUD file includes extended information for implementing a consensus-based contract in the network.

[0052] After receiving the URI, the ledger node is used to register the URI associated with the network node and notify the management device of the registration;

[0053] After receiving the notification from the ledger node, the management device is used to obtain the MUD file based on the URI, generate a contract associated with the network node based on the extended information of the MUD file, and deploy the contract in the network.

[0054] After the contract is deployed in the network, each consensus network node in the group of consensus network nodes is used to obtain the MUD file based on the URI, independently generate another contract associated with the network node based on the extended information of the MUD file, use the other contract to verify the deployed contract, and send the verification result to the ledger node.

[0055] The ledger node is further configured to determine whether a consensus is reached based on the results received from the group of consensus network nodes.

[0056] It should be noted that the management node and any node in the group of consensus network nodes can act as a blockchain node in the first aspect or any implementation thereof.

[0057] The network of the second aspect may have the same advantages and effects as the device of the first aspect and its implementation method.

[0058] A third aspect of the present invention provides a MUD file for a network node, wherein the MUD file includes extended information for implementing a consensus-based contract associated with the network node in a network.

[0059] In an implementation of the third aspect, the extended information may include record description information used to generate the contract.

[0060] In an implementation of the third aspect, the extended information may include blockchain-specific description information for selecting a group of consensus network nodes.

[0061] In an implementation manner of the third aspect, the extended information may include service domain specific extended information.

[0062] The MUD file and its implementation method of the third aspect may have the same advantages and effects as the device and its implementation method of the first aspect mentioned above.

[0063] A fourth aspect of the present invention provides a method for a network. The method includes a blockchain node obtaining a MUD file of a network node. The MUD file includes extended information for implementing a consensus-based contract in the network. The method also includes the blockchain node generating a contract associated with the network node based on the extended information of the MUD file.

[0064] In an implementation of the fourth aspect, the extended information may include record description information used to generate the contract.

[0065] In an implementation of the fourth aspect, the extended information may include blockchain-specific description information for selecting a group of consensus network nodes in the network.

[0066] In an implementation manner of the fourth aspect, the extended information may include service domain specific extended information.

[0067] In an implementation of the fourth aspect, the record description information may include one or more fields, wherein each field may include one or more of the following:

[0068] - indicates the name of the field;

[0069] - the data type of the field;

[0070] - used to validate the value range of the field;

[0071] -update the refresh rate of the field;

[0072] -Aging value.

[0073] In an implementation of the fourth aspect, the blockchain specific description information may include one or more of the following:

[0074] - a domain field indicating the relevant domain;

[0075] - A quorum size indicating the minimum number of nodes in the consensus network.

[0076] In an implementation manner of the fourth aspect, the service domain specific extension information may include one or more of the following:

[0077] -Manufacturer-specific settings;

[0078] -Signature certificate;

[0079] -The name and strength of the encryption algorithm.

[0080] In an implementation of the fourth aspect, the extended information and / or the MUD file may be signed by a certificate.

[0081] In an implementation of the first aspect, the method may further include acquiring the MUD file based on the URI.

[0082] The method of the fourth aspect and its implementation method may have the same advantages and effects as the device of the first aspect and its implementation method mentioned above.

[0083] A fifth aspect of the present invention provides a computer program product, comprising instructions, which, when the program is executed by a computer, cause the computer to execute the method according to the fourth aspect or any implementation thereof.

[0084] A sixth aspect of the present invention provides a non-transitory storage medium storing executable program code, which, when executed by a processor, enables the method described in the fourth aspect or any implementation thereof to be executed.

[0085] A seventh aspect of the present invention provides a chipset, comprising a memory and a processor, wherein the memory and the processor are used to store and execute program code to execute the method according to the fourth aspect or any implementation thereof.

[0086] It should be noted that all nodes, devices, elements, units and components described in this application can be implemented in software or hardware elements or any combination thereof. The steps performed by the various entities described in this application and the functions to be performed by the various entities described are intended to refer to the various entities for performing the various steps and functions. Although in the description of the following specific embodiments, the specific functions or steps to be performed by the external entity are not reflected in the description of the specific detailed elements of the entity performing the specific steps or functions, it should be clear to the technician that these methods and functions can be implemented in the corresponding software or hardware elements or any type of combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0087] In conjunction with the accompanying drawings, the following description of specific embodiments will illustrate the above aspects and implementation methods, wherein:

[0088] Figure 1 An example of a blockchain node of the present invention is shown;

[0089] Figure 2 An example of a network of the present invention is shown;

[0090] Figure 3 An example of contract registration of the present invention is shown;

[0091] Figure 4 An example of contract deployment of the present invention is shown;

[0092] Figure 5 A flow chart showing the contract deployment of the present invention is shown;

[0093] Figure 6 An example of the method for a network of the present invention is shown;

[0094] Figure 7 An example of a smart grid is shown. DETAILED DESCRIPTION

[0095] The present invention generally relates to contract registration and deployment in a network based on blockchain technology. In order to automate contract registration and deployment and improve the security and authenticity of contract generation and certification, it is crucial to have unified information to generate and certify contracts.

[0096] Figure 1 An example of a blockchain node 100 of the present invention is shown. The blockchain node 100 is used to obtain a MUD file 120 of a network node. Alternatively, the network node may be a device newly added to the network. Alternatively, the network node may be used to generate a new or updated contract in the network. Alternatively, the configuration of the network node may have been updated. For example, the network node may be from a new energy provider that has newly joined the network (e.g., a smart grid), and the new energy provider may need to deploy its contract in the network.

[0097] It should be noted that the MUD file 120 may be based on the MUD proposed in the Internet Engineering Task Force (IETF) RFC 8520. The MUD proposed in RFC 8520 is used to specify a component-based architecture based on descriptions for use by manufacturers. In the present invention, the MUD defined in RFC 8520 is extended.

[0098] The MUD file 120 in the present invention includes extended information 140 for implementing a consensus-based contract in the network. The blockchain node 100 is used to generate a contract 160 associated with the network node based on the extended information 140 of the MUD file 120. In this way, the contract 160 can be registered, deployed and established in a decentralized manner.

[0099] An example of the extended information 140 included in the MUD file 120 may be as follows:

[0100]

[0101] In this example, a single field description is shown. In general, any CBC related definitions may be included in the extension information 140 .

[0102] Optionally, the extension information 140 of the MUD 120 file may include one or more of the following parts: a domain-specific extension (DSE) 142, a blockchain-specific description (BCD) 144, and a record description (RD) 146. It should be noted that Figure 1The order described in is for illustration purposes only. When the extended information 140 includes two or more parts, the two or more parts can be in any order. An example of the structure of the extended information 140 is as follows:

[0103]

[0104] Note that the header and footer may be used to indicate the beginning and end, respectively, of extended information included in the MUD file.

[0105] DSE 142 may be used in situations where a service federation includes members that share similar or unified data and processes. Manufacturers of network nodes (e.g., suppliers) may use this section to specify well-known settings that make sense in a narrow scope (e.g., contract details related to security, finance, IT management, etc.), and may include specialized parameters such as signing certificates, names and strengths of encryption algorithms, etc.

[0106] Examples of fields that may be included in BCD 144 are listed in Table 1.

[0107] Field Name describe usage domain Related domains (IoT, finance, ...) Node grouping, business logic fine-tuning, etc. Arbitration Size Minimum number of nodes for consensus For controlled contract enforcement (enough voters registered) other Additional fields Meet specific needs such as ledgers

[0108] Table 1: Possible fields in the BCD section

[0109] Examples of fields that may be included in RD 146 are listed in Table 2.

[0110]

[0111] Table 2: Possible fields in the RD section

[0112] RD 146 can be used primarily for the generation of contracts that can be verified on a consensus basis. Parts of extended information 140 can be selectively used based on the alliance's decision (e.g., only RD 146 can be used to generate a contract). These fields can be used selectively. For example, some of the fields in Table 2 can be used to create partial information about a contract. The ledger node can use some or all of the fields in BCD 144 to select nodes related to verification and management of business channels.

[0113] Optionally, the extended information may also include a signature 148. The signature may be used to support any third party's authenticity and integrity checks. A signature may also be understood as a certificate. The MUD file and / or extended information may be signed by a known certificate (e.g., a certificate from a vendor or a known authority).

[0114] Figure 1The blockchain node 100 in the example may be a management node of the network. For example, the network may be a CBC IoT network, and the blockchain node 100 may belong to the owner of the CBC IoT network. In other words, the blockchain node 100 may be an administrator or management node of the network. When a new network node is added to the network, the blockchain node 100 as a management node may be used to independently generate a contract 160 associated with the network node and register the generated contract 160. Alternatively, Figure 1 The blockchain node 100 in can be a consensus node of the network. In this case, the blockchain node 100 as a consensus node can participate in contract verification and certification. For example, when, for example, the ledger node notifies the blockchain node 100 as a consensus node to verify the contract 160 to be deployed in the network, the blockchain node 100 can independently generate the contract 160 based on the MUD file 120 according to the present invention. Then, the blockchain node 100 as a consensus node can be used to verify the to-be-deployed contract using the independently generated contract 160. The necessary information required to generate and / or verify the contract is included in the extended information 140 of the MUD file 120.

[0115] Figure 2 An example of a network 200 of the present invention is shown. The network 200 includes a network node 201, a ledger node 202, a management node 203, and a group of consensus network nodes 204. The network node 201 is Figure 2 200, and may be a new node to be added to the network 200. Alternatively, the network node 201 may be a network node whose contract information is to be updated. Alternatively, the network node 201 may be a new type of device to be added to the network 200.

[0116] Optionally, the network may be a CBC network. In addition, the network may be an IoT network. In the network 200, the new node 201 will deploy its contract. In the present invention, the deployment of the contract may generally include contract registration and contract verification.

[0117] The new node 201 may be used to provide the URI (MUD URI) identifying the associated MUD file to the ledger node 202. The MUD file includes extended information for implementing consensus-based contracts in the network. It should be noted that Figure 2 The MUD file in can be Figure 1 Optionally, the ledger node 202 can be used to enforce sequential and synchronous deployment and manage roles and states in the network 200.

[0118] Optionally, the new node 201 may include an API that can be called by the ledger node 202 to discover devices and can be used to return a MUD URI. The MUD URI can be signed by a universally trusted certificate to support source verification. When there are several extensions in the universal MUD file, the MUD URI can point to one or more specific parts of multiple extensions in the universal MUD file.

[0119] After receiving the URI, the ledger node 202 may be configured to register the URI associated with the new node 201 and notify the management node 203 of the registration. Optionally, to register the URI, the ledger node 202 may be configured to store the URI associated with the new node 201 (e.g., the ID / address of the new node) in a registration device 205. The registration device 205 may be any type of storage device that can be connected to the ledger node 202. The registration device 205 may also be a local storage medium of the ledger node 202.

[0120] After the management node 203 receives the notification from the ledger node 202, the management node 203 is used to obtain the MUD file based on the URI. Optionally, the management node 203 can be used to obtain information about the new node (e.g., the ID / address of the new node) from the registration notification of the ledger node 202. Based on the information about the new node 201, the management node 203 can be used to retrieve the URI. Optionally, the management node 203 can be used to obtain the MUD file from the MUD server 206 based on the URI. The MUD server 206 can be provided by the manufacturer (or supplier) or owner of the new node. The MUD server 206 is not necessarily part of the network 202. For example, the MUD server 206 can be an Internet server accessible to any device with a URI. The MUD file can be prepared in advance and can be already stored in the MUD server 206. The management node 203 can send a request to the MUD server 206 to obtain the MUD file. The request may include one or more parameters identifying the required part, such as the MUD URI, the device type, a sub-part of the MUD URI, etc.

[0121] After obtaining the extended information of the MUD file, the management node 203 is used to generate a contract associated with the new node 201 based on the extended information of the MUD file, and deploy the generated contract to the network 200. This can end the contract registration. It should be noted that the management node 203 can be based on Figure 1 The blockchain node 100 disclosed in .

[0122] After the contract is deployed in the network, each consensus network node (or simply referred to as a consensus node) in the set of consensus network nodes 204 is used to obtain a MUD file based on a URI. Each consensus node 204 is used to independently generate another contract associated with the new node 201 based on the extended information of the MUD file. In order to generate another contract, similar to the management node 203, each consensus node 204 can obtain a URI, query the MUD server 206 using the URI, and retrieve the MUD file. Each consensus node 204 is also used to verify the deployed contract using another contract and send the result of the verification to the ledger node 202. The ledger node 202 is also used to determine whether a consensus is reached based on the results received from the set of consensus network nodes 204, which can end the contract verification. It should be noted that the above-mentioned contract verification can occur when there is a transaction associated with the contract that needs to be approved in the network 200. In order to verify the deployed contract, each consensus node 204 can be used to compare the deployed contract with another contract. Optionally, the management node 203 or the ledger node 202 can be used to select a subset of the set of consensus nodes for verification based on the extended information of the MUD file. For example, if the domain information identifying the relevant domain is 64 in the BCD part of the MUD file, the ledger node 202 or the management 203 can be used to at least select the consensus node in the relevant domain for verification. This can save network resources.

[0123] Figure 3 An example of contract registration of the present invention is shown. Figures 1 to 3 Similar elements and steps in the same manner may also share the same features and functions. Contract registration includes the following steps.

[0124] Step 301: The new node will register in the network and send a registration request including the MUD URI to the ledger node.

[0125] Step 302: The ledger node registers the MUD URI associated with the ID of the new node, for example in a registry.

[0126] Step 303: The ledger node notifies the management node to register.

[0127] Step 304: The management node retrieves the MUD file associated with the new node from the MUD server. The MUD file includes extended information for generating a consensus-based contract associated with the new node.

[0128] Step 305: The management node generates a contract based on the MUD file.

[0129] Step 306: The management node caches the generated contract in, for example, a registry through the ledger node.

[0130] Figure 4An example of contract deployment of the present invention is shown. Figures 1 to 4 Similar elements and steps in the same embodiment may also share the same features and functions.

[0131] Contract deployment includes the following steps.

[0132] Step 401: The ledger node notifies a group of consensus nodes to verify the contract of the new node.

[0133] Step 402: Each consensus node obtains a MUD file.

[0134] Step 403: Each consensus node generates another contract based on the MUD file.

[0135] Step 404: Each consensus node verifies the contract using another contract.

[0136] Step 405: Each consensus node sends the verification result to the ledger node.

[0137] Step 406: The ledger node activates the contract.

[0138] Step 407: The ledger node notifies the new node whether the contract is approved.

[0139] Figure 5 A flow chart of contract deployment of the present invention is shown. Figures 1 to 5 Similar elements and steps in may also share the same features and functions. Contract deployment may include the following steps.

[0140] First, when a new node is introduced (e.g., for a new device type), the ledger node can retrieve the MUD URI and notify the management node of the new node.

[0141] Second, the management node can decide to register a new node and generate a contract associated with the new node. Optionally, a newly introduced contract deployment transaction can be generated.

[0142] Third, the ledger can notify registered consortium members (or consensus nodes) of the contract registration. The details of the registration (e.g., MUD URI) will be provided as part of the notification.

[0143] Fourth, alliance members can independently retrieve extended information from the MUD file and generate contracts based on the extended information of the MUD file.

[0144] Fifth, if the contracts generated by the management node and alliance members meet any of the following conditions, the newly registered contract is approved:

[0145] -Contracts are equal. Comparisons can be performed based on generated code snippets for string comparisons.

[0146] - The contracts produce code that performs identically. For example, for a synthetic test dataset, various pieces of the contract deliver identical results.

[0147] Sixth, after collecting sufficient (consensus size) approvals from consensus nodes, the ledger node can notify members of transaction submission based on the contract, and the transaction submission may be converted into contract activation by the participating parties.

[0148] Figure 6 A diagram of a method 600 for a network of the present invention is shown. The method 600 comprises the following steps:

[0149] -Step 601: The blockchain node obtains the MUD file of the network node. The MUD file includes extended information for implementing consensus-based contracts in the network; and

[0150] -Step 602: The blockchain node generates a contract associated with the network node based on the extended information of the MUD file.

[0151] It should be noted that from the above Figure 1-Figure 5 From the perspective of FIG. 6 , the steps of method 600 may share the same functions and details. Therefore, the corresponding method implementation will not be described in detail herein.

[0152] By including extended information for generating consensus-based contracts in a MUD file, the effort required to register new nodes (e.g., IoT devices) in a blockchain-based network can be minimized. In addition, potential errors and failures caused by human error and synchronization issues can be minimized. In addition, the extended information provides protection against hostile or stealing (owning organization) organizations (e.g., by tampering with contracts). In addition, synchronization issues associated with contract deployment of independently managed nodes can be alleviated. In addition, the extended information lays the foundation for unified, optimized and standardized contract deployment in the network, which can be a CBC IoT network.

[0153] The nodes and devices in the present invention may include processing circuits (not shown) for respectively performing, carrying out or initiating various operations of the devices described herein. The processing circuit may include hardware and software. The hardware may include analog circuits or digital circuits, or both analog circuits and digital circuits. The digital circuit may include components such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP) or a multi-purpose processor. Optionally, the processing circuit includes one or more processors and a non-transient memory connected to the one or more processors. The non-transient memory may carry an executable program code, which, when executed by one or more processors, causes the device to respectively perform, carry out or initiate the operations or methods described herein.

[0154] For example, the (network) node according to the present invention may be an electronic device, such as a computer, a server, a tablet computer, a mobile terminal, an IoT device, etc.

[0155] The invention has been described in conjunction with various embodiments as examples and implementations. However, other variations may be understood and implemented by those skilled in the art in practicing the claimed subject matter, based on a study of the drawings, the invention and the independent claims. In the claims and in the specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfil the functions of several entities or items described in the claims. The enumeration of certain measures in mutually different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A blockchain node (100) for a network, characterized in that: The blockchain node (100) is used for: Obtaining a manufacturer usage description (MUD) file (120) of a network node, wherein the MUD file (120) includes extended information (140) for implementing a consensus-based contract in the network; A contract (160) associated with the network node is generated based on the extended information (140) of the MUD file (120).

2. The blockchain node (100) according to claim 1, characterized in that: The extended information (140) includes record description information (146) used to generate the contract (160).

3. The blockchain node (100) according to claim 1 or 2, characterized in that: The extended information (140) includes blockchain specific description information (144) for selecting a set of consensus network nodes in the network.

4. The blockchain node (100) according to any one of claims 1 to 3, characterized in that: The extended information (140) includes service domain specific extended information (142).

5. The blockchain node (100) according to any one of claims 2 to 4, characterized in that: The record description information (146) includes one or more fields, each of which includes one or more of the following: - indicates the name of the field; - the data type of the field; - used to validate the value range of the field; -update the refresh rate of the field; -Aging value.

6. The blockchain node (100) according to any one of claims 2 to 5, characterized in that: The blockchain specific description information (144) includes one or more of the following: - a domain field indicating the relevant domain; - A quorum size indicating the minimum number of nodes in the consensus network.

7. The blockchain node (100) according to any one of claims 2 to 6, characterized in that: The service domain specific extension information (142) includes one or more of the following: -Manufacturer specific settings; -Signature certificate; -The name and strength of the encryption algorithm.

8. The blockchain node (100) according to any one of claims 1 to 7, characterized in that: The extended information (140) and / or the MUD file (120) are signed by a certificate (148).

9. The blockchain node (100) according to any one of claims 1 to 8, characterized in that: The blockchain node (100) is used to obtain the MUD file (120) based on a uniform resource identifier (URI).

10. A network (200), comprising a network node (201), a ledger node (202), a management node (203) and a group of consensus network nodes (204), characterized in that: The network node (201) is used to provide a uniform resource identifier (URI) identifying an associated manufacturer usage description (MUD) file to the ledger node (202), wherein the MUD file includes extended information for implementing a consensus-based contract in the network; After receiving the URI, the ledger node (202) is used to register the URI associated with the network node (201) and notify the management node (203) of the registration; After receiving the notification from the ledger node (202), the management node (203) is used to obtain the MUD file based on the URI, generate a contract associated with the network node (201) based on the extended information of the MUD file, and deploy the contract in the network; After the contract is deployed in the network, each consensus network node in the group of consensus network nodes (204) is used to obtain the MUD file based on the URI, independently generate another contract associated with the network node (201) based on the extended information of the MUD file, verify the deployed contract using the other contract, and send the verification result to the ledger node (202); The ledger node (202) is further configured to determine whether a consensus is reached based on the results received from the group of consensus network nodes (204).

11. A manufacturer usage description (MUD) file (120) for a network node, characterized in that: The MUD file (120) includes extended information (140) for implementing a consensus-based contract associated with the network node in the network.

12. The MUD file (120) according to claim 11, characterized in that: The extended information (140) includes record description information (146) used to generate the contract.

13. The MUD file (120) according to claim 11 or 12, characterized in that: The extended information (140) includes blockchain specific description information (144) for selecting a group of consensus network nodes.

14. The MUD file (120) according to any one of claims 11 to 13, characterized in that: The extended information (140) includes service domain specific extended information (142).

15. A method (600) for a network, characterized in that: The method comprises: The blockchain node obtains (601) a manufacturer usage description (MUD) file of the network node, wherein the MUD file includes extended information for implementing a consensus-based contract in the network; The blockchain node generates (602) a contract associated with the network node based on the extended information of the MUD file.

16. A computer program product, characterized in that The program comprises instructions which, when executed by a computer, cause the computer to execute the method according to claim 15 .

Images