Blockchain-based twin data interaction method and apparatus

Abstract

The application provides a kind of based on the method and device of twin data interaction of blockchain, and there is smart contract on blockchain, and the contract state of smart contract is stored with twin register, and smart contract includes registration module, method includes: based on the digital twin identity object corresponding to the target entity of pre-established registration message is structured, and based on registration message to blockchain sends registration transaction of calling registration module, to trigger registration module in twin register and write the target registration record of digital twin identity object, target registration transaction includes digital twin identity identification, access strategy and service pointer;Receive service request for digital twin object;Based on digital twin identity identification in service request, to blockchain sends data query request;According to the access strategy returned by blockchain, the authority of service request is checked, and the service interface is determined and called based on the service pointer returned by blockchain after checking, and the calling result is returned.

Description

Technical Field

[0001] This invention relates to the field of digital twin technology, and in particular to a blockchain-based method and apparatus for twin data interaction. Background Technology

[0002] Digital twin technology constructs a virtual mapping of physical entities in digital space, enabling real-time synchronization of the physical entity's state, behavior, and operational processes. It can be widely applied in areas such as equipment monitoring, production scheduling, intelligent operation and maintenance, predictive maintenance, and full lifecycle management. Digital twin objects not only contain entity attribute information but also real-time operational status, historical operational data, object relationships, and business models, forming a crucial foundation for digital management.

[0003] With the development of digital twin technology, more and more systems are building digital twin models to digitally manage equipment, production lines, factories, and even cities. However, most current digital twin platforms rely on centralized databases or cloud platforms for data management. There is a lack of a unified identity management mechanism between different platforms, and digital twin objects lack reliable registration capabilities. Their status information is prone to inconsistencies due to system migration, platform switching, or data synchronization anomalies. Therefore, how to achieve unified identity management and reliable interaction for digital twin objects is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a blockchain-based twin data interaction method and apparatus to eliminate or improve one or more defects existing in the prior art.

[0005] According to the first aspect, a blockchain-based twin data interaction method is provided. A smart contract is deployed on the blockchain, and the contract state of the smart contract stores a twin registry. The smart contract includes a registration module, which is used to write registration records to the twin registry. The method includes: constructing a registration message based on a pre-established digital twin identity object corresponding to a target entity, and sending a registration transaction to the blockchain based on the registration message to invoke the registration module, thereby triggering the registration module to write the target registration record of the digital twin identity object into the twin registry. The registration transaction includes a digital twin identity identifier, a state hash of the digital twin state, a repository version number of the off-chain twin state repository, an access policy, and a service pointer. The service pointer is used for... The document describes a service interface associated with the digital twin object corresponding to the aforementioned target entity; receives service requests for the aforementioned digital twin object, wherein the service request includes the requesting user's identifier, the aforementioned digital twin identity identifier, service type, and operation type; based on the aforementioned digital twin identity identifier in the service request, sends a data query request to the aforementioned blockchain, wherein the data query request is used to query the access policy and service pointer in the aforementioned target registration record corresponding to the aforementioned digital twin identity identifier on the aforementioned blockchain; performs permission verification on the aforementioned service request according to the access policy returned by the aforementioned blockchain, and if the permission verification passes, determines and calls the target service interface based on the service pointer returned by the aforementioned blockchain, and returns the call result as the service response information for the aforementioned service request.

[0006] According to the second aspect, a blockchain-based twin data interaction device is provided. A smart contract is deployed on the blockchain, and the contract state of the smart contract stores a twin registry. The smart contract includes a registration module, which is used to write registration records to the twin registry. The device includes a registration unit, used to construct a registration message based on a pre-established digital twin identity object corresponding to a target entity, and to send a registration transaction to the blockchain based on the registration message, invoking the registration module to trigger the registration module to write a target registration record of the digital twin identity object into the twin registry. The registration transaction includes a digital twin identity identifier, a state hash of the digital twin state, a repository version number of the off-chain twin state repository, an access policy, and a service pointer, wherein the service pointer is used to point to the target entity. The system includes: a service interface description of the service interface associated with the corresponding digital twin object; a receiving unit for receiving service requests for the aforementioned digital twin object, wherein the service request includes the identifier of the requesting user, the aforementioned digital twin identity identifier, the service type, and the operation type; a query unit for sending a data query request to the aforementioned blockchain based on the aforementioned digital twin identity identifier in the service request, wherein the data query request is used to query the access policy and service pointer in the aforementioned target registration record corresponding to the aforementioned digital twin identity identifier on the aforementioned blockchain; and a response unit for performing permission verification on the aforementioned service request according to the access policy returned by the aforementioned blockchain, and, if the permission verification passes, determining and calling the target service interface based on the service pointer returned by the aforementioned blockchain, and returning the call result as the service response information for the aforementioned service request.

[0007] According to a third aspect, an electronic device is provided, including a processor, a memory, and a computer program / instructions stored in the memory, characterized in that the processor is configured to execute the computer program / instructions, and when the computer program / instructions are executed, the electronic device performs the steps of the method as described in any one of the first aspects.

[0008] According to a fourth aspect, a computer-readable storage medium is provided having a computer program / instructions stored thereon, characterized in that, when executed by a processor, the computer program / instructions implement the steps of the method as described in any one of the first aspects.

[0009] The blockchain-based twin data interaction method and apparatus provided in the embodiments of this specification can deploy smart contracts on the blockchain. The smart contract's contract state stores a twin registry. The smart contract can include a registration module, which can be used to write registration records to the twin registry. Based on this, the aforementioned blockchain-based twin data interaction method can include: First, a registration message can be constructed based on a pre-established digital twin identity object corresponding to the target entity, and a registration transaction invoking the registration module can be sent to the blockchain based on the registration message to trigger the registration module to write the target registration record of the digital twin identity object into the twin registry. The registration transaction can include a digital twin identity identifier, a state hash of the digital twin state, a repository version number of the off-chain twin state repository, an access policy, and a service pointer. The service pointer is used to point to a service interface description of the service interface associated with the digital twin object corresponding to the target entity. Second, a service request for the digital twin object can be received. The service request includes the requesting user's identifier, the digital twin identity identifier, the service type, and the operation type. Then, based on the digital twin identity in the service request, a data query request can be sent to the blockchain. This data query request retrieves the access policy and service pointer from the target registration record corresponding to the digital twin identity on the blockchain. Finally, the service request can be authorized based on the access policy returned by the blockchain. If the authorization verification passes, the target service interface is determined and invoked based on the service pointer returned by the blockchain, and the invocation result is returned as the service response information for the service request. Thus, unified identity management of digital twin objects can be achieved based on blockchain, as can trusted interaction between digital twin objects.

