A detection method and device based on a data risk prevention and control probe

Abstract

The embodiment of the specification discloses a detection method based on a data risk prevention and control probe, obtains event data to be chained corresponding to an offline device, and obtains state data of the offline device collected by an SDK integrated in the offline device, determines an event period of an event corresponding to the event data according to the event data, further determines a detection period according to the event period, detects the authenticity of the event data to be chained according to the state data collected by the SDK in the detection period, and at least chains and stores the event data when the detection is passed. Through the above method, the authenticity of the event data to be chained can be detected according to the state data of the offline device collected by the SDK integrated in the offline device before the event data to be chained is chained, so that the authenticity and reliability of the chained event data are ensured.

Description

[0001] This application claims priority to patent application No. 202511279030.5, entitled "A detection method and device for risk prevention and control probe based on RWA data". Technical Field

[0002] This specification relates to the field of computer technology, and in particular to a detection method and apparatus based on a data risk prevention and control probe. Background Technology

[0003] With the development of blockchain technology, blockchain systems can now empower various fields, and tokenized assets are a typical example of applying blockchain systems to financial business.

[0004] Tokenized assets refer to tangible or intangible assets existing in the physical world or traditional financial system that are tokenized through blockchain technology, thereby circulating, trading, or serving as collateral in the crypto market. Its core is to fully digitize and record the value attributes of traditional assets on the blockchain; that is, to transform traditional assets into twin data assets and store them on the blockchain system.

[0005] However, although blockchain systems have characteristics such as tamper-proof and traceability, and the security of data assets can be guaranteed after they are uploaded to the chain, the authenticity of data assets before they are uploaded to the chain is difficult to detect. Therefore, how to detect the authenticity of data assets before they are uploaded to the chain is an urgent problem to be solved. Summary of the Invention

[0006] This specification provides a detection method, apparatus, storage medium, and electronic device based on a data risk prevention and control probe, in order to partially solve the problems existing in the prior art.

[0007] The embodiments in this specification adopt the following technical solutions: This specification provides a detection method based on a data risk prevention probe, which pre-deploys an SDK in offline devices for collecting status data of the offline devices; the method includes: Obtain event data corresponding to events occurring on the offline devices uploaded by the first user through the data collection platform, and obtain status data of the offline devices collected by the SDK; Based on the event data, determine the event time period corresponding to the event data; The detection period is determined based on the event time period; The authenticity of the event data is verified by the SDK based on the status data of the offline devices collected during the detection period, and the event data is stored in the blockchain system at least when the detection is passed.

[0008] This specification provides a detection device based on a data risk prevention probe, which pre-deploys an SDK in offline devices for collecting status data of the offline devices; the device includes: The acquisition module is used to acquire event data corresponding to events occurring on the offline device uploaded by the first user through the data acquisition platform, and to acquire status data of the offline device collected by the SDK. The first determining module is used to determine the event time period of the event corresponding to the event data based on the event data; The second determining module is used to determine the detection period based on the event period; The detection module is used to detect the authenticity of the event data based on the status data of the offline devices collected by the SDK during the detection period, and to store the event data into the blockchain system at least when the detection is passed.

[0009] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned detection method based on a data risk prevention probe.

[0010] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described detection method based on a data risk prevention probe.

[0011] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: This specification discloses a detection method based on a data risk prevention probe. The method involves acquiring event data to be uploaded to the blockchain from offline devices, and acquiring status data of the offline devices collected by an SDK integrated within those devices. The method determines the event time period corresponding to the event data, then determines a detection time period based on the event time period. Based on the status data collected by the SDK within this detection time period, the authenticity of the event data to be uploaded to the blockchain is verified. If the verification passes, the event data is at least uploaded to the blockchain for storage. Through this method, the authenticity of the event data to be uploaded to the blockchain can be verified based on the status data of the offline devices collected by the SDK integrated within the offline devices before the event data is uploaded, ensuring the authenticity and reliability of the uploaded event data. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1This is a schematic diagram of a token asset business system provided in the embodiments of this specification; Figure 2 A flowchart of a data authenticity detection method provided in the embodiments of this specification; Figure 3 A schematic diagram of the data authenticity detection device provided in the embodiments of this specification; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0014] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0015] Figure 1 This is a schematic diagram of the token asset business system provided in the embodiments of this specification, such as... Figure 1 As shown, in the token asset business scenario, there are three main roles: the first user, the blockchain system, and the second user.

