Blockchain-based device verification system

Abstract

This specification provides an embodiment of a blockchain-based device verification system, which includes: a first device that uploads device information associated with a target device to the blockchain; a second device that publishes a smart contract on the blockchain, the smart contract being used to determine whether the target device meets acceptance requirements; the target device, upon its first run, acquires the device information on the blockchain and performs a self-check based on the device information to obtain a self-check result; the self-check result is used as a parameter to call the smart contract to perform device acceptance, and the result after executing the smart contract is recorded on the blockchain as the acceptance result.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of blockchain technology, and in particular to a blockchain-based device verification system. Background Technology

[0002] With the development of computer technology, chip modules are being used in an increasing number of scenarios. As core components of IoT devices, chip modules have very high physical and technological value. Therefore, after the migration of a system carrying a chip module, the system needs to be verified to determine whether the chip module can be used normally. The verification phase often requires the actual system carrying the chip module to be running to verify its functionality, and delivery after verification is more in line with delivery requirements. In current technology, the acceptance and delivery of chip modules mostly involves adding a delivery and acceptance email to the contract for confirmation, which is often inefficient and lacks traceability. Therefore, an effective solution is urgently needed to address these problems. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a blockchain-based device verification system. One or more embodiments of this specification also relate to another blockchain-based device verification system to address technical deficiencies in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a blockchain-based device verification system is provided, comprising:

[0005] The first device uploads the device information associated with the target device to the blockchain;

[0006] The second device publishes a smart contract to the blockchain, the smart contract being used to determine whether the target device meets the acceptance requirements;

[0007] The target device, upon its first run, acquires the device information on the blockchain and performs a self-test based on the device information to obtain the self-test result; the self-test result is used as a parameter to call the smart contract to perform device acceptance, and the result after executing the smart contract is recorded on the blockchain as the acceptance result.

[0008] According to a second aspect of the embodiments of this specification, another blockchain-based device verification system is provided, comprising:

[0009] The first device uploads the device information associated with the target device to the blockchain;

[0010] The second device publishes a smart contract to the blockchain, the smart contract being used to determine whether the target device meets the acceptance requirements;

[0011] The target device, upon first run, acquires the device information on the blockchain and performs a self-test based on the device information to obtain the self-test result;

[0012] The third device communicates with the target device, uses the self-test result as a parameter to call the smart contract, calls the smart contract to perform device acceptance, and uploads the result after executing the smart contract as the acceptance result to the blockchain.

[0013] This manual provides a blockchain-based device verification system. To enable accurate device verification and improve efficiency after a change in device status, a device verification system based on blockchain technology is established. A first device uploads the target device's information to the blockchain, and a second device uploads a smart contract associated with the target device to the blockchain. This smart contract determines whether the target device meets acceptance requirements. When the target device runs for the first time, it retrieves device information from the blockchain and performs a self-check based on that information to obtain the self-check result. Subsequently, the self-check result is used as a parameter to invoke the smart contract for device acceptance. The result of executing the smart contract is recorded on the blockchain as the acceptance result. In practical applications, combining blockchain technology can effectively improve verification security while eliminating the need for additional offline operations, thus significantly improving device verification efficiency and ensuring standardization in device change scenarios. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the structure of a blockchain-based device verification system provided in one embodiment of this specification;

[0015] Figure 2 This is a schematic diagram of another blockchain-based device verification system provided in one embodiment of this specification;

[0016] Figure 3 This is a flowchart illustrating the processing procedure of a blockchain-based device verification system provided in one embodiment of this specification. Detailed Implementation

[0017] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0018] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0019] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0020] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0021] Blockchain is a chain of blocks. Each block stores specific information, and these blocks are linked together in chronological order of their creation. This chain is stored on all servers, and as long as at least one server in the system is operational, the entire blockchain is secure. These servers are called nodes in the blockchain system, and they provide storage space and computing power for the entire system. To modify information in the blockchain, the consent of more than half of the nodes must be obtained, and the information in all nodes must be modified. Compared to traditional networks, blockchain has two core characteristics: first, the data is difficult to tamper with; second, it is decentralized.

[0022] Smart contracts are computer protocols designed to transmit, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without the need for a third party; these transactions are traceable and irreversible.

[0023] This specification provides a blockchain-based device verification system. This specification also relates to another blockchain-based device verification system, which will be described in detail in the following embodiments.

[0024] Figure 1 A schematic diagram of the structure of a blockchain-based device verification system 100 according to an embodiment of this specification is shown. The blockchain-based device verification system 100 includes a first device 110, a second device 120, and a target device 130.