[0010] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0011] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to the specific ones described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0012] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to limit the scope of the invention.

[0013] Figure 1 A flowchart illustrating a blockchain-based twin data interaction method according to one embodiment is shown; Figure 2An architecture diagram of a blockchain-based twin data interaction system according to one embodiment is shown; Figure 3 A schematic block diagram of a blockchain-based twin data interaction device according to one embodiment is shown. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0015] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0016] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0017] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0018] It is understood that the ordinal numbers such as "first" and "second" mentioned in this specification are only used to distinguish multiple objects of the same or different categories (such as components, steps, parameters, etc.), and do not indicate the priority, importance or order relationship between objects, nor do they constitute a limitation on the technical features.

[0019] Blockchain technology is a special distributed database technology suitable for storing simple, sequential data that can be verified within the system. Cryptography and consensus algorithms ensure the immutability and tamper-proof nature of the data. A blockchain contains multiple blockchain nodes, each storing the entire ledger—the state of all blocks and accounts. Each node in the blockchain can produce the same state by executing the same transaction, and each node stores the same state database. A transaction in the blockchain context refers to a unit of work executed and recorded within the blockchain. Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in the form of code.

[0020] As mentioned earlier, how to achieve unified identity management and trusted interaction of digital twin objects is a technical problem that urgently needs to be solved.

[0021] Therefore, the embodiments of this specification provide a blockchain-based twin data interaction method, which can realize unified identity management of digital twin objects based on blockchain, and can also realize trusted interaction of digital twin objects based on blockchain.

[0022] It is understood that the blockchain-based twin data interaction method in the embodiments of this specification can be executed by any device, equipment, platform, device cluster, etc., with computing and processing capabilities.

[0023] Before implementing the aforementioned blockchain-based twin data interaction method, a digital twin identity object and a digital twin object can be constructed for the target entity. These two can be linked through the digital twin identity identifier Twin_ID. The digital twin identity object serves as the unified management and control entry point for the digital twin object, storing basic information about the target entity, the current version number of the off-chain twin state repository, and its lifecycle status. The digital twin object represents a complete data mapping of the target entity in the digital space, including state data, server endpoints, and historical version records, and is stored in the off-chain twin state repository using the digital twin identity identifier Twin_ID as the primary index.

[0024] In some examples, the digital twin identity object of the target entity can be established through the following steps 1) and 2), specifically: Step 1) Generate a digital twin identity for the target entity based on a preset hash algorithm and various primary relevant information of the target entity.

[0025] In this example, the target entity can include physical entities and business entities, such as equipment, production lines, vehicles, energy facilities, sensors, edge nodes, business systems, or third-party platforms. The primary relevant information for the target entity may include, but is not limited to, entity type, owner, public key, entity attribute summary, and creation time.

[0026] For example, suppose the physical entity or business entity is: From the entity Extract the corresponding entity attribute set: in, Can represent entities The set of entity attributes, The first entity can represent the third Attributes such as device number, model, manufacturer, deployment location, organization, activation time, and business category.

[0027] You can also obtain entities Entity type: Get Entity Owner or management entity: And generate or bind public / private key pairs: in, It can represent the public key corresponding to a digital twin object. It can represent the private key corresponding to a digital twin object.

[0028] After that, you can work on the entity attribute set. Standardization process: And calculate the entity attribute set Corresponding entity attribute summary: in, This represents a normalization function, used to uniformly process field order, encoding format, unit format, and data structure; It can represent the set of entity attributes after normalization. Represents a cryptographic hash function; It can represent a summary of entity attributes.

[0029] In this example, the digital twin identity Twin_ID can be generated based on one or more of the following: entity type, owner, public key, entity attribute digest, creation time, and random perturbation factor. In one implementation, in, Can represent entities The corresponding digital twin identity identifier, It can indicate the identity creation time. It can represent random numbers or salt values. It can represent splicing operations.

[0030] Step 2) Encapsulate the digital twin identity identifier and various secondary related information of the target entity according to a preset data structure to generate a digital twin identity object.

[0031] In this example, a digital twin identity and various secondary related information of the target entity can be encapsulated according to a preset data structure to generate a digital twin identity object. For example, these secondary related information may include at least one of the following: entity type, owner, metadata, public key, repository version number, lifecycle state, and relationship index, etc. The repository version number is the version number of the off-chain twin state repository corresponding to the digital twin identity, which can be used to store the data of the digital twin object corresponding to the target entity. The lifecycle state can refer to the lifecycle state of the digital twin object corresponding to the target entity. The relationship index can represent the relationship between the digital twin object corresponding to the target entity and other digital twin objects, such as ownership, management, etc. It is understood that constructing digital twin objects from physical entities or business entities is an existing well-known technology, and will not be elaborated upon here.

[0032] For example, entities Corresponding digital twin identity object It can be represented as: in, Can represent entities Digital twin identity identifier, Representing entities entity type, Representing entities The entity owner or management entity, Representing entities metadata, Represents the public key. This indicates the current version number of the off-chain twin state repository. Representing entities The lifecycle state of the corresponding digital twin object. Represents a relational index.

[0033] The initial version number of the off-chain twin state repository can be set as follows: The initial lifecycle state can be set as follows: In this example, to prevent identity conflicts, it can be checked whether the generated digital twin identity, Twin_ID, already exists: in, This represents an existing set of digital twin identities.

[0034] when At that time, it indicates the generated digital twin identity. Since it already exists, the random perturbation factor can be regenerated. And regenerate the digital twin identity. When At that time, it indicates the generated digital twin identity. If it does not exist, the validity of the digital twin identity can be confirmed.

[0035] This example demonstrates how to transform a physical or business entity into a registerable, verifiable, and traceable digital twin identity object.

[0036] After the digital twin identity object corresponding to the target entity is established, the blockchain-based twin data interaction method of this embodiment can be further executed. A smart contract can be pre-deployed on the blockchain, and this smart contract is configured with an independent contract state storage space. The contract state of this smart contract can store a twin registry. This twin registry not only stores data hashes but also stores the on-chain trusted state of the digital twin object corresponding to the target entity. The twin registry can also be called an on-chain twin registry. The smart contract may also include a registration module, which can be used to write (or add) registration records corresponding to the digital twin identity object to the twin registry.

[0037] Please see Figure 1 , Figure 1 A flowchart illustrating a blockchain-based twin data interaction method according to one embodiment is shown. It is understood that this method can be executed by any device, equipment, platform, device cluster, etc., with computing and processing capabilities. Figure 1 As shown, this blockchain-based twin data interaction method may include the following steps 101 to 104, specifically: Step 101: Construct a registration message based on the pre-established digital twin identity object corresponding to the target entity, and send a registration transaction to the blockchain to call the registration module based on the registration message, so as to trigger the registration module to write the target registration record of the digital twin identity object into the twin registry.