[0016] The first user is a user who owns offline devices or has at least partial control over offline devices. These offline devices are the first user's offline assets in the real physical world. The first user needs to convert the offline devices into data assets and put them on the blockchain.

[0017] A blockchain system is a decentralized or weakly centralized database used to store the data assets of a first user and to allocate tokens (referred to as virtual resources in this specification) used by the blockchain system to the first user based on those data assets. The more and higher quality the first user's data assets, the more virtual resources the blockchain system allocates to the first user, and vice versa. To protect the first user's data assets, in the embodiments of this specification, the blockchain system does not directly disclose the stored data assets of the first user to the second users on the blockchain system. Instead, it displays the virtual resources allocated to the first user to the second users on the blockchain system.

[0018] A second user is a user who conducts financial transactions with the first user based on the first user's data assets. The second user can understand the quantity and quality of the first user's offline assets in the real world based on the virtual resources disclosed by the blockchain system, and conduct the necessary financial transactions with the first user accordingly. The financial transactions described in the embodiments of this specification include, but are not limited to: transactions, mortgages, and financing.

[0019] Taking financing as an example, financing refers to providing the first user with real-world resources, including funds, in the physical world. The second user can roughly understand the first user's offline assets based on the virtual resources disclosed by the blockchain system, and decide whether to provide the first user with real resources, and how much real resources to provide.

[0020] In the aforementioned scenario of financing through tokenized assets, the first user often needs to upload data assets corresponding to their own offline equipment through a data collection platform. While the blockchain system can guarantee the security of stored data, it cannot determine the authenticity of the data assets uploaded by the first user. For example, suppose the first user's offline equipment is a production line for manufacturing a certain product. If the production line is dilapidated or even inoperable, but the data assets reported by the first user indicate that the production line is a high-quality and operational line, then storing this data asset on the blockchain would inevitably mislead the second user, who may be the financing party, potentially causing them significant losses. Therefore, this specification provides a data authenticity detection method to verify the authenticity of the first user's data assets before storing them on the blockchain. Figure 2 As shown.

[0021] Figure 2 A flowchart of a detection method based on a data risk prevention probe, provided for embodiments of this specification, specifically includes the following steps: S200: Obtain event data corresponding to events occurring on offline devices uploaded by the first user through the data collection platform, and obtain the status data of the offline devices collected by the SDK.

[0022] In the embodiments of this specification, the following are used: Figure 2 The device used for data authenticity verification as shown in this specification can be any electronic device, including servers, clusters of multiple servers, personal computers, mobile phones, tablets, etc. This device can be the same device as the device carrying the data acquisition platform, or it can be a different device; this specification does not impose any restrictions on this. The device used for data authenticity verification will be referred to as the verification device below.

[0023] Typically, a data acquisition platform collects event data corresponding to events occurring on offline devices, as input by the first user, and then uploads it to a blockchain system for storage. However, since the authenticity of the event data input by the first user is difficult to verify, after the data acquisition platform collects the event data input by the first user, the detection device can retrieve the event data corresponding to the events occurring on the offline devices input by the first user from the data acquisition platform.

[0024] The event data can be data corresponding to any event that occurs during the normal use of the offline device. For example, when the first user's offline device is an electric vehicle used for ride-hailing operations, the event data of the electric vehicle can include any one or more of the following: data corresponding to receiving an order, data corresponding to completing an order, data corresponding to charging events, and data corresponding to other abnormal driving events.