[0025] The first device 110 uploads the device information associated with the target device to the blockchain;

[0026] The second device 120 publishes a smart contract to the blockchain, the smart contract being used to determine whether the target device meets the acceptance requirements;

[0027] When the target device 130 runs for the first time, it obtains the device information on the blockchain and performs a self-test based on the device information to obtain the self-test result. The self-test result is used as a parameter to call the smart contract to perform device acceptance. The result after executing the smart contract will be recorded on the blockchain as the acceptance result.

[0028] Specifically, the first device refers to the terminal that connects to the target device manufacturer. Since the target device needs to be verified via blockchain after delivery, the first device must upload the associated device information to the blockchain before delivery to support the verification phase. Correspondingly, the second device refers to the terminal that connects to the target device manufacturer. To support acceptance testing after delivery and reduce the cost of manual review, the second device needs to publish a smart contract on the blockchain to determine whether the target device meets acceptance requirements. It should be noted that the smart contract published on the blockchain is a consensus-based contract determined by the manufacturer of the first device, the manufacturer of the second device, and the buyer of the target device, and is associated with the target device to be delivered to ensure accurate acceptance testing of the target device.

[0029] Furthermore, the target device specifically refers to the equipment that the buyer needs to procure according to actual requirements, including but not limited to chips, modules, or graphics processing devices. Correspondingly, the device information specifically refers to the information associated with the target device, which records the target device's attribute information and functional description files, used to characterize the device's uniqueness. For example, if the target device is a chip with communication functions, the device information includes, but is not limited to, register information, memory information, voltage information, communication functions, transmission power, and communication parameter configuration; or if the target device is a graphics processing device, the device information includes, but is not limited to, video memory information, power information, and serial number information. In practical applications, different types of target devices have different device information, and when uploading to the blockchain, the manufacturer can choose to upload all or part of the device information according to requirements, as long as it can achieve subsequent device acceptance processing. This embodiment does not impose any limitations here. Correspondingly, the smart contract specifically refers to a smart contract that can be used to verify the target device during the target device acceptance stage. It contains acceptance logic code to implement the acceptance processing of the target device, that is, by executing the smart contract, the acceptance result can be verified whether the device is faulty, used, or damaged.

[0030] Furthermore, the self-test of the target device specifically refers to the process of detecting relevant parameters of its own operation based on device information. For example, if the default memory of a chip is 1k, during the chip's self-test, it might read its own memory and determine it to be 0.95k. This 0.95k is the chip's self-test result, used in subsequent calls to the smart contract to test the memory at 0.95k. The test result is the acceptance result, verifying whether the chip's memory meets the acceptance requirements. Correspondingly, the self-test result is the relevant parameters obtained after the target device performs a self-test according to the device information; similarly, the acceptance result is the result after executing the smart contract, used to determine whether the target device meets the acceptance requirements. The acceptance result includes comparisons of parameter values ​​across various attribute dimensions of the target device, used to determine whether the target device meets or does not meet the acceptance requirements.

[0031] Based on this, the first operation of the target equipment indicates that it has been delivered from the product manufacturer to the buyer. Considering the importance of the target equipment, the buyer needs to conduct acceptance testing to determine whether to settle payment or return the goods. To ensure higher accuracy and efficiency in verifying the target equipment, the first device 110 can first upload the associated equipment information to the blockchain. This allows the equipment information of the target equipment in its factory state to be recorded on the blockchain, achieving tamper-proof protection. Simultaneously, the second device 120 will publish a smart contract associated with the target equipment, based on multi-party consensus, to the blockchain. This allows for determination of whether the target equipment meets acceptance requirements during the acceptance phase, achieving automated acceptance processing.

[0032] When target device 130 is run for the first time, it indicates a change in ownership. To ensure the target device is functional and malfunction-free, it automatically retrieves device information from the blockchain and performs a self-check based on this information. The self-check result is then used as a parameter to invoke a smart contract for device acceptance. The execution result of the smart contract is recorded on the blockchain as the acceptance result. This allows the new owner to determine the current status of the target device based on the acceptance result recorded on the blockchain, enabling them to decide on subsequent actions, such as canceling the subscription or settling the remaining payment.

[0033] For example, a manufacturer produces a batch of communication-enabled chips, serial numbers S1 to Sn; chip information is A1 to An. To provide reliable chips to both the product manufacturer and the buyer, the manufacturer uploads the chip information (power, parameters, functions, initial register values, initial memory values, initial voltage values) of each chip to the blockchain using a first device. Simultaneously, the product manufacturer publishes a multi-party consensus smart contract to the blockchain using a second device, enabling automated acceptance processing during the chip acceptance phase.