[0038] In this embodiment, a registration message can be constructed based on the digital twin identity object corresponding to the established target entity, and a registration transaction calling the registration module can be sent to the blockchain based on the registration message. This registration transaction can trigger the registration module to write the target registration record of the digital twin identity object into the twin registry.

[0039] In this example, the data structure of each record stored in the on-chain twin registry can be as follows: in, This refers to records in the twin registry. It can represent a digital twin identity. The hash representing the current state of the digital twin object. This indicates the current version number of the off-chain twin state repository. Represents metadata hash, Represents a relational index. Indicates updating the timestamp. Indicates the access strategy for digital twin objects. Indicates a service pointer. Represents the lifecycle state of a digital twin object. A digital signature representing the registered entity.

[0040] It is understood that the above data structure is merely an illustrative description of the contents recorded in each record of the on-chain twin registry, rather than a limitation on the contents recorded in each record. In practice, the contents recorded in each record can be set according to actual needs.

[0041] In this example, the registration transaction may include a digital twin identity, access policy, and service pointers. The access policy refers to the access policy of the digital twin object corresponding to the target entity, and the service pointer can be used to point to the service interface description associated with the digital twin object corresponding to the target entity.

[0042] For example, the initial state of a digital twin object can be constructed based on the initial state: in, It can represent the initial state of a digital twin object. Indicates the initial attribute state. Indicates the initial behavioral state. Indicates the initial environment state. This indicates the initial relational state. This indicates the initial model state of the model involved.

[0043] Normalize the initial state: in, Represents a normalized function. This represents the initial state after normalization.

[0044] Calculate the normalized initial state hash: in, Represents the initial state after normalization. The hash value.

[0045] At the same time, the metadata in the digital twin identity object Perform normalization and calculate metadata hash: in, This represents the metadata hash.

[0046] Constructing registration messages: in, This indicates a registration message. Can represent entities Digital twin identity identifier, Represents the initial state after normalization. hash value, This indicates the current version number of the off-chain twin state repository. Represents metadata hash, Represents a relational index. Indicates updating the timestamp. Indicates the access strategy for digital twin objects. Indicates a service pointer. Representing entities The lifecycle status of the corresponding digital twin object.

[0047] The registrant uses their private key to sign the registration message: in, It can represent the signature of the registration message. This represents the private key. It can represent a signature operation.

[0048] Next, a registration transaction can be sent to the blockchain to invoke the registration module in the smart contract. After receiving the registration transaction, the smart contract performs signature verification: in, This indicates a signature verification operation. Represents the public key. This indicates that the verification has passed.

[0049] After the signature verification is successful, the digital twin identity identifier in the registration message is further examined. Has it been registered on the blockchain? in, This represents the on-chain existence determination function, used to check whether a record already exists in the blockchain. An output of 0 indicates that the product does not exist.

[0050] When the signature verification passes and the digital twin identity is verified Smart contracts allow registration even when not registered on-chain: in, This indicates that the signature verification has passed and the digital twin identity has been verified. Not registered on the blockchain. This indicates on-chain registration.

[0051] After successful registration, a twin registry record is generated on the blockchain: Among them, registration records The 0 in the code represents the current version number of the off-chain twin state repository. The number is 0. Registration records. In Represents lifecycle state for .

[0052] And change the lifecycle state of the digital twin object from (Create) Update to (register): Through this step, the blockchain no longer stores only isolated data hashes, but maintains a trusted on-chain registry for digital twin objects.

[0053] In some examples, a Twin State Repository corresponding to the digital twin identity Twin_ID can be pre-established off-chain. The Twin State Repository can be used to store complete state data, historical versions, sensor data streams, documents, media, and knowledge data of the digital twin object. In this example, the off-chain Twin State Repository can be established as follows: using the digital twin identity as the primary key, an off-chain Twin State Repository with version numbers is created.

[0054] The off-chain twin state repository can store at least one of the following information: the current state of the digital twin object, the historical state set of the digital twin object, sensor data streams, document data, media data, a set of off-chain storage addresses, and a repository version number. The state of the digital twin object includes at least one of the following: attribute state, behavioral state, environmental state, relational state, and the model state of the involved models.

[0055] For example, an off-chain twin state repository, using the digital twin identity Twin_ID as its primary key, can be represented as: in, Indicates the current state of the digital twin object. Represents the set of historical states of a digital twin object. Represents sensor data stream, Represents document data, This refers to media data (e.g., video, audio data, etc.). This refers to data representing a knowledge base, rule base, or the model involved. Represents the set of off-chain storage addresses. Indicates an index. This indicates the version number of the off-chain repository.

[0056] During the initialization phase, the initial state can be written to the off-chain state repository: in, It can represent the initial state of a digital twin object.

[0057] Add the initial state to the history state set: The current version number of the off-chain twin state repository is set to: The off-chain data set can be represented as: in, Represents state data, Represents sensor stream data, Represents document data, Represents media data, This represents knowledge data or model data.

[0058] The system can generate a set of storage addresses for off-chain data objects: Each storage address corresponds to one off-chain data object: in, Indicates the first An off-chain data object, Indicates the first The storage address of each off-chain data object.

[0059] Then, the hash of each data object can be calculated: in, This represents the normalization function.

[0060] Off-chain data object hash set for: When the off-chain twin state repository includes multiple data objects, the system can construct a Merkle root: To support proof of partial data integrity. Among them, It can represent a Merkle root hash value. It can represent the Merkle root calculation function.

[0061] This example demonstrates that off-chain storage is no longer just file or object storage, but a structured repository for the state of digital twin objects.

[0062] In some examples, multidimensional mapping relationships can be established between physical (or business) entities, digital twin identity objects, on-chain registries, off-chain twin state repositories, storage addresses, service interfaces, and access policies.

[0063] For example, this mapping relationship can be represented as: in, Indicates the mapping relationship. Represents a physical (or business) entity. Represents a digital twin identity object. This represents a record in the on-chain registry. This represents an off-chain twin state repository. This represents the set of storage addresses for off-chain data objects. Represents a set of service interfaces. Indicates the access policy.

[0064] The system can also represent the above mapping relationship as a seven-tuple: in, It represents a 7-tuple.