[0025] Additionally, in the embodiments of this specification, a Software Development Kit (SDK) for collecting status data of the offline device can be integrated into the offline device. The SDK can be pre-downloaded to the offline device via over-the-air (OTA) or similar methods, allowing the offline device to integrate the SDK. The SDK can then collect the status data of the offline device and send it directly to the detection device. Furthermore, the SDK can also be integrated into associated devices of the first user that perform the same business as the offline device, for collecting status data from those associated devices, which also serve as status data for the offline device.

[0026] Specifically, the SDK can periodically collect the status data of the offline device and send it to the testing device, which can then receive the status data of the offline device periodically collected and sent by the SDK.

[0027] The aforementioned status data characterizes the status of the offline device, any one or more components within the offline device, and associated devices that work together with the offline device to perform the same service. Continuing with the previous example, when the first user's offline device is an electric vehicle used for ride-hailing operations, the status data collected by the SDK integrated into the electric vehicle may include: the battery status data, the driving status data, and the order-accepting status data. The order-accepting status data can be collected through the SDK integrated into the dispatch system that works with the electric vehicle to perform the ride-hailing service.

[0028] S202: Based on the event data, determine the event time period corresponding to the event data.

[0029] After acquiring event data and status data corresponding to the offline devices, the detection equipment can determine the event time period corresponding to the event data based on the event data. Here, the event time period mentioned in the embodiments of this specification refers to the time period during which the event corresponding to the event data occurred.

[0030] Specifically, the detection equipment can determine the occurrence and end times of the event corresponding to the event data based on the event data, and define the time period between the occurrence and end times as the event time period.

[0031] S204: Determine the detection period based on the event period.

[0032] After determining the event time period, the detection equipment can determine the detection time period based on that event time period. Specifically, the detection equipment can determine the detection time period based on the start time (i.e., the time when the event data corresponds to the occurrence of the event), the end time, and any time within the event time period, or the entire event time period and any one or more of the event time periods. The detection time period is the neighborhood time period of the event time period. Specifically, it can be the neighborhood time period of a specified time within the event time period (the neighborhood time period includes the specified time), or it can be the neighborhood time period of a part or all of the event time period (the neighborhood time period includes the part or all of the event time periods).

[0033] For example, the detection equipment can determine the domain period of the start time of the event period as the detection period. However, the domain period does not necessarily fall entirely within the event period. For instance, the domain period of the start time can be defined as the period from 5 seconds before the start time to 5 seconds after the start time.

[0034] S206: Based on the status data of the offline devices collected by the SDK during the detection period, the authenticity of the event data is detected, and when the detection is passed, the event data is stored in the blockchain system at least once.

[0035] In this embodiment, the authenticity of the event data uploaded by the first user is questionable, but the status data of the offline device collected by the SDK can be considered authentic. When an event occurs on an offline device, the status data of the offline device during the event period or a period before and after the event period can usually reflect the occurrence of the event. Therefore, the detection device can use the status data of the offline device collected by the SDK during the detection period to detect the authenticity of the event data uploaded by the first user. Specifically, the detection device can determine whether the status data of the offline device collected by the SDK during the detection period matches the event data uploaded by the first user. That is, whether the status data of the offline device collected by the SDK during the detection period can reflect that the offline device has experienced the event corresponding to the event data uploaded by the first user. If they match, the event data is determined to be authentic; otherwise, the event data is determined to be authentic. When the event data is detected to be authentic, it can at least be stored in the blockchain system; if the event data is detected to be authentic, it can be refused to be stored in the blockchain system.

[0036] Specifically, when verifying the authenticity of event data, the detection equipment can first determine the type information of the offline device. This type information, as described in this specification, includes the device type information of the offline device itself and the service type information of the service performed by the first user using the offline device.