[0034] Subsequently, the chips were sold by the manufacturer to the buyers. To ensure that the delivered chips were those with serial numbers S1 to Sn, and that each chip was unused, upon its first run, each chip would retrieve device information (power, parameters, functions, initial register values, initial memory values, initial voltage values) from the blockchain. It would then perform a self-test based on this information, meaning the chip would self-check the actual parameters corresponding to each piece of device information at the current moment, obtaining the self-test results. These results could then be used as parameters to invoke a smart contract for multi-party consensus, performing device acceptance testing. Executing the smart contract allowed for comparison of the self-test results with the consensus-based device information, determining the device's performance across various dimensions. By integrating all the comparison results, the chip's acceptance result was determined and recorded on the blockchain. The chip buyers could then use the blockchain to verify the acceptance results of each chip, allowing them to pay the remaining balance to the manufacturer or return defective chips.

[0035] This manual provides a blockchain-based device verification system. To enable accurate device verification and improve efficiency after a change in device status, a device verification system based on blockchain technology is established. A first device uploads the target device's information to the blockchain, and a second device uploads a smart contract associated with the target device to the blockchain. This smart contract determines whether the target device meets acceptance requirements. When the target device runs for the first time, it retrieves device information from the blockchain and performs a self-check based on that information to obtain the self-check result. Subsequently, the self-check result is used as a parameter to invoke the smart contract for device acceptance. The result of executing the smart contract is recorded on the blockchain as the acceptance result. In practical applications, combining blockchain technology can effectively improve verification security while eliminating the need for additional offline operations, thus significantly improving device verification efficiency and ensuring standardization in device change scenarios.

[0036] Furthermore, considering that the device information of the target device is a fundamental element for the acceptance of the target device, in order to ensure that the target device can be accurately verified and that whether the device has been used or damaged can be reflected in the device information, device attribute information and device description file can be selected to form device information for subsequent use. In this embodiment, the first device 110 is used to determine the device attribute information and device description file corresponding to the target device, and upload the device attribute information and the device description file as device information to the blockchain.

[0037] Specifically, device attribute information refers to the information that integrates the initial values ​​of the target device across various attribute dimensions, used to characterize the basic attributes of the target device. For example, if the target device is a chip, which includes memory, drivers, decoders, etc., then the device attribute information includes, but is not limited to, parameters related to the memory, parameters related to the drivers, and parameters related to the decoders, such as register information, memory information, and voltage information. Correspondingly, a device description file refers to a file that integrates and describes the function, rules, etc., of the target device. The content included in the functional description file depends on the functions that the target device can provide. For example, if the target device is a chip with communication functions, then the device description file includes the chip's communication functions, transmit power, communication parameters, etc.; or if the target device is a chip with storage functions, then the device description file includes the chip's storage functions, storage space parameters, storage technology implementation information, etc.

[0038] Based on this, in order to ensure that the target equipment can be accepted from multiple dimensions and improve the accuracy of acceptance, the equipment attribute information and equipment description file corresponding to the target equipment can be determined and used as the equipment information corresponding to the target equipment. Then, the equipment information containing the equipment attribute information and equipment description file is uploaded to the blockchain so that the target equipment can be accurately accepted in the future.

[0039] In summary, by recording device attribute information and device description files on the blockchain, both changeable and immutable information of the target device is recorded. During the acceptance phase, the target device can be accepted more accurately, thereby ensuring the authenticity of the acceptance and improving the efficiency of the acceptance process.

[0040] Based on this, in order to ensure that the smart contract can accurately verify the target device from both changed and unchanged dimensions, the smart contract can be created by combining the device attribute information and the device description file. In this embodiment, the second device 120 is used to create a smart contract based on the device attribute information and the device description file, and publish the smart contract to the blockchain.

[0041] Specifically, when creating a smart contract, considering that the smart contract is a contract for accepting the target device that needs to be delivered, in order to accurately accept the target device, a multi-party consensus smart contract can be created by combining the device description file and device attribute information of the target device, and then published on the blockchain for subsequent acceptance processing.

[0042] It's important to note that smart contracts, as contracts for accepting and processing target devices, require consensus among multiple parties. Only by combining device attribute information and device description files can a smart contract associated with the target device be created. For example, the target device's device information might contain n dimensions of attribute information and m dimensions of description files. However, during the device acceptance phase, the buyer typically only accepts l (l ≤ m + n) dimensions of information. Therefore, when creating a smart contract, the n dimensions of attribute information and the m dimensions of description files can be combined, and l dimensions of information (including p1 initial attribute information and p2 initial description files, where p1 + p2 = l) can be selected to create the smart contract for subsequent use.