[0065] Based on the established mapping relationship, object-level queries, data location, service discovery, and permission verification can be achieved using the digital twin identity Twin_ID. For example, when an external system submits an access request, the request can carry the digital twin identity Twin_ID, representing the identifier of the requesting user. Operation type Request for signature Information such as these can be used to perform mapping resolution based on the mapping relationship and the Twin_ID in the request. in, Represents a mapping parse function, used to... Query and return Related data.

[0066] Specifically, it includes: in, Indicates according to Retrieve records from the on-chain twin registry , Indicates according to Obtain the off-chain twin state repository , Indicates calling the service resolution function From the records Service pointers Parse the service interface set , Indicates access policy For record Access strategies within.

[0067] Then, permission checks can be performed based on the access policy: in, Indicates user Access policy The set of authorized entities obtained , Indicates from access policy Users obtained List of granted operation permissions Indicates user Granted the authority to perform specific operations Permissions, This represents the authorization determination function. A return value of 1 indicates success, and 0 indicates failure.

[0068] If the permission verification passes, the system can continue to execute the corresponding status query, data access, or service call. If the permission verification fails, the system rejects the request.

[0069] The mapping established in this example allows the system to switch from "data addressing based on hash or URI" to "object addressing based on Twin_ID".

[0070] After writing the target registration record of the digital twin identity object into the on-chain twin registry, the target registration record can also be updated.

[0071] In some examples, the smart contract may also include an update module for updating the registration records in the twin registry. Based on this, the above-mentioned blockchain-based twin data interaction method may also include the following steps (1) to (3), specifically: Step (1): Based on the state data of the target entity collected at the first sampling time, determine the first digital twin state of the digital twin object corresponding to the target entity at the first sampling time.

[0072] In this example, state data of the target entity can be collected from the target entity and related data sources. For example, state data can be collected from data sources including, but not limited to, physical (or business) entities, sensors, edge devices, business systems, and third-party platforms. State data can include, but is not limited to, sensor data, device operation data, environmental data, business events, maintenance records, control commands, or third-party system data. The collected data can then be processed through cleaning, standardization, time alignment, and signature verification.

[0073] For example, suppose at time... The collected raw data is as follows: in, Indicates at time The raw data collected, This represents the second data point in the original dataset.

[0074] The system can clean and standardize the raw data: in, This represents the data cleaning function. Represents the normalized function. This represents the raw data after cleaning and standardization.

[0075] For missing data, interpolation can be used: in, Indicates the first The fields are in The values ​​collected at any given time are not empty. Indicates the first The fields are in The real-time data collection returned an empty value. ), This indicates that the interpolation function is called to use the sampling point before the missing time step. and the next sampling point The valid data is used as input to deduce. Approximate value of time.

[0076] Abnormal data can be identified in the following ways: in, This represents the mean of the data items. Indicates standard deviation, This represents the abnormal threshold coefficient.

[0077] Data acquisition events can be represented as: in, Indicates a data collection event. This represents the raw data after cleaning and standardization. Indicates the data source. Indicates the collection time. This indicates the signature of the data source.

[0078] In this example, the data source signature can be verified to confirm the trustworthiness of the data source. Specifically: in, This indicates a signature verification operation. This represents the public key of the data source.

[0079] Once the verification is successful, the standardized data can be written to the state cache area of ​​the off-chain twin state repository, the sensor stream storage area, or the current state update queue.

[0080] In this example, a digital twin object can be constructed at any time based on standardized data. The digital twin state.

[0081] time The digital twin state can be represented as: in, It can represent time. The state of digital twins, Indicates time The attribute state, Indicates time behavioral state, Indicates time The environmental conditions, Indicates time Relationship status, Indicates time The model state.

[0082] The function for constructing the digital twin state is as follows: in, The function that represents the state of a digital twin. Representing a digital twin model, This indicates the state update rules. Indicates time The previous moment The digital twin state at any given moment.

[0083] In this example, the digital twin model A digital twin model is a pre-constructed digital template describing the essential characteristics of a target entity. It contains a set of static parameters and a description of the runtime logic of the target entity, but does not contain specific state data that changes over time.

[0084] Step (2): Based on the state difference between the first digital twin state and the second digital twin state, determine whether the preset state update conditions are met.

[0085] In this example, the second digital twin state can be the digital twin state corresponding to the previous time step of the first sampling time. Based on the state difference between the first and second digital twin states, it can be determined whether the preset state update conditions are met.

[0086] For example, a change in state can be expressed as: in, Represents the change in state. Indicates time The state of digital twins, express The digital twin state at any given moment.

[0087] It can be further decomposed into: in, express The change in state of the attribute at any given time. express The change in state of behavior at any given moment. express The change in the state of the environment at any given time. express The change in state in relation to time. express The change in state of the model at any given time. In this example, the change in state can also be called the state variability.

[0088] In this example, it can be based on The digital twin state at any moment and The degree of state difference between the digital twin states at any given time is used to determine whether a preset state update condition is met. For example, the state update condition can be set as follows: Time and The state difference between time points is greater than a preset difference threshold.

[0089] In some examples, the state data of the target entity collected at the first sampling time may also include event types. Based on this, the state update conditions may include at least one of the following: the state difference between the first digital twin state and the second digital twin state is greater than a preset difference threshold; the event type belongs to the event types included in the preset set of key events.

[0090] Taking the first sampling time as Taking a specific moment as an example, we can determine whether to trigger a state update based on the degree of state difference: in, This represents the function for calculating the degree of state difference. Indicates the threshold for state change. This represents a set of key events. express Digital twin state at any moment and Digital twin state at any moment The degree of state difference is greater than the state change threshold , Indicates event type Belongs to the set of key events Included event types. 1 indicates an updated status. 0 indicates that the status is not updated.

[0091] The degree of state difference is: in, These represent the differences in attributes, behaviors, environments, relationships, and model states, respectively. , , , , .in, Let be the weighting coefficient, and satisfy: Step (3): When the state update condition is met, based on the first digital twin state, update the pre-established off-chain twin state repository corresponding to the digital twin identity identifier, and send an update transaction to the blockchain to call the update module, so as to trigger the update module to update the target registration record.

[0092] In this example, an off-chain twin state repository can be used to store data for digital twin objects, and update transactions can include the digital twin identity and the hash value of the first digital twin state.

[0093] In this example, a state change event can be generated when the preset state update conditions are met: in, Indicates a state change event. Indicates the event type, Indicates the collection time. Indicates the data source. This indicates the event signature.

[0094] in, Indicates the private key of the data source. Representing the state of a digital twin The hash value.

[0095] This example demonstrates how heterogeneous state data can be transformed into versionable, verifiable, and synchronizeable digital twin states.

[0096] Once a state change event is generated, the off-chain twin state repository update and the on-chain twin registry update can be performed.