[0037] Once the type information of the offline device is determined, a preset detection rule can be determined based on this type information. Then, based on the detection rule, data input parameters can be extracted from the event data and the status data of the offline device collected by the SDK during the detection period. Finally, the authenticity of the event data can be detected based on the extracted data input parameters.

[0038] The aforementioned detection rules specify the data input parameters that need to be detected in event data and status data, as well as the detection methods for these data input parameters. Continuing with the previous example, when the first user's offline device is an electric vehicle used for ride-hailing operations, the type information of this offline device is the ride-hailing service type. The data input parameters specified in the detection rules pre-set for this ride-hailing service type may include: for the event data corresponding to the order receiving event, the data input parameters to be detected are the number of orders received, the receiving time and end time of each order, the origin and destination of each order, the mileage of each order, and the amount generated by each order; while for the status data, the data input parameters to be detected are the vehicle order acceptance status, remaining battery power, cumulative mileage, vehicle speed, GPS positioning, etc., at any time during the detection period collected by the SDK.

[0039] The detection methods in the detection rules may include: whether the number of orders in the event data matches the total number of order status changes in the status data, whether the origin and destination in the event data match the GPS location in the status data, whether the mileage of each order in the event data matches the cumulative mileage in the status data, and whether the amount corresponding to each order in the event data matches the amount received for each order in the status data, etc.

[0040] The detection equipment can use the detection methods in the above detection rules to match and detect the extracted data input parameters in order to determine whether the event data is real.

[0041] Using the above method, the testing device can detect the authenticity of the event data to be uploaded to the blockchain based on the status data of the offline device collected by the SDK integrated in the offline device, before the event data is uploaded to the blockchain, thus ensuring that the event data uploaded to the blockchain is authentic and reliable.

[0042] Furthermore, the aforementioned pre-defined detection rules for each type of information can all be generated using a Large Language Model (LLM) without manual configuration. Specifically, for each type of information, sample event data corresponding to events occurring on offline devices belonging to that type of information can be pre-acquired, along with sample status data of the offline devices collected by the SDK deployed on those devices. This type of information, sample event data, and sample status data are then input into a pre-trained LLM, along with a prompt message. Guided by this prompt message, the LLM generates detection rules that utilize the sample status data of the offline devices to detect the authenticity of the sample event data. Specifically, the prompt message guides the LLM in generating these detection rules.

[0043] Furthermore, this manual provides corresponding authenticity detection methods for different types of data input parameters in event data and state data. These different types of data input parameters include: discrete variables that are discrete in the time dimension, monotonically continuous variables that change monotonically in the time dimension, and non-monotonic continuous variables that do not change monotonically in the time dimension.

[0044] For the aforementioned discrete variables, the detection device can employ an equivalent comparison method to verify the authenticity of the event data. Specifically, the detection device can determine whether the state data collected by the SDK within the detection period determined in step S204 is a discrete variable. The discrete variable refers to a time-discrete variable collected by the SDK triggered by an event corresponding to the event data uploaded by the first user in step S200 occurring on the offline device. If the offline device does not experience this event, the SDK cannot collect this discrete variable as state data during the detection period. The detection device can determine whether the state data collected within the detection period is a discrete variable based on preset state data type judgment rules. If the state data collected by the SDK within the detection period is a discrete variable, the detection device can determine the event occurrence quantity corresponding to the event data uploaded by the first user in step S200. If the discrete variable matches the event occurrence quantity, the authenticity detection of the event data is deemed successful; if the discrete variable does not match the event occurrence quantity, the authenticity detection of the event data is deemed unsuccessful. The event occurrence quantity refers to the value of the variable corresponding to the event contained in the event data uploaded by the first user. If the difference between the event occurrence quantity and the discrete variable is within a preset range, the two match; otherwise, they do not match.