[0043] For example, a chip with communication capabilities and serial number S1 has device attribute information including initial register values, initial memory values, power supply parameters, input voltage parameters, output voltage parameters, and storage temperature parameters; its device description file includes transmit power, communication functions, and interface parameters. To support automated chip acceptance after delivery, the manufacturer can upload the device attribute information and device description file to the blockchain using a first device. Simultaneously, based on the consensus reached by the product manufacturer, the producer, and the buyer, a smart contract will be created using the initial register values, initial memory values, power supply parameters, and storage temperature parameters from the device attribute information, as well as the communication functions and interface parameters from the device description file. The product manufacturer will then publish this smart contract to the blockchain using a second device, enabling automated acceptance processing after chip delivery.

[0044] In summary, by creating an equipment acceptance contract based on the equipment description file and equipment attribute information, information representing the working status of the target equipment is integrated into the equipment acceptance contract, thereby enabling accurate verification of the target equipment and obtaining more accurate verification information.

[0045] Furthermore, considering that the target device may need to be integrated with other devices to function after delivery, and that its acceptance criteria can only be determined after the target device is operational, in order to ensure that verification can be automatically completed after the target device is started, the on-chain information of the device and the on-chain address of the smart contract can be written into the firmware code of the target device. This allows the relevant information to be downloaded and accurately verified during runtime via function calls. In this embodiment, the second device 120 obtains the block height and transaction address after the device information is uploaded to the blockchain, as well as the on-chain address of the smart contract after it is deployed on the blockchain; and writes the block height, the transaction address, and the on-chain address into the firmware code of the target device.

[0046] Specifically, block height refers to the number of blocks on the blockchain after the device description information and device description file are uploaded. Correspondingly, transaction address refers to the transaction number, or transaction hash (TxHash), corresponding to the uploaded device information. That is, after the device information is uploaded to the blockchain, it is signed with a private key to obtain a target signature. This signature is then merged with the uploaded signature and subjected to hash calculation to obtain the transaction hash (TxHash), which is used as the transaction address. This enables the download of device information on the blockchain. Correspondingly, on-chain address refers to the address where the device acceptance contract is deployed on the blockchain. Correspondingly, firmware code refers to the code corresponding to the program that the target device needs to execute in its working state.

[0047] Based on this, after the first device uploads the target device's information to the blockchain, it will obtain the block height and transaction address corresponding to the target device. Simultaneously, after the second device publishes the smart contract associated with the target device to the blockchain, it will obtain the on-chain address of the deployed smart contract. Subsequently, to support automatic acceptance testing of the target device and save on manpower, the block height, transaction address, and on-chain address can be written into the target device's firmware code. This will allow for accurate acceptance testing of the target device based on this information.

[0048] In practical applications, considering that both block height and transaction address can be used to read device information on the blockchain, when writing block height and transaction address into the firmware code, you can write only the block height, only the transaction address, or both, to ensure accurate download of device information.

[0049] In summary, by writing the on-chain information and on-chain address into the firmware code of the target device, the device acceptance process can be automatically executed by calling the on-chain information and on-chain address in the firmware code when the target device is running. This eliminates the need for manual intervention and effectively improves the convenience of device acceptance.

[0050] Based on this, after the target device is delivered and the IoT device carrying the target device is running, the device information corresponding to the target device can be downloaded on the blockchain according to the on-chain information read from the firmware code, so as to detect the target device. In this embodiment, the target device 130, during its first run, reads the block height and / or the transaction address in the firmware code, obtains the device information on the blockchain according to the block height and / or the transaction address, performs a self-test based on the device information to obtain a self-test result, reads the on-chain address in the firmware code, determines the smart contract on the blockchain according to the on-chain address, uses the self-test result as a parameter to call the smart contract, and calls the smart contract to perform device acceptance.

[0051] Specifically, IoT devices refer to devices equipped with target devices, such as vending machines with chips or terminals with camera modules. Therefore, once the target device is determined to be running within the IoT system, the target device will begin its first operation. This triggers an automatic acceptance event, which involves reading the block height and / or transaction address associated with the target device from the firmware code, retrieving device information from the blockchain based on the block height and / or transaction address, and performing a self-check based on this information to obtain the self-check result.