[0097] For example, for the new state (i.e., Digital twin state at any moment This can be standardized: in, Represents a normalized function. This represents the result after normalization of the new state.

[0098] Calculate the new state hash: in, This represents the new state hash.

[0099] In addition, a new version number can be generated: in, This indicates the new version number. ( ) indicates the version update rules. This indicates the current version number of the off-chain twin state repository. Indicates the event type.

[0100] In some examples, off-chain twin state repositories can adopt a structure of major version number, minor version number, and revision number, where the version number includes the major version number, minor version number, and revision number. New version numbers can be generated based on event types and preset version update rules.

[0101] Specifically, version numbers can use a triplet structure: in, Indicates the version number. Indicates the major version number. Indicates the minor version number. Indicates the revision number.

[0102] As an example, the version update rule could be: in, This represents the preset main version event set. This represents a predefined set of sub-version events. This represents a pre-defined set of revision events.

[0103] In this example, the old state can be written into the historical state set of the off-chain twin state repository: And write the new state into the current state of the off-chain twin state repository: Update the version number of the off-chain twin state repository: in, This indicates the version number of the off-chain repository.

[0104] Then construct the on-chain update message: in, This indicates an on-chain message update. This represents the new state hash. This indicates the new version number. This represents the new metadata hash. This indicates a new relational index. Represents a timestamp. This indicates a new access policy. This indicates a new service pointer. This indicates the lifecycle state of a digital twin object.

[0105] Then, an update signature can be generated: in, This indicates an update to the signature. This represents the private key.

[0106] Subsequently, an update transaction can be sent to the blockchain based on the constructed on-chain update message, invoking the update module in the smart contract. This update transaction may include the digital twin identity, a new state hash, a new version number of the off-chain twin state repository, and so on.

[0107] After receiving an update transaction, the smart contract can perform an update verification: The above update verification is a joint verification based on multiple conditions. This indicates that the signature verification has passed. Indicates the new version number Greater than the current version number recorded on the chain , Indicates checking the owner Is it authorized to execute? (Update operation).

[0108] When the update verification passes, the update module can update the target registration record in the on-chain twin registry to: And generate an update log: in, This indicates the update log. Indicates the old version number. Indicates the new version number. Represents the old state hash. Represents the hash of the new state. Indicates the operator. Represents a timestamp. This indicates that the signature has been updated.

[0109] In practice, to prevent off-chain writes from succeeding while on-chain updates fail, the system is configured with a synchronization state. : in, This indicates that the submission has been made but not yet confirmed. This indicates that it has been submitted. Indicates failure. This indicates a rollback.

[0110] When off-chain write is complete but on-chain confirmation is not yet available: When the on-chain update is successful: When an on-chain update fails: In this example, a rollback or compensation synchronization can be performed according to a preset strategy.

[0111] In some examples, on-chain and off-chain consistency verification can also be performed. Specifically, the above-mentioned blockchain-based twin data interaction method can also include the following: when the current conditions meet the preset on-chain and off-chain data verification conditions, perform consistency verification on the off-chain data based on the on-chain data in the target registration record.

[0112] In this example, consistency verification includes at least one of the following three types: 1) Read the on-chain state hash from the target registration record of the blockchain, calculate the hash value of the current digital twin state in the off-chain twin state repository to obtain the off-chain state hash, and verify the consistency between the on-chain state hash and the off-chain state hash.

[0113] 2) Read the on-chain repository version number from the target registration record of the blockchain, and read the current repository version number from the off-chain twin state repository as the off-chain repository version number to verify the consistency between the on-chain repository version number and the off-chain repository version number.

[0114] 3) Read the on-chain service pointer from the target registration record of the blockchain, and verify the consistency of the service interface based on the on-chain service pointer and the set of service interfaces associated with the digital twin object.

[0115] For example, on-chain and off-chain data verification conditions may include, but are not limited to, reaching the predetermined verification period at the current time, detecting a predetermined event, receiving an access request, etc.

[0116] In this example, the system periodically, triggered by events, or when an access request occurs, verifies the consistency between the on-chain registration information and the off-chain state repository.

[0117] The current registration information can be read from the blockchain: Retrieve on-chain state hash and version number: in, Represents the on-chain state hash. This indicates the on-chain repository version number.

[0118] Read the current state and version number from the off-chain state repository: in, This represents the current state of the digital twin objects stored in the off-chain twin state repository. This indicates the current repository version number stored in the off-chain twin state repository.

[0119] Calculate the off-chain state hash: in, This represents the hash of the off-chain state.

[0120] The consistency judgment function can be: For service interfaces, further verification can be performed to confirm whether the on-chain service pointer matches the off-chain service endpoint: in, This can represent the registration records in the on-chain twin registry. Service pointers in It can represent a set of service interfaces. This represents the normalization function.

[0121] The overall consistency judgment is as follows: in, This indicates the overall consistency judgment result.

[0122] When the overall consistency is 1, it means that the on-chain registration information, off-chain state data, and service binding information are consistent; when the overall consistency is 0, error types can be identified. in, Indicates the error type. This indicates a hash mismatch. This indicates a version conflict. This indicates a service mismatch. This indicates that the off-chain twin state repository is missing. Indicated by The key cannot be found in the on-chain twin registry. This indicates that the signature is invalid.

[0123] And execute alerts, freezes, resynchronizations, rollbacks, or manual reviews according to preset policies: in, Indicates a repair operation. This represents the repair strategy mapping function. Indicates the error type. This indicates the repair strategy.

[0124] This example demonstrates how to ensure that trusted on-chain registration information remains consistent with actual off-chain state data.

[0125] Step 102: Receive service requests for the digital twin object.

[0126] In this embodiment, when external users, application systems, or third-party platforms need to access the digital twin object, they can send a service request. The service request may include the requesting user's identifier, the digital twin's identity identifier, the service type, and the operation type.

[0127] For example, a service request can be represented as: in, It can represent a service request. Indicates the identifier of the requesting user. Indicates the operation type. Indicates the service type. Indicates the operation parameters. Indicates a request for a timestamp. This indicates a request for a signature.

[0128] Step 103: Send a data query request to the blockchain based on the digital twin identity identifier in the service request.

[0129] In this embodiment, a data query request can be sent to the blockchain based on the digital twin identity identifier in the service request. This data query request can be used to query the access policy and service pointer in the target registration record corresponding to the digital twin identity identifier on the blockchain.

[0130] For example, you can first verify the request signature in the service request: in, This indicates a signature verification operation. This indicates that the user's public key is being requested. This indicates a request for a signature. Indicates the operation type. Indicates the operation parameters. This indicates the request for a timestamp.