[0045] For example, when the first user's offline device is an electric vehicle used for ride-hailing operations, the discrete variables that are discrete in the time dimension may include the order number and the order amount of the order received by the electric vehicle (because the order number and the order amount are not continuous in time and are discrete variables). Therefore, when the SDK collects order data with a certain amount added during the detection period, the detection device can determine whether the event occurrence quantity (i.e., order amount and order number) of the new order corresponding to the event period of the new order uploaded by the first user is consistent with the discrete variables collected by the SDK after determining that the order data used as status data is a discrete variable. If they are inconsistent, it can be determined that the event data corresponding to the new order uploaded by the first user is not real.

[0046] For the aforementioned monotonically continuous variables, the detection device can use a change comparison method to verify the authenticity of the event data. Specifically, if the detection device determines that the state data collected by the SDK during the detection period is not a discrete variable triggered by the occurrence of the aforementioned event on the offline device, then it can be determined that the state data collected by the SDK must be a continuous variable that needs to be collected periodically. This continuous variable is not triggered by the occurrence of the aforementioned event on the offline device. Therefore, the detection device can determine whether the state data is a monotonically continuous variable that changes monotonically over time. The detection device can also determine whether the state data collected during the detection period is a monotonically continuous variable based on preset state data type judgment rules, or it can determine whether the state data consistently increases or decreases across all time periods based on the state data collected by the SDK in all time periods. If so, the state data is determined to be a monotonically continuous variable; otherwise, it is determined to be a non-monotonic continuous variable.

[0047] When the detection equipment determines that the status data collected by the SDK during the detection period is a monotonically continuous variable, it determines the event occurrence quantity corresponding to the event data uploaded by the first user in step S200, and determines the change quantity of this monotonically continuous variable during the detection period. If the change quantity matches the event occurrence quantity, the authenticity detection of the event data is deemed to have passed; if the change quantity does not match the event occurrence quantity, the authenticity detection of the event data is deemed to have failed. If the difference between the change quantity and the event occurrence quantity is within a preset range, then they match; otherwise, they do not match.

[0048] For example, when the first user's offline device is an electric vehicle used for ride-hailing operations, the monotonically continuous variable that changes monotonically over time can include the cumulative power consumption of the electric vehicle (because the cumulative power consumption of an electric vehicle is always a monotonically increasing continuous variable). Therefore, when the status data collected by the SDK is the cumulative power consumption of the electric vehicle, the detection device can determine that the status data is a monotonically continuous variable. If the event data uploaded by the first user corresponds to an event in which the electric vehicle drives to execute a received order within a certain event period, the detection device can take the power consumed during the driving process contained in the event data as the event occurrence quantity, and determine whether the change in the cumulative power consumption of the electric vehicle contained in the status data collected by the SDK within the corresponding detection period matches the event occurrence quantity. If they match, it can be determined that the event data corresponding to the driving event of the electric vehicle is real; if they do not match, it can be determined that the event data corresponding to the driving event of the electric vehicle is not real.

[0049] For the aforementioned non-monotonic continuous variables, the detection equipment can employ trend comparison to verify the authenticity of the event data. Specifically, when the detection equipment determines that the state data is not a monotonic continuous variable but a non-monotonic continuous variable, it can determine whether the change in the trend of the state data was triggered by the aforementioned event occurring at the offline device. Furthermore, the detection equipment can still determine whether the change in the trend of the state data collected during the detection period was triggered by the aforementioned event occurring at the offline device, based on preset state data type judgment rules.

[0050] If the change in the trend of the status data is determined to be triggered by the aforementioned event occurring on an offline device, the detection device can determine the event occurrence volume corresponding to the event data uploaded by the first user in step S200. It will determine whether the trend of the status data collected by the SDK changes at the start and end of the detection period, and whether the change in the status data during the detection period matches the event occurrence volume. When the trend of the status data changes at the start and end of the detection period, and the change in the status data during the detection period matches the event occurrence volume, the authenticity detection of the event data is deemed successful. When at least one of the trends of the status data at the start and end of the detection period remains unchanged, or when the change in the status data during the detection period does not match the event occurrence volume, the authenticity detection of the event data is deemed unsuccessful. If the difference between the change volume and the event occurrence volume is within a preset range, they match; otherwise, they do not match.