[0052] Furthermore, after the self-test is completed, in order to automatically accept the target device, the on-chain address can be read in the firmware code. Then, based on the on-chain address, the smart contract associated with the target device can be determined on the blockchain. After that, the self-test result is used as the parameter to call the smart contract to perform device acceptance processing. The result after executing the smart contract will be recorded on the blockchain as the acceptance result.

[0053] In practical applications, to save space resources, only the block height or transaction address can be written to the firmware code. To achieve accuracy in downloading device information, both the block height and transaction address can be written to the firmware code. The choice can be made based on the specific application scenario, and this embodiment does not impose any limitations. Based on this, when the target device is running, the device information can be downloaded by reading the block height and / or transaction address. Furthermore, by reading the on-chain address in the firmware code, the smart contract associated with the target device can be determined. The self-test result is then input into the smart contract to execute the smart contract, complete the acceptance of the target device, and upload the acceptance result to the blockchain.

[0054] For example, after the manufacturer uploads the chip's attributes and functional description file to the blockchain using a first device, they will obtain the chip's block height and TxHash transaction address. Simultaneously, the smart contract created based on the chip's attributes and functional description file is deployed to the blockchain by the product manufacturer using a second device, obtaining the on-chain address of the smart contract. Furthermore, to automate the chip acceptance process, the block height, TxHash transaction address, and on-chain address can be written into the chip's firmware code. When the chip is delivered to the buyer, if it is running for the first time in an actual IoT device, the firmware code can read the block height, TxHash transaction address, and on-chain address according to the operating mechanism to perform detection of the currently running chip.

[0055] Furthermore, after reading the block height and TxHash transaction address from the firmware code, the chip's corresponding chip attribute and functional description file can be downloaded from the blockchain network based on these information. Then, the chip's attributes and functional description file are used to perform a self-test on the currently running chip, such as checking the chip's current register values, voltage values, memory values, functional description information, and transmit power, as the self-test result. Simultaneously, the smart contract associated with the chip is determined based on the on-chain address in the firmware code. The self-test result is then used as a parameter to call the smart contract for device acceptance. Executing the smart contract yields the acceptance result, which is then uploaded to the blockchain. Subsequently, the chip purchaser can use the blockchain to determine the acceptance results of each chip, and based on the acceptance results, pay the remaining balance to the product supplier or return defective chips.

[0056] In summary, by using firmware code to write on-chain information and on-chain addresses, the self-test of the target device is automatically triggered to determine the self-test result of the target device in the current state. This facilitates the subsequent determination of whether the target device meets the acceptance criteria by executing smart contracts, thereby achieving the purpose of fast and accurate acceptance. At the same time, combined with blockchain implementation, it can avoid the state from being tampered with before acceptance, further ensuring the accuracy of acceptance.

[0057] During the device verification phase, to prevent tampering with the device test results during the intermediate process, encryption and decryption methods can be used to improve verification security. In this embodiment, the target device 130 creates a self-test event based on the device information, performs a self-test based on the self-test event to obtain a self-test result, reads the target private key to encrypt the self-test result to obtain an encrypted self-test result, and uses the encrypted self-test result as a parameter to call the smart contract to call the smart contract for device acceptance.

[0058] Specifically, a self-test event refers to an event created based on device information to perform a self-test on the target device. This self-test event corresponds to all dimensions involved in the device information, with each dimension corresponding to a sub-self-test event to ensure the comprehensiveness of the self-test. Correspondingly, the target private key refers to the key used to encrypt the self-test results. It is recorded in the target device's memory. It should be noted that the target private key is created at the time of the target device's manufacture and is unique. The public key corresponding to the target private key is also simultaneously registered on the blockchain for use when calling smart contracts, enabling the acceptance of the target device through smart contract execution. Furthermore, the smart contract performs the acceptance process on the target device through acceptance logic information. This acceptance logic information specifically refers to the acceptance logic code in the device acceptance contract. Executing this code triggers a mechanism to verify the device's test results, comparing the test results with the device information before delivery to obtain verification information.

[0059] Based on this, after downloading device information from the blockchain, the target device can create multiple sub-self-check events based on various dimensions associated with the device information, forming a target event. Executing the target event completes the self-check of the target device, yielding a self-check result. Then, the target private key is read from the target device's memory to encrypt the self-check result, resulting in an encrypted self-check result. This encrypted result is then used as a parameter to invoke the smart contract for device acceptance testing.