[0131] After the signature verification is successful, the on-chain twin registry can be queried based on the Twin_ID: Read access strategy: Read the service pointer: in, Indicates according to Read records from the on-chain twin registry , Indicates access policy For record Access policies in Indicates service pointer For record The service pointer in the middle.

[0132] Step 104: Perform permission verification on the service request according to the access policy returned by the blockchain. If the permission verification is successful, determine and call the target service interface based on the service pointer returned by the blockchain, and return the call result as the service response information of the service request.

[0133] In this embodiment, the service request can be validated based on the access policy returned by the blockchain.

[0134] For example, performing permission checks: in, This represents the authorization determination function. A return value of 1 indicates success, and 0 indicates failure.

[0135] Parsing service interface collection: in: Indicates calling the service resolution function From the records Service pointers Parse the service interface set .

[0136] Among them, REST is used for request-based status queries, MQTT is used for message publish / subscribe, gRPC is used for high-performance remote calls, WebSocket is used for real-time bidirectional communication, and Event Topic is used for event notification and subscription.

[0137] In this example, you can select the service interface based on the request type: in, This indicates the selected service interface.

[0138] In this example, the service matching scoring function can be: in, Indicates the degree of service capability matching. Indicates service availability. Indicates the degree of permission matching. Indicates call delay. This indicates the quality or reliability of the service. , , , , These represent the weights.

[0139] In one implementation, the service selection rule can be expressed as: in, Represents the protocol mapping function; Indicates when the operation type for (Status query) supports both REST and gRPC protocols; This indicates that when the operation type is SubscribeState, either MQTT or WebSocket protocols are supported. This indicates that when the operation type is ListenEvent, the system uses the EventTopic mode.

[0140] This indicates that the gRPC protocol is used when the operation type is InvokeModel (model call).

[0141] This indicates that the REST protocol is used when the operation type is QueryHistory (historical query).

[0142] After the system calls the corresponding service, it can read data from the off-chain twin state repository: in, This indicates the read result from the off-chain twin state repository.

[0143] After reading data from the off-chain twin state repository, the integrity of the data can be verified.

[0144] For complete status queries, the system verifies: in, This represents the current state hash in the registration record of the on-chain twin registry.

[0145] For local state queries, the system can use Merkel proofs: in, This represents the Merkel verification function. The hash value representing local state data. This indicates Merkel's verification path. This represents a Merkle root hash.

[0146] A service response can be represented as: in, It can represent a service response. This indicates the current version number of the off-chain twin state repository. This indicates the result of the service call. Indicates the result hash. Indicates response time. This indicates the system signature.

[0147] This embodiment enables object-level service access based on Twin_ID.

[0148] In some examples, the smart contract may also include a lifecycle management module, which updates the lifecycle state in the registration records of the digital twin registry, thereby performing lifecycle management of the digital twin object. Based on this, the aforementioned blockchain-based digital twin data interaction method may further include the following steps (i) and (ii), specifically: Step (1): In response to the determination that a lifecycle event has occurred, a lifecycle change transaction that calls the lifecycle management module is sent to the blockchain to trigger the lifecycle management module to update the lifecycle status in the target registration record, and after the lifecycle status is updated, the generated lifecycle record is written to the on-chain log. Step (2): In response to the update of the lifecycle state of the digital twin object in the blockchain, update the lifecycle field in the off-chain twin state repository.

[0149] In this example, the occurrence of a predetermined lifecycle event can be detected in real time. If it occurs, a lifecycle change transaction invoking the lifecycle management module is sent to the blockchain. This lifecycle change transaction can include the digital twin identity, the operating entity, the operating entity's public key, the state before the change, the state after the change, and the reason for the change, etc. The lifecycle change transaction can trigger the lifecycle management module to update the lifecycle state in the target registration record.