[0051] For example, when the first user's offline device is an electric vehicle used for ride-hailing operations, non-monotonic continuous variables that are not monotonically continuous in the time dimension may include the remaining battery power of the electric vehicle (this is because the remaining battery power of the electric vehicle will continuously and monotonically increase when charging, and continuously and monotonically decrease when driving, thus it is a non-monotonic continuous variable). Therefore, when the event data uploaded by the first user includes events in which the electric vehicle drives to execute received orders within a certain event period, the detection device can determine whether the trend of the remaining battery power collected by the SDK has changed at the beginning and end of the detection period corresponding to the event period, and determine whether the power consumption of the electric vehicle in the event (i.e., the amount of event occurrence) matches the amount of change of the remaining battery power in the detection period. If both judgment results are yes, it can be determined that the event data corresponding to the driving event of the electric vehicle is real; if at least one judgment result is no, it can be determined that the event data corresponding to the driving event of the electric vehicle is not real.

[0052] Since the event data and the state data collected by the SDK during the corresponding detection period may simultaneously contain one or more of the aforementioned discrete variables, monotonic continuous variables, and non-monotonic continuous variables for the same event, the detection device can apply the corresponding methods described above to perform authenticity checks on the event data for each type of variable. Only when all authenticity checks performed on the event data for the event based on all types of state data collected by the SDK using the above methods pass can the event data be determined to be authentic. Conversely, if the authenticity check fails for at least one variable, the event data for the event is determined to be unauthentic.

[0053] When the detection equipment confirms that the authenticity of the event data uploaded by the first user through the data acquisition platform has been verified, the event data and status data corresponding to the offline equipment can be stored in the blockchain system as the first user's data assets. The blockchain system can then allocate virtual resources to the first user based on the first user's data assets and publicize the first user's virtual resources to some or all other users on the blockchain system, i.e., the second users. The second users can then determine whether to provide actual resources to the first user, i.e., whether to provide financing to the first user, based on the virtual resources publicized by the blockchain system.

[0054] In addition to storing the first user's data assets in the blockchain system, the detection results and / or detection process of verifying the authenticity of the event data in the stored data assets can also be stored in the blockchain system. The stored detection results and / or detection process can be made public to the second user who provides the actual resources to the first user, so that the second user can know the specific data in the first user's data assets as well as the detection process and detection results before the data assets are put on the blockchain.

[0055] In addition, the blockchain system can also store simulated event data and simulated state data corresponding to simulated offline devices, and the detection process (hereinafter referred to as the simulation detection process) that uses the simulated state data to detect the authenticity of the simulated event data using the above method is also stored in the blockchain system. The stored simulation detection process can also be made public to all users on the blockchain system, so that all users can know that all data assets stored on the chain have been tested for authenticity by the above method based on the publicized simulation detection process.

[0056] In addition, when the status data of the offline device collected by the SDK contains data indicating that the offline device has malfunctioned, the above method may still not be able to accurately detect the authenticity of the event data uploaded by the first user. Therefore, the detection device can notify the first user to eliminate the malfunction of the offline device, and then continue to detect the authenticity of the event data after the malfunction is eliminated.

[0057] The above is a detection method based on a data risk prevention probe provided in the embodiments of this specification. Based on the same idea, this specification also provides corresponding devices, storage media and electronic devices.