[0060] For example, the chip's device information includes device attribute information and a device description file. Device attribute information includes initial register values, initial memory values, power supply parameters, and storage temperature parameters; the device description file includes transmit power, communication functions, and interface parameters. At this point, seven sub-self-test events can be created based on the device information: register self-test event, memory self-test event, power supply self-test event, temperature self-test event, power self-test event, function self-test event, and interface parameter self-test event. Then, by executing each sub-self-test event, the relevant parameters for the chip's first run are determined. Specifically, executing the register self-test event will yield the current actual register value (A1); executing the memory self-test event will yield the current actual memory size (B1); executing the power supply self-test event will yield the current actual power supply voltage (C1); executing the temperature self-test event will yield the current actual storage temperature (D1); executing the power self-test event will yield the current actual chip power (E1); executing the function self-test event will yield the chip's function information (F1); and executing the interface parameter self-test event will yield the chip's interface type (G1).

[0061] Furthermore, by integrating the results of the aforementioned self-test events, the chip's self-test result is obtained. Then, the private key is read from the chip's memory to sign the self-test result. The signed self-test result is then input into the smart contract corresponding to the on-chain address. The smart contract decrypts the self-test result signed with the private key using the public key, obtaining the final self-test result. At this point, the smart contract is invoked to verify the chip's self-test result using the consensus-preset acceptance logic code. This involves comparing the obtained actual value or information with the threshold or standard information at the time of on-chain verification. Based on the comparison result, it is determined whether the chip meets the acceptance requirements in various dimensions. The result after executing the smart contract is the chip's corresponding acceptance result, which is then uploaded to the blockchain. Subsequently, chip buyers can use the blockchain to determine the acceptance results of each chip, and based on the acceptance results, pay the remaining balance to the product manufacturer or process returns for problematic chips.

[0062] In summary, using a combination of private and public keys to inspect target devices ensures the security of the inspection process. Furthermore, to ensure accurate inspection, the inspection logic information can be used for verification, further improving the accuracy of the inspection and allowing for backtracking in cases where the device does not meet the inspection standards.

[0063] Furthermore, in order to enable the device user to trace back when there is a problem with the target device, and to create and retain acceptance certificates based on relevant information, in this embodiment, the second device 120 obtains the acceptance result and public key address on the blockchain according to the smart contract, and creates the acceptance certificate corresponding to the target device based on the acceptance result and the public key address.

[0064] Specifically, the public key address refers to the address corresponding to the key used to decrypt the encrypted self-test result. Correspondingly, the acceptance certificate refers to the credential used by the buyer or product provider to process the delivery after the target device has undergone acceptance processing. Based on this, after the second device confirms the delivery of the target device, it can query the delivered acceptance result and public key address of the target device through a smart contract on the blockchain. Then, it can create an acceptance certificate corresponding to the target device based on the public key address and acceptance result to retain records of the target device's acceptance process.

[0065] For example, after obtaining the chip verification information, this information can be uploaded to the blockchain to achieve persistent verification records. Once the product manufacturer confirms that the chip has been accepted, they can use a smart contract on the blockchain to query the number of delivered and verified chips and their public key addresses. Based on this, they can create transaction vouchers for that batch of chips, allowing them to resolve issues during the retrospective phase.

[0066] In summary, by persisting verification information and creating acceptance credentials, the verification process of the delivered target equipment can be recorded. In the retrospective stage, transaction credentials can be used to resolve issues, thereby avoiding disputes and improving the standardization of equipment delivery scenarios.

[0067] Furthermore, when the product owner, manufacturer, or purchaser needs to perform retrospective analysis, they can obtain the device information and / or acceptance results corresponding to the target device from the blockchain based on the verification request. In this embodiment, the first device 110 or the second device 120 obtains the device information and / or acceptance results corresponding to the target device from the blockchain based on the verification request. Additionally, the purchaser of the target device can also obtain the device information and / or acceptance results corresponding to the target device from the blockchain through a third device based on the verification request.

[0068] In other words, if a dispute arises after the equipment is delivered, the product seller, manufacturer, or buyer can submit a verification request. Then, based on the request, they can obtain the equipment information and / or acceptance results on the blockchain to carry out subsequent processing based on the information at each stage in order to resolve the dispute.

[0069] This manual provides a blockchain-based device verification system. To enable accurate device verification and improve efficiency after a change in device status, a device verification system based on blockchain technology is established. A first device uploads the target device's information to the blockchain, and a second device uploads a smart contract associated with the target device to the blockchain. This smart contract determines whether the target device meets acceptance requirements. When the target device runs for the first time, it retrieves device information from the blockchain and performs a self-check based on that information to obtain the self-check result. Subsequently, the self-check result is used as a parameter to invoke the smart contract for device acceptance. The result of executing the smart contract is recorded on the blockchain as the acceptance result. In practical applications, combining blockchain technology can effectively improve verification security while eliminating the need for additional offline operations, thus significantly improving device verification efficiency and ensuring standardization in device change scenarios.