[0150] In this example, the lifecycle states of a digital twin object can include creation ( ),register( ),activation( ),renew( ),freeze( Cancellation ),recover( ) and termination ( (e.g., ...). This involves trusted management of the processes of creating, registering, activating, updating, freezing, deregistering, restoring, and terminating digital twin objects.

[0151] The lifecycle state set can be represented as: The lifecycle state transition function is: in, This represents the lifecycle state transition function. Represents lifecycle events. Indicates the access policy.

[0152] The state transition rules may include: in, Indicates a registration event. Indicates an activation event. Indicates an update event. Indicates confirmation of the event. Indicates a freeze event. Indicates a recovery event. Indicates a cancellation event. This indicates the termination of the event.

[0153] A lifecycle record can be generated for each lifecycle change: in, It can represent a lifecycle record. Indicates the state before the change. Indicates the state after the change. Indicates the entity performing the operation. Indicate the reason for the operation. Indicates the operation time. This indicates the operation signature.

[0154] Lifecycle operation signatures can be: in, Indicates the lifecycle operation signature. This represents the private key of the entity performing the operation.

[0155] Smart contracts can determine whether lifecycle changes are legal: in: in, The public key representing the entity performing the operation. Used to verify whether a lifecycle change request is initiated by a legitimate operating entity; Indicates the lifecycle operation type. Used to verify whether the operating entity is authorized to perform lifecycle change operations. Used to verify whether the transition from the old state to the new state conforms to the predefined state machine rules.

[0156] Once the lifecycle change is approved, the smart contract updates the on-chain lifecycle state and writes the lifecycle record to the on-chain log. At the same time, the lifecycle field in the off-chain state repository is updated synchronously. And add historical records: in, Indicates historical records.

[0157] This example demonstrates the ability to manage the lifecycle of digital twin objects.

[0158] In summary, this disclosed embodiment combines blockchain, digital twin, distributed storage, and cryptographic technologies to achieve unified identity management, trusted registration, state synchronization, service binding, and full lifecycle governance of digital twin objects in both on-chain and off-chain environments. By constructing a digital twin identity identifier (Twin_ID) as a unified object entry point, and using an on-chain twin registry (Twin Registry) for trusted identity anchoring, and an off-chain twin state repository (Twin StateRepository) for unified organization of state data, this embodiment achieves trusted management and efficient interaction of digital twin objects throughout their creation and termination process through multi-dimensional mapping mechanisms, state synchronization and version management, consistency verification, service binding, and access control. This embodiment can be widely applied to scenarios such as the Industrial Internet, smart manufacturing, smart energy, smart transportation, supply chain management, and urban digital governance, and features object-oriented, trusted, controllable, traceable, and scalable characteristics.

[0159] The foregoing embodiments of the present invention disclose a blockchain-based twin data interaction method. Correspondingly, the present invention also provides a software system that can execute the above method. The system is deployed collaboratively through a multi-layer functional architecture to carry out and automatically execute the various steps of the aforementioned method, realizing multiple functions such as identity establishment of digital twin objects, on-chain registration, state repository establishment, multi-dimensional mapping, state collection, state synchronization / version update, consistency verification, service invocation, and lifecycle management.

[0160] like Figure 2 As shown, Figure 2 An architecture diagram of a blockchain-based twin data interaction system according to one embodiment is shown.

[0161] exist Figure 2 In the example shown, physical entities or business entities can be equipment, production lines, vehicles, energy facilities, sensors, or business systems from scenarios such as the Industrial Internet, smart manufacturing, smart energy, smart transportation, or supply chain collaboration. An on-chain trusted registration environment is built based on blockchain, and an off-chain twin state repository is constructed based on databases, object storage, distributed storage, edge storage, or cloud storage. The digital twin identity identifier Twin_ID serves as a unified entry point, enabling identity registration, state mapping, on-chain and off-chain synchronization, service binding, and full lifecycle management of digital twin objects. In this embodiment, the blockchain-based twin data interaction system can adopt a seven-layer architecture: physical entity and data source layer, data acquisition and state modeling layer, digital twin identity and object management layer, on-chain trusted registration layer, off-chain twin state repository layer, interaction service and access control layer, and application and collaboration management layer. Each layer is described below.

[0162] 1. Physical Entities and Data Source Layer.

[0163] The physical entity and data source layer can be used to access real-world physical entities or business systems, including equipment, production lines, vehicles, energy facilities, sensors, edge nodes, business systems, third-party platforms, and so on. This layer can generate entity attribute data, operational status data, environmental data, business events, maintenance records, control commands, and model calculation results, among other things.

[0164] Let the first The physical or business entities are: Its time The generated raw data can be represented as: in, Indicates the first Class data source at time The generated data.

[0165] 2. Data Acquisition and State Modeling Layer.

[0166] The data acquisition and state modeling layer can be used to collect, clean, standardize, detect anomalies, align time, and model the raw data generated by the physical entity and data source layers, transforming the raw heterogeneous data into a digital twin state.

[0167] The standardized data after processing can be represented as: in, This represents the data cleaning function. This represents the standardized function.

[0168] The data model of a digital twin state can be represented as: in, Indicates the attribute status. Indicates the state of behavior. Indicates the environmental state. Indicates the state of the relationship. This indicates the model state of the model involved.

[0169] 3. Digital twin identity and object management system.

[0170] The digital twin identity and object management layer can be used to generate and maintain the digital twin identity identifier Twin_ID, and manage data such as entity type, owner, metadata, public key, current version, lifecycle status and relationship index of digital twin objects.

[0171] As mentioned earlier, a digital twin identity object can be represented as: Subsequent data storage, state synchronization, service binding, access control, and lifecycle management of the system all use Twin_ID as a unified entry point.

[0172] 4. On-chain trusted registration layer.

[0173] The on-chain trusted registration layer can be deployed in a blockchain or consortium blockchain environment. It maintains the twin registry through smart contracts and can be used to record on-chain trusted information of digital twin objects.

[0174] As mentioned earlier, the registration records stored in the on-chain twin registry can be represented as: in, (Service pointers) can be used to point to the service interface description bound to a digital twin object. The on-chain trusted registration layer can be used to implement trusted registration of digital twin identities, state hash anchoring, version registration, metadata hash registration, access policy registration, service pointer registration, and lifecycle logging.

[0175] 5. Off-chain twin state warehouse layer.

[0176] The off-chain twin state repository layer can be used to store complete data of digital twin objects, including current state, historical state, sensor data streams, document data, media data, knowledge data, model data, and off-chain indexes.

[0177] As mentioned earlier, the off-chain twin state store can be represented as: Unlike traditional off-chain file storage, the off-chain twin state repository layer does not store a single file, but rather organizes the complete state space of the digital twin object using Twin_ID as the primary key.

[0178] 6. Interactive services and access control layer.

[0179] The interaction service and access control layer can be used to complete service binding, service discovery, interface resolution, permission verification, consistency verification and service invocation.

[0180] The set of service interfaces bound to a digital twin object can be represented as: Among them, REST is used for request-based status queries, MQTT is used for message publish / subscribe, gRPC is used for high-performance remote calls, WebSocket is used for real-time bidirectional communication, and Event Topic is used for event notification and subscription.

[0181] 7. Application and Collaboration Management Layer.

[0182] The application and collaboration management layer can be used to provide services to upper-level business scenarios, including equipment monitoring, operation analysis, predictive maintenance, collaborative management, third-party system access, cross-platform sharing, and audit trails.

[0183] When applications and the collaboration management layer initiate access, they do not directly submit data hashes, file URIs, or service addresses, but instead submit Twin_ID. The system automatically parses on-chain registration information, off-chain state repository, service interfaces, and access policies based on the Twin_ID.

[0184] Based on the above seven-layer system architecture, this embodiment can further establish an object-level multidimensional mapping relationship centered on Twin_ID.

[0185] This mapping relationship can be represented as: Or it can be represented as a 7-tuple: in, Represents a physical entity or a business entity. Represents a digital twin identity object. This represents an on-chain twin registry. This represents an off-chain twin state repository. Represents the set of off-chain storage addresses. Represents a set of service interfaces. Indicates the access policy.

[0186] The system's layered architecture emphasizes the functional layers that make up the system, while the multi-dimensional mapping emphasizes how a single digital twin object completes the association between entity, identity, registry, state repository, storage address, service interface, and access policy within the system. Both together form the foundation for the system implementation of this embodiment.

[0187] According to another embodiment, a blockchain-based twin data interaction device is provided. This blockchain-based twin data interaction device can be deployed in any device, platform, or device cluster with computing and processing capabilities. Specifically, a smart contract is deployed on the blockchain, and the contract state of the smart contract stores a twin registry. The smart contract includes a registration module for writing registration records to the twin registry.

[0188] Figure 3 A schematic block diagram of a blockchain-based twin data interaction device according to one embodiment is shown. Figure 3 As shown, the blockchain-based twin data interaction device 300 includes: Registration unit 301 is used to construct a registration message based on the pre-established digital twin identity object corresponding to the target entity, and send a registration transaction to the blockchain to call the registration module based on the registration message, so as to trigger the registration module to write the target registration record of the digital twin identity object in the twin registry. The registration transaction includes digital twin identity identifier, digital twin state state hash, off-chain twin state repository version number, access policy and service pointer. The service pointer is used to point to the service interface description of the service interface associated with the digital twin object corresponding to the target entity. The receiving unit 302 is configured to receive a service request for the aforementioned digital twin object, wherein the service request includes the identifier of the requesting user, the digital twin identity identifier, the service type, and the operation type; The query unit 303 is used to send a data query request to the blockchain based on the digital twin identity identifier in the service request, wherein the data query request is used to query the access policy and service pointer in the target registration record corresponding to the digital twin identity identifier on the blockchain. The response unit 304 is used to perform permission verification on the service request according to the access policy returned by the blockchain. If the permission verification is successful, the target service interface is determined and invoked based on the service pointer returned by the blockchain, and the invocation result is returned as the service response information of the service request.

[0189] According to another embodiment, an electronic device is also provided, including a processor, a memory, and a computer program / instructions stored in the memory, characterized in that the processor is configured to execute the computer program / instructions, and when the computer program / instructions are executed, the electronic device performs the following functions: Figure 1 The steps of the method described.

[0190] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program / instructions are stored, characterized in that, when the computer program / instructions are executed by a processor, they implement as follows: Figure 1 The steps of the method described.

[0191] The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.

[0192] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0193] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0194] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0195] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based twin data interaction method, wherein a smart contract is deployed on the blockchain, the contract state of the smart contract stores a twin registry, the smart contract includes a registration module, the registration module being used to write registration records to the twin registry, the method comprising: A registration message is constructed based on the pre-established digital twin identity object corresponding to the target entity, and a registration transaction invoking the registration module is sent to the blockchain based on the registration message to trigger the registration module to write the target registration record of the digital twin identity object into the twin registry. The registration transaction includes a digital twin identity identifier, a state hash of the digital twin state, a repository version number of the off-chain twin state repository, an access policy, and a service pointer. The service pointer is used to point to the service interface description of the service interface associated with the digital twin object corresponding to the target entity. Receive a service request for the digital twin object, wherein the service request includes the identifier of the requesting user, the digital twin identity identifier, the service type, and the operation type; Based on the digital twin identity identifier in the service request, a data query request is sent to the blockchain, wherein the data query request is used to query the access policy and service pointer in the target registration record corresponding to the digital twin identity identifier on the blockchain; The service request is validated according to the access policy returned by the blockchain. If the validation passes, the target service interface is determined and invoked based on the service pointer returned by the blockchain, and the invocation result is returned as the service response information for the service request.