[0058] Figure 3 This is a schematic diagram of a detection device based on a data risk prevention probe provided in an embodiment of this specification. An SDK for collecting status data of the offline device is pre-deployed in the offline equipment. The device includes: The acquisition module 301 is used to acquire event data corresponding to events occurring on the offline device uploaded by the first user through the data acquisition platform, and to acquire status data of the offline device collected by the SDK. The first determining module 302 is used to determine the event time period of the event corresponding to the event data based on the event data; The second determining module 303 is used to determine the detection period based on the event period; The detection module 304 is used to detect the authenticity of the event data based on the status data of the offline device collected by the SDK during the detection period, and to store the event data into the blockchain system at least when the detection is passed.

[0059] Optionally, the detection module 304 is specifically used to: determine the type information of the offline device; determine a preset detection rule for the type information based on the type information; extract data input parameters from the event data and the status data of the offline device collected by the SDK during the detection period based on the detection rule; and detect the authenticity of the event data based on the extracted data input parameters.

[0060] Optionally, the detection module 304 is further configured to, before detecting the authenticity of the event data, acquire sample event data corresponding to events occurring on the sample offline device belonging to the type information, and sample status data of the sample offline device collected by the SDK deployed on the sample offline device; input the type information, the sample event data, and the sample status data into a pre-trained Large Language Model (LLM), and input prompt information into the LLM, so that the LLM, guided by the prompt information, generates detection rules for detecting the authenticity of the sample event data of the sample offline device using the sample status data of the sample offline device.

[0061] Optionally, the detection module 304 is specifically used to determine whether the status data collected by the SDK during the detection period is a discrete variable in the time dimension that is triggered by the event occurring on the offline device; if so, the event occurrence quantity corresponding to the event data is determined, and when the discrete variable matches the event occurrence quantity, the authenticity detection of the event data is determined to be passed; when the discrete variable does not match the event occurrence quantity, the authenticity detection of the event data is determined to be failed.

[0062] Optionally, the detection module 304 is further configured to: if the status data collected by the SDK during the detection period is not a discrete variable collected by the SDK triggered by the event occurring on the offline device, then determine whether the status data is a monotonically changing continuous variable in the time dimension; if it is a monotonically continuous variable, then determine the event occurrence quantity corresponding to the event data, and determine the change quantity of the monotonically continuous variable during the detection period; when the change quantity matches the event occurrence quantity, determine that the authenticity detection of the event data has passed; when the change quantity does not match the event occurrence quantity, determine that the authenticity detection of the event data has failed.

[0063] Optionally, the detection module 304 is further configured to: if the state data is not a monotonically continuous variable, determine whether the change in the trend of the state data is triggered by the event occurring on the offline device; if the change in the trend of the state data is triggered by the event occurring on the offline device, determine the event occurrence quantity corresponding to the event data; when the change in the trend of the state data changes at the start and end of the detection period, and the change in the state data during the detection period matches the event occurrence quantity, determine that the authenticity detection of the event data passes; when at least one of the change trends of the state data at the start and end of the detection period does not change, or when the change in the state data during the detection period does not match the event occurrence quantity, determine that the authenticity detection of the event data fails.

[0064] Optionally, the detection module 304 is specifically used to store the event data and status data corresponding to the offline device as the data assets of the first user into the blockchain system, so that the blockchain system allocates virtual resources to the first user based on the data assets of the first user; wherein, the virtual resources of the first user on the blockchain are used to display to each second user on the blockchain system, so that each second user provides actual resources to the first user based on the displayed virtual resources of the first user.

[0065] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the data authenticity detection method provided above.

[0066] based on Figure 2 The detection method based on data risk prevention probes shown in this specification also provides embodiments. Figure 4 The diagram shows the structure of the electronic device. Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the aforementioned detection method based on data risk prevention probes.

[0067] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A detection method based on a data risk prevention probe, comprising pre-deploying an SDK in an offline device for collecting status data of the offline device; the method comprising: Obtain event data corresponding to events occurring on the offline devices uploaded by the first user through the data collection platform, and obtain status data of the offline devices collected by the SDK; Based on the event data, determine the event time period corresponding to the event data; The detection period is determined based on the event time period; The authenticity of the event data is verified by the SDK based on the status data of the offline devices collected during the detection period, and the event data is stored in the blockchain system at least when the detection is passed.