[0070] Corresponding to the above embodiments, this embodiment also provides another blockchain-based device verification system. Figure 2 A schematic diagram of another blockchain-based device verification system provided according to an embodiment of this specification is shown. The blockchain-based device verification system 200 includes a first device 210, a second device 220, a target device 230, and a third device 240.

[0071] The first device 210 uploads the device information associated with the target device to the blockchain;

[0072] The second device 220 publishes a smart contract to the blockchain, the smart contract being used to determine whether the target device meets the acceptance requirements;

[0073] The target device 230, upon its first run, acquires the device information on the blockchain and performs a self-test based on the device information to obtain the self-test result;

[0074] The third device 240 is communicatively connected to the target device, uses the self-test result as a parameter to call the smart contract, calls the smart contract to perform device acceptance, and uploads the result after executing the smart contract as the acceptance result to the blockchain.

[0075] It should be noted that the other blockchain-based device verification system provided in this embodiment is similar to the description of the blockchain-based device verification system described above. The same or corresponding descriptions can be found in the above embodiment, and this embodiment will not be described in detail here.

[0076] Specifically, the third device refers to the device that communicates with the target device, and the third device corresponds to the purchaser of the target device.

[0077] In one optional embodiment, the first device 210 determines the device attribute information and device description file corresponding to the target device, and uploads the device attribute information and the device description file as device information to the blockchain.

[0078] In one optional embodiment, the second device 220 creates a smart contract based on the device attribute information and the device description file, and publishes the smart contract to the blockchain.

[0079] In one optional embodiment, the second device 220 obtains the block height and transaction address after the device information is uploaded to the blockchain, as well as the on-chain address after the smart contract is deployed on the blockchain; and writes the block height, the transaction address, and the on-chain address into the firmware code of the target device.

[0080] In an optional embodiment, the target device 230, upon first run, reads the block height and / or the transaction address in its firmware code, obtains the device information on the blockchain based on the block height and / or the transaction address, and performs a self-test based on the device information to obtain a self-test result.

[0081] In one optional embodiment, the third device 240 reads the on-chain address from the firmware code of the target device, determines the smart contract on the blockchain based on the on-chain address, uses the self-test result as a parameter to call the smart contract, and calls the smart contract to perform device acceptance.

[0082] In one optional embodiment, the target device 230 creates a self-test event based on the device information, performs a self-test based on the self-test event, and obtains a self-test result.

[0083] Correspondingly, the third device 240 reads the target private key to encrypt the self-test result, obtains the encrypted self-test result, and uses the encrypted self-test result as a parameter to call the smart contract to perform device acceptance.

[0084] In one optional embodiment, the second device 220 obtains the acceptance result and public key address on the blockchain according to the smart contract, and creates an acceptance credential corresponding to the target device based on the acceptance result and the public key address.

[0085] In one optional embodiment, the first device 210, the second device 220, or the third device 240 obtains the device information and / or acceptance results corresponding to the target device on the blockchain according to the verification request.

[0086] In summary, to enable accurate and efficient verification of devices after state changes, a device verification system based on blockchain technology can be established. A first device uploads the target device's information to the blockchain, and a second device uploads a smart contract associated with the target device to the blockchain. This smart contract determines whether the target device meets acceptance requirements. When the target device runs for the first time, it retrieves device information from the blockchain and performs a self-check based on that information. Subsequently, a third device uses the self-check result as a parameter to invoke the smart contract for device acceptance. The result of executing the smart contract is recorded on the blockchain as the acceptance result. In practical applications, combining blockchain technology can effectively improve verification security without requiring additional offline operations, thus significantly increasing device verification efficiency and ensuring standardization in device change scenarios.

[0087] The following is in conjunction with the appendix Figure 3 Taking the application of the blockchain-based device verification system provided in this specification in a graphics processor delivery scenario as an example, the blockchain-based device verification system will be further explained. Figure 3 This specification illustrates a flowchart of the processing procedure of a blockchain-based device verification system according to one embodiment, which specifically includes the following steps.

[0088] Step S302: The manufacturing equipment uploads the attribute information and functional description file corresponding to the graphics processor to the blockchain to obtain the block height and transaction address corresponding to the graphics processor.

[0089] Step S304: The product supplier creates an acceptance contract based on the graphics processor's attribute information and functional description file.

[0090] In step S306, the product provider publishes the acceptance contract to the blockchain and obtains the on-chain address after the acceptance contract is deployed.