2. The method according to claim 1, characterized in that, The smart contract further includes an update module, which is used to update the registration records in the twin registry. The method further includes: Based on the state data of the target entity collected at the first sampling time, the first digital twin state of the digital twin object corresponding to the target entity at the first sampling time is determined; Based on the state difference between the first digital twin state and the second digital twin state, it is determined whether the preset state update condition is met, wherein the second digital twin state is the digital twin state corresponding to the previous time of the first sampling time. When the state update condition is met, based on the first digital twin state, the pre-established off-chain twin state repository corresponding to the digital twin identity is updated, and an update transaction calling the update module is sent to the blockchain to trigger the update module to update the target registration record. The off-chain twin state repository is used to store the data of the digital twin object, and the update transaction includes the hash value of the digital twin identity and the first digital twin state.

3. The method according to claim 2, characterized in that, The state data of the target entity collected at the first sampling time includes event types, and the state update condition includes at least one of the following: The difference between the first digital twin state and the second digital twin state is greater than a preset difference threshold; The event type belongs to the event types included in the preset set of key events.

4. The method according to claim 3, characterized in that, The version number of the off-chain twin state repository includes a major version number, a minor version number, and a revision number; the update transaction also includes a new version number of the off-chain twin state repository; the new version number is generated in the following way: A new version number is generated based on the event type and the preset version update rules.

5. The method according to claim 1, characterized in that, in, The target registration record includes a digital twin identity identifier, a status hash, a repository version number, an access policy, and a service pointer; Furthermore, the method further includes: When the current conditions meet the preset on-chain and off-chain data verification conditions, the off-chain data is verified for consistency based on the on-chain data in the target registration record, wherein the consistency verification includes at least one of the following: Read the on-chain state hash from the target registration record of the blockchain, calculate the hash value of the current digital twin state in the off-chain twin state repository to obtain the off-chain state hash, and verify the consistency between the on-chain state hash and the off-chain state hash; Read the on-chain repository version number from the target registration record of the blockchain, read the current repository version number from the off-chain twin state repository as the off-chain repository version number, and verify the consistency between the on-chain repository version number and the off-chain repository version number; Read on-chain service pointers from the target registration records of the blockchain, and verify the consistency of the service interfaces based on the on-chain service pointers and the set of service interfaces associated with the digital twin object.

6. The method according to claim 1, characterized in that, The registration transaction also includes the lifecycle state of the digital twin object, and the target registration record includes the lifecycle state; the smart contract also includes a lifecycle management module, which is used to update the lifecycle state in the registration record of the digital twin registry; the method further includes: In response to the determination that a lifecycle event has occurred, a lifecycle change transaction that invokes the lifecycle management module is sent to the blockchain to trigger the lifecycle management module to update the lifecycle status in the target registration record, and after the lifecycle status is updated, a lifecycle record is generated and written to the on-chain log. The lifecycle change transaction includes the digital twin identity identifier, the operating subject, the operating subject public key, the state before the change, the state after the change, and the reason for the operation. In response to an update to the lifecycle state of the digital twin object in the blockchain, the lifecycle field in the off-chain twin state repository is updated.

7. The method according to claim 1, characterized in that, The off-chain twin state repository is established in the following way: Using the digital twin identity as the primary key, an off-chain twin state repository with a version number is established. This off-chain twin state repository stores at least one of the following: the current state of the digital twin object, a set of historical states of the digital twin object, sensor data streams, document data, media data, a set of off-chain storage addresses, and a repository version number. The state of a digital twin object includes at least one of the following: attribute state, behavior state, environment state, relationship state, and model state of the model involved.

8. The method according to claim 1, characterized in that, The digital twin identity object is established in the following way: Based on a preset hash algorithm and various first-related information of the target entity, a digital twin identity of the target entity is generated, wherein the various first-related information includes at least one of the following: entity type, owner, public key, entity attribute digest, and creation time; The digital twin identity identifier and various secondary related information of the target entity are encapsulated according to a preset data structure to generate the digital twin identity object. The various secondary related information includes at least one of the following: entity type, owner, metadata, public key, repository version number, lifecycle status, and relationship index.

9. An electronic device comprising a processor, a memory, and a computer program / instructions stored in the memory, characterized in that, The processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the electronic device implements the steps of the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 8.

Images