2. The method as described in claim 1, wherein the authenticity of the event data is detected based on the status data of the offline device collected by the SDK during the detection period, specifically including: Determine the type information of the offline device; Based on the type information, determine the preset detection rules for the type information; According to the detection rules, data parameters are extracted from the event data and the status data of the offline devices collected by the SDK during the detection period; The authenticity of the event data is verified based on the extracted data input parameters.

3. The method as described in claim 2, further comprising, before detecting the authenticity of the event data: Obtain sample event data corresponding to events occurring on the sample offline device that belong to the type information, and sample status data of the sample offline device collected by the SDK deployed on the sample offline device; The type information, the sample event data, and the sample state data are input into a pre-trained large language model (LLM), and prompt information is input into the LLM. Guided by the prompt information, the LLM generates detection rules to detect the authenticity of the sample event data of the sample offline device using the sample state data of the sample offline device.

4. The method as described in claim 1, wherein the authenticity of the event data is detected based on the status data of the offline device collected by the SDK during the detection period, specifically including: Determine whether the status data collected by the SDK during the detection period is a discrete variable in the time dimension that is triggered by the event occurring on the offline device and collected by the SDK. If so, the event occurrence quantity corresponding to the event data is determined, and when the discrete variable matches the event occurrence quantity, the authenticity detection of the event data is determined to have passed; when the discrete variable does not match the event occurrence quantity, the authenticity detection of the event data is determined to have failed.

5. The method of claim 4, further comprising: If the state data collected by the SDK during the detection period is not a discrete variable collected by the SDK triggered by the event occurring on the offline device, then it is determined whether the state data is a monotonically continuous variable that changes monotonically in the time dimension. If it is a monotonically continuous variable, then determine the event occurrence quantity corresponding to the event data, and determine the change quantity of the monotonically continuous variable during the detection period. When the change quantity matches the event occurrence quantity, the authenticity detection of the event data is determined to pass. When the change quantity does not match the event occurrence quantity, the authenticity detection of the event data is determined to fail.

6. The method of claim 5, further comprising: If the state data is not a monotonically continuous variable, then determine whether the change in the trend of the state data is triggered by the event occurring in the offline device; If the change in the trend of the status data is triggered by the event occurring on the offline device, then the event occurrence quantity corresponding to the event data is determined; When the trend of the change of the status data changes at the start and end of the detection period, and the amount of change of the status data during the detection period matches the amount of event occurrence, the authenticity detection of the event data is determined to be passed. If at least one of the trends in the change of the status data at the start and end of the detection period remains unchanged, or if the change in the status data during the detection period does not match the event occurrence rate, the authenticity detection of the event data is determined to fail.

7. The method as described in any one of claims 1 to 6, wherein at least the event data is stored in a blockchain system, specifically including: The event data and status data corresponding to the offline devices are stored in the blockchain system as the data assets of the first user, so that the blockchain system can allocate virtual resources to the first user based on the data assets of the first user. The virtual resources of the first user on the blockchain are displayed to each second user on the blockchain system, so that each second user provides actual resources to the first user based on the virtual resources displayed to the first user.

8. A detection device based on a data risk prevention and control probe, wherein an SDK for collecting status data of the offline equipment is pre-deployed in the offline equipment; the device comprises: The acquisition module is used to acquire event data corresponding to events occurring on the offline device uploaded by the first user through the data acquisition platform, and to acquire status data of the offline device collected by the SDK. The first determining module is used to determine the event time period of the event corresponding to the event data based on the event data; The second determining module is used to determine the detection period based on the event period; The detection module is used to detect the authenticity of the event data based on the status data of the offline devices collected by the SDK during the detection period, and to store the event data into the blockchain system at least when the detection is passed.

9. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method according to any one of claims 1-7.

Images