[0091] In step S308, the product device writes the on-chain address, block height, and transaction address into the firmware code of the graphics processor.

[0092] In step S310, the graphics processor reads the block height and transaction address from the firmware code during its first run.

[0093] In step S312, the graphics processor downloads attribute information and functional description files from the blockchain based on the block height and transaction address.

[0094] Step S314: The graphics processor performs a self-test based on the attribute information and the function description file, and obtains the self-test results.

[0095] Step S316: After signing the self-test result using the private key, the buyer's device sends it to the acceptance contract corresponding to the on-chain address, calls the acceptance contract to perform device acceptance, and the result after executing the acceptance contract will be recorded on the blockchain as the acceptance result.

[0096] In step S318, the product device downloads the number of graphics processors and public key addresses from the blockchain and creates an acceptance certificate.

[0097] In summary, to enable accurate and efficient verification of devices after state changes, a device verification system based on blockchain technology can be established. The generating device uploads its graphics processor (GPU) information to the blockchain, and the product-producing device uploads an acceptance contract associated with the GPU to the blockchain. This acceptance contract determines whether the GPU meets the acceptance requirements. When the GPU runs for the first time, it retrieves device information from the blockchain and performs a self-test based on that information. Subsequently, the purchasing device uses the self-test result as a parameter to invoke the acceptance contract for device acceptance. The result of executing the acceptance contract is recorded on the blockchain as the acceptance result. In practical applications, combining blockchain technology can effectively improve verification security without requiring additional offline operations, thus significantly improving device verification efficiency and ensuring standardization in device change scenarios.

[0098] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0099] The computer instructions involved in this scheme include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in different jurisdictions. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0100] It should be noted that, for the sake of simplicity, the aforementioned system embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0101] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0102] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A blockchain-based device verification system, comprising: The first device uploads the device information associated with the target device to the blockchain; The second device publishes a smart contract to the blockchain, the smart contract being used to determine whether the target device meets the acceptance requirements; The target device, upon first run, acquires the device information on the blockchain and performs a self-test based on the device information to obtain the self-test result; Read the target private key built into the target device, encrypt the self-test result, and obtain the encrypted self-test result; The encrypted self-test result is used as a parameter to call the smart contract, which performs device acceptance testing. The result of executing the smart contract will be recorded on the blockchain as the acceptance result.

2. The system according to claim 1, wherein the first device determines the device attribute information and device description file corresponding to the target device, and uploads the device attribute information and the device description file as device information to the blockchain.

3. In the system according to claim 2, the second device creates a smart contract based on the device attribute information and the device description file, and publishes the smart contract to the blockchain.

4. In the system according to claim 1, the second device acquires the block height and transaction address after the device information is uploaded to the blockchain, and the on-chain address after the smart contract is deployed on the blockchain; and writes the block height, the transaction address, and the on-chain address into the firmware code of the target device.

5. According to claim 4, the target device, during its first run, reads the block height and / or the transaction address in the firmware code, obtains the device information on the blockchain based on the block height and / or the transaction address, and performs a self-test based on the device information to obtain a self-test result.

6. In the system according to claim 5, the target device reads the on-chain address in the firmware code, determines the smart contract on the blockchain based on the on-chain address, uses the self-test result as a parameter for calling the smart contract, and calls the smart contract to perform device acceptance.

7. The system according to claim 1, wherein the target device creates a self-test event based on the device information, performs a self-test based on the self-test event to obtain a self-test result; reads the target private key to encrypt the self-test result to obtain an encrypted self-test result, uses the encrypted self-test result as a parameter for calling the smart contract, and calls the smart contract to perform device acceptance.

8. The system according to any one of claims 1-7, wherein the second device obtains the acceptance result and public key address on the blockchain according to the smart contract, and creates an acceptance certificate corresponding to the target device according to the acceptance result and the public key address.

9. In the system according to any one of claims 1-7, the first device or the second device obtains the device information and / or acceptance results corresponding to the target device on the blockchain according to the verification request.

10. A blockchain-based device verification system, comprising: The first device uploads the device information associated with the target device to the blockchain; The second device publishes a smart contract to the blockchain, the smart contract being used to determine whether the target device meets the acceptance requirements; The target device, upon first run, acquires the device information on the blockchain and performs a self-test based on the device information to obtain the self-test result; Read the target private key built into the target device, encrypt the self-test result, and obtain the encrypted self-test result; The third device communicates with the target device, uses the encrypted self-test result as a parameter to call the smart contract, the smart contract performs device acceptance, and uploads the result of executing the smart contract as the acceptance result to the blockchain.

Images