A method and device for internet of things payment based on smart contract

Abstract

The application discloses a method and device for Internet of Things payment based on a smart contract, and relates to the technical field of Internet of Things. A specific implementation of the method comprises the following steps: after deploying a smart contract on an Internet of Things device, performing contract registration, so that the smart contract enters a listening state; listening to external events through the smart contract, and in the case that the external events meet a triggering condition, converting the smart contract from the listening state to an execution state to perform Internet of Things payment; wherein the smart contract in the execution state continues to listen to external events. The implementation realizes trusted payment, reliable user privacy protection and safe and convenient transaction payment.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method and apparatus for IoT payment based on smart contracts. Background Technology

[0002] With the rise of the Internet of Things (IoT), the security of IoT payments has become increasingly prominent. The key to payment events lies in the initiation and confirmation of transactions. The initiation of transactions is usually achieved through data collection, while the confirmation of transactions is currently mainly carried out by third-party payment platforms authorized by users.

[0003] In the process of realizing this invention, the inventors discovered the following problems in the prior art:

[0004] First, due to the large number of IoT devices, and the fact that most of them are not portable, it is inconvenient for users to confirm payment transactions in real time. Second, the personal information for transaction payments is managed by the IoT device operators, which poses a risk of user privacy leaks. Finally, there is a risk of default on transactions triggered by third-party payment platforms, which can lead to transaction disputes, financial losses, and other problems. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method and apparatus for IoT payment based on smart contracts. Based on the trusted payment scenario actively perceived by smart contracts and the two-way measurable security perception mechanism, by applying smart contracts to IoT devices, trusted payment, reliable user privacy protection, and secure and convenient transaction payment are realized.

[0006] To achieve the above objectives, according to a first aspect of the present invention, a method for making Internet of Things (IoT) payments based on smart contracts is provided, comprising:

[0007] After deploying the smart contract to an IoT device, the contract is registered so that the smart contract enters a listening state;

[0008] The smart contract listens for external events, and when the external events meet the triggering conditions, the smart contract is switched from the listening state to the execution state to perform IoT payments.

[0009] Among them, smart contracts in the execution state continue to listen for external events.

[0010] Optionally, the smart contract includes three parts: a payee contract, a payer contract, and a payment channel contract, and these three parts are deployed on one or more IoT devices respectively.

[0011] Optionally, listening to external events through the smart contract and switching the smart contract from a listening state to an execution state when the external event meets the triggering conditions to perform IoT payments includes: listening to external events through the payee contract; switching the smart contract from a listening state to an execution state when the external event meets the triggering conditions; calling the payment channel contract through the payee contract; and calling the payer contract through the payment channel contract to process the payment request, thereby performing IoT payments.

[0012] Optionally, after making an IoT payment, the process further includes: receiving a payment voucher returned by the payment channel contract through the payee contract and verifying the payment voucher; if the verification passes, completing the IoT payment; wherein the payment voucher is generated by the payer contract after making the IoT payment.

[0013] Optionally, if the payee contract, payer contract, and payment channel contract are deployed on different IoT devices, the payment channel contract is associated with the payee contract and the payer contract respectively before the smart contract is switched from the listening state to the execution state for IoT payment; if the payment channel contract is deployed on the same IoT device as at least one of the payee contract and the payer contract, the payment channel contract is associated with the payee contract and the payer contract respectively during contract registration.

[0014] Optionally, the smart contract has identity data and can provide identity verification services; wherein, the identity data of the smart contract is implemented based on digital certificates and digital signature technology during contract registration; the identity verification service is based on the identity data of the smart contract and the digest value of the executable code of the smart contract.

[0015] Optionally, the smart contract has a security level, and before deploying the smart contract to an IoT device, the method further includes: obtaining the security level of a module on the IoT device to which the smart contract is to be deployed; comparing the security level of the module with the security level of the smart contract, and the comparison result meeting the security requirements.

[0016] Optionally, the smart contract is implemented as a software module on the IoT device; the security of the hardware module on the IoT device is based on an initial root of trust embedded in the IoT device; and the software module on the IoT device is executed by the initial root of trust or other software modules guided by the initial root of trust.

[0017] Optionally, the security level of the module is calculated according to the following principles: the security level of the module does not exceed the security level of the initial root of trust on the module's boot execution chain, which consists of the initial root of trust that guides the execution of the module or other software modules guided by the initial root of trust; the security level of a module enhanced by a module based on an initial root of trust with a higher security level is higher than the security level of the initial root of trust; and the security level of a module that does not have confidentiality protection during loading and execution is lower than the security level of the initial root of trust.

[0018] According to a second aspect of the present invention, an apparatus for making Internet of Things (IoT) payments based on smart contracts is provided, comprising:

[0019] The contract registration module is used to register the smart contract after it has been deployed to an IoT device, so that the smart contract can enter a listening state.

[0020] The contract execution module is used to listen to external events through the smart contract, and when the external event meets the triggering conditions, to switch the smart contract from the listening state to the execution state for IoT payment; wherein, the smart contract in the execution state continues to listen to external events.

[0021] According to a third aspect of the present invention, a mobile electronic device terminal for Internet of Things (IoT) payments based on smart contracts is provided, characterized in that it comprises:

[0022] One or more processors;

[0023] Storage device for storing one or more programs.

[0024] When the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in the first aspect of the embodiments of the present invention.

[0025] According to a fourth aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method provided in the first aspect of the present invention.

[0026] One embodiment of the above invention has the following advantages or beneficial effects: after deploying the smart contract to an IoT device, the contract is registered to put the smart contract into a listening state; the smart contract listens for external events, and when the external events meet the triggering conditions, the smart contract is switched from the listening state to the execution state to perform IoT payment; wherein the smart contract in the execution state continues to listen for external events, the technical solution realizes a trusted payment scenario based on the smart contract's proactive perception and a two-way measurable security perception mechanism. By applying the smart contract to IoT devices, trusted payment, reliable user privacy protection, and secure and convenient transaction payment are guaranteed. Attached Figure Description

[0027] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0028] Figure 1 This is a schematic diagram of the main process of a method for making Internet of Things (IoT) payments based on smart contracts according to an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of smart contract deployment according to the first embodiment of the present invention;

[0030] Figure 3 This is a schematic diagram of smart contract deployment according to the second embodiment of the present invention;

[0031] Figure 4 This is a schematic diagram of smart contract deployment according to the third embodiment of the present invention;

[0032] Figure 5 This is a schematic diagram illustrating the changes in the machine contract state according to an embodiment of the present invention;

[0033] Figure 6 This is a schematic diagram of the process of making Internet of Things (IoT) payments based on smart contracts according to an embodiment of the present invention;

[0034] Figure 7 This is a schematic diagram of the process of IoT payment based on machine contracts according to another embodiment of the present invention;

[0035] Figure 8 This is a schematic diagram of the main modules of an IoT payment device based on smart contracts according to an embodiment of the present invention;

[0036] Figure 9 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0037] Figure 10 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0038] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0039] Currently, IoT transactions are typically processed through third-party payment platforms authorized by users. This payment model suffers from several drawbacks, including inconvenience for users to confirm transactions in real time, a lack of privacy protection mechanisms, and the risk of breach of trust in initiating transactions. Consequently, existing IoT payment methods cannot adequately meet the needs of practical applications.

[0040] To address the aforementioned problems in the existing technology, this invention proposes an IoT payment method. Based on a trusted payment scenario proactively perceived by smart contracts and a two-way measurable security perception mechanism, this method applies smart contracts to IoT devices, thereby achieving trusted payment, reliable user privacy protection, and secure and convenient transaction payment.

[0041] In the description of the embodiments of the present invention, the terms involved and their meanings are as follows:

[0042] SCP: Secure Channel Protocol;

[0043] REE: Rich Execution Environment;

[0044] SE: Secure Element;

[0045] TEE: Trusted Execution Environment;

[0046] Internet of Things (IoT) devices: Embedded terminal devices with network connectivity and capable of digital currency transactions. The core functional modules of IoT devices are IoT wireless modules and business-related hardware peripherals.

[0047] Computing engine: A hardware functional unit consisting of a processor (CPU), memory (RAM), and flash memory, capable of independently performing computing tasks, excluding executable code, data, and keys. A computing engine may be a physical computing engine based on actual physical computing hardware, or a virtual computing engine based on virtualization technology.

[0048] Root of trust: It consists of executable code running on a specific computing platform and the computing engine that executes the executable code. It may also contain data and keys to provide security services.

[0049] Computing platform: A collective term for hardware and software modules such as computing engines, hardware peripherals, firmware, or operating systems. A computing platform can independently provide computing services. A computing platform requires an initial root of trust or an extended root of trust to bootstrap. A computing platform may be an actual physical computing platform based on physical hardware and software systems, or a virtual computing platform based on virtualization technology.

[0050] Machine Contracts: An application model for digital currency trading scenarios. Machine contracts can be activated when environmental events occur on IoT devices, determine whether the contract trigger conditions are met, and execute the agreed instructions after the trigger conditions are met.

[0051] Figure 1 This is a schematic diagram illustrating the main flow of a method for IoT payment based on smart contracts according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method for IoT payment based on smart contracts in this embodiment of the invention includes the following steps S101 to S102.

[0052] Step S101: After deploying the smart contract to the IoT device, register the contract so that the smart contract enters the listening state.

[0053] According to one embodiment of the present invention, the smart contract has a security level. Before deploying the smart contract to an IoT device, the method further includes: obtaining the security level of a module on the IoT device to which the smart contract is to be deployed; comparing the security level of the module with the security level of the smart contract, and the comparison result meeting the security requirements. In this embodiment of the present invention, since the smart contract is deployed on an IoT device, it is also called a "machine contract". A machine contract is an application model for digital currency trading scenarios. A machine contract can be activated when an external environmental event occurs on an IoT device, determine whether the contract triggering conditions are met, and execute the agreed instructions after the contract triggering conditions are met. Machine contracts can be defined and implemented based on computer programming languages ​​or abstract syntax languages. The completed machine contract needs to be reviewed by relevant parties. After the review, the machine contract needs to be compiled. Each party compiles the code to generate executable code and calculates the digest value of the executable code. This digest value is one of the measurement information used to verify the legitimacy of the identity when the machine contract is executed.

[0054] In addition to the aforementioned security levels, the smart contract must also include protection mechanisms to ensure its integrity and authenticity; basic descriptive information such as contract functions and version; machine contract identity data to uniquely identify the machine contract instance; internal state to store the current state of the machine contract; event listening rules and action correspondences to define the external events that the machine contract needs to listen to, as well as the correspondence between external events and actions; and specific action content to define the actions that the machine contract can execute.

[0055] The installation and deployment of smart contracts is bidirectionally measurable. Only smart contracts that pass authenticity verification are allowed to be installed and deployed. This authenticity verification can be achieved by verifying the legality of the smart contract's digital signature. The metric information for the modules of the IoT devices deployed with the smart contract includes a module identifier, module owner, module digest, module security level requirements, and module legal signature. The installation and deployment environment of the smart contract is measured by comparing the security level of the IoT device modules with the security level of the smart contract. Only when both the authenticity verification metric and the security metric of the IoT device modules deployed with the smart contract are met can the prerequisites for smart contract installation and deployment be satisfied. The module identifier may be a unique identifier or a class identifier; the module owner refers to the organization that developed and manages the module; the module digest refers to the digest value of the module's executable code; the module security level requirements determine whether the module can be loaded and executed; and the module legal signature refers to the digital signature of the above information included in the module, as well as the digital certificate associated with the digital signature.

[0056] According to another embodiment of the present invention, the smart contract is implemented as a software module on the Internet of Things (IoT) device; the security of the hardware module on the IoT device is based on an initial root of trust embedded in the IoT device; and the software module on the IoT device is executed by the initial root of trust or other software modules guided by the initial root of trust.

[0057] Specifically, the payee contract, payer contract, and payment channel contract are implemented as software modules on IoT devices. The security of the modules on the IoT devices where smart contracts are to be deployed includes the security of the hardware modules and the security of the software modules. The security of the hardware modules is determined by the initial root of trust embedded in the IoT device, while the security of the software modules depends on the initial root of trust that guides execution or other software modules guided by the initial root of trust. When guiding and executing software modules, the integrity and authenticity of the executable code of the software modules are first verified, and then it is verified whether the underlying environment for loading the software modules meets the security level requirements of the software modules.

[0058] According to another embodiment of the present invention, the security level of the module is calculated based on the following principles: the security level of the module does not exceed the security level of the initial root of trust on the bootstrap execution chain of the module, the bootstrap execution chain being composed of the initial root of trust that guides the execution of the module or other software modules guided by the initial root of trust; the security level of the module enhanced by a module based on an initial root of trust with a higher security level is higher than the security level of the initial root of trust; the security level of the module without confidentiality protection during loading and execution is lower than the security level of the initial root of trust.

[0059] Typically, a root of trust model consists of an initial root of trust that guides the execution of a module, or other software modules guided by the initial root of trust. The initial root of trust represents the highest security level, and the security level of a module's execution is not allowed to exceed the security level of the initial root of trust on the execution chain. Correspondingly, for modules that receive enhanced security by calling and executing other modules with higher security levels from the initial root of trust, their security level is an enhancement of the initial root of trust. Conversely, for modules without confidentiality protection, their security level is a reduction of the initial root of trust. For example, if the initial root of trust has a security level of 5, when a module calls other modules with higher security levels, the module's security level is enhanced, reaching 5+; when the module executes without confidentiality protection, its security level is 5-.

[0060] According to the technical solutions of embodiments of the present invention, the initial root of trust is typically contained within a computing platform. A computing platform is a collective term for inherent hardware and software modules such as a computing engine, hardware peripherals, firmware, or operating system. The computing platform determines the security level of the hardware device. Embodiments of the present invention can run on devices possessing the following three computing platforms or combinations thereof:

[0061] (1) REE computing platform

[0062] Composed of an application processor, memory, and flash storage, it inherently lacks protection against physical and logical attacks. The REE computing platform has the lowest security level. If the REE system undergoes security hardening and closed management, its security level will increase accordingly.

[0063] (2) TEE computing platform

[0064] It consists of a processor with protection against logical attacks and some low-level physical attacks, secure memory, and flash memory. The processor can be shared with the application processor based on secure virtualization technology or a separate processor chip. The security level of the TEE computing platform is higher than that of the REE computing platform but lower than that of the SE computing platform.

[0065] (3) SE or security subsystem computing platform

[0066] Composed of an independent processor with advanced physical attack protection mechanisms, secure memory, and secure flash memory, the SE or Security Subsystem computing platform is the platform with the highest level of security.

[0067] After the smart contract has passed legal signature verification and the security level of the software and hardware modules on the IoT device has been matched, the smart contract is installed and deployed. The smart contract that has been successfully installed and deployed is in the initial state and needs to be registered as a personal instance. By configuring the parameters of the smart contract, it can provide services. The registered smart contract enters the listening state from the initial state.

[0068] The aforementioned smart contract listening state primarily involves monitoring external payment scenario state changes within the Internet of Things (IoT) and listening to calls to smart contracts related to IoT payments. Specifically, when a smart contract enters the listening state, the payee contract listens for external events within the IoT payment scenario, the payment channel contract listens for call events sent by the payee contract, and the payer contract listens for call events sent by the payment channel contract.

[0069] Step S102: Listen to external events through the smart contract, and when the external event meets the triggering conditions, change the smart contract from the listening state to the execution state to perform IoT payment; wherein, the smart contract in the execution state continues to listen to external events.

[0070] According to one embodiment of the present invention, the smart contract includes three parts: a payee contract, a payer contract, and a payment channel contract, and these three parts are respectively deployed on one or more Internet of Things devices.

[0071] Specifically, based on their different roles and functions, smart contracts include payee contracts, payer contracts, and payment channel contracts that support payees and payers in completing payment transactions. Due to the functional differences of IoT devices, these three types of contracts can be deployed on one or more IoT devices to achieve different functions.

[0072] In one embodiment of the present invention, the payee contract, the payer contract, and the payment channel contract can be deployed on an Internet of Things (IoT) device to realize automatic and integrated transaction payment via IoT. Figure 2 This is a schematic diagram of smart contract deployment according to the first embodiment of the present invention. The payee contract is implemented as a merchant module, the payment channel contract is implemented as a cashier module, and the payer contract is implemented as a digital currency wallet module. The three modules are deployed on the same main device. The typical scenario is: the smart washing machine automatically purchases laundry detergent when it detects that the detergent is insufficient, and the smart refrigerator automatically purchases vegetables and fruits when it detects that the vegetables and fruits are insufficient.

[0073] In another embodiment of the present invention, the payee contract can be deployed in an associated device, and the payer contract and the payment channel contract can be deployed in the same master device, so as to enable the IoT master device to autonomously conduct transaction payments for goods and services with associated devices. Figure 3 This is a schematic diagram of smart contract deployment according to the second embodiment of the present invention. Similarly, the payment contract is implemented as a merchant module, the payment channel contract is implemented as a cashier module, and the payment contract is implemented as a digital currency wallet module. The cashier module and the digital currency wallet module are deployed on the same main device, and the merchant module is deployed on an associated device. A typical scenario is that IoT devices autonomously go to the merchant to purchase goods, such as: a smart tractor discovering that the fuel tank is low on fuel, automatically driving to a smart gas station to refuel and make a transaction payment.

[0074] In another embodiment of the present invention, the payee contract and the payment channel contract can be deployed in the same master device, and the payer contract can be deployed in the associated device to realize transaction payment of shared devices. Figure 4 This is a schematic diagram of smart contract deployment according to the third embodiment of the present invention. Similarly, the payment contract is implemented as a merchant module, the payment channel contract is implemented as a cashier module, and the payment contract is implemented as a digital currency wallet module. The cashier module and the merchant module are deployed on the same main device, and the digital currency wallet module is deployed on an associated device. Its typical scenario is a shared device scenario, such as: shared car users use their own wallets to pay usage fees.

[0075] In another embodiment of the invention, the payee contract, payer contract, and payment channel contract can be deployed on a single IoT device, enabling the payment channel contract to act as an intermediary for transaction payments. For example, a smart car can book movie tickets online and complete the payment through the main device with the deployed payment channel contract. Typically, an IoT device can deploy multiple payee contracts and multiple payer contracts, but generally only one payment channel contract is deployed. The payee contract, payer contract, and payment channel contract are essentially machine contracts, all possessing event listening and automatic execution capabilities. The payee contract primarily listens for external events of the IoT device, while the other two contracts listen for payment-related events.

[0076] The payee contract, payer contract, and payment channel contract that support the payee and payer in completing payment transactions jointly execute IoT payment operations through calls between contracts. If the two smart contracts that call each other are not on the same device, they can communicate through near-field or long-range communication channels, such as NFC (Near Field Communication), Bluetooth, cellular networks, and Wi-Fi. In this case, the communication needs to be based on a secure communication channel (SCP) to ensure information security.

[0077] According to another embodiment of the present invention, if the payee contract, the payer contract, and the payment channel contract are deployed on different IoT devices, the payment channel contract is associated with the payee contract and the payer contract respectively before the smart contract is switched from the listening state to the execution state for IoT payment; if the payment channel contract is deployed on the same IoT device as at least one of the payee contract and the payer contract, the payment channel contract is associated with the payee contract and the payer contract respectively during contract registration.

[0078] The prerequisite for transaction payment is establishing the association between the payee contract, the payer contract, and the payment channel contract. This involves establishing communication protocols and trust relationships between these three functional contracts. The payment channel contract, as the intermediary bridge supporting and facilitating the completion of the payment transaction, needs to be associated with both the payer and payee contracts. Depending on the specific installation and deployment of the smart contracts, there are two main scenarios: First, if the payee contract, payer contract, and payment channel contract are deployed on different IoT devices, the payment channel contract is associated with both the payee and payer contracts before the smart contract is switched from listening to execution for IoT payment. Second, if the payment channel contract is deployed on the same IoT device as at least one of the payee and payer contracts, the payment channel contract is associated with both the payee and payer contracts during contract registration.

[0079] According to another embodiment of the present invention, the smart contract has identity data and can provide identity verification services; wherein, the identity data of the smart contract is implemented based on digital certificates and digital signature technology during contract registration; the basis of the identity verification service includes the identity data of the smart contract and the digest value of the executable code of the smart contract.

[0080] Each smart contract instance, after being registered and individually instantiated, contains a mechanism to uniquely identify itself and can provide identity verification services. The smart contract's identity data is implemented during contract registration using digital certificates and digital signature technology, such as generating or importing SM2 key pairs and corresponding digital certificates. When a smart contract receives a call request, its legitimacy is determined by verifying the caller's smart contract identity and the digest value of its executable code. Furthermore, the smart contract's identity can be fixed or dynamically generated using a cryptographic signature mechanism.

[0081] According to another embodiment of the present invention, the method of listening to external events through the smart contract and switching the smart contract from a listening state to an execution state when the external event meets the triggering conditions to perform IoT payment includes: listening to external events through the payee contract; switching the smart contract from a listening state to an execution state when the external event meets the triggering conditions; calling the payment channel contract through the payee contract; and calling the payer contract through the payment channel contract to process the payment request, thereby performing IoT payment.

[0082] The payee contract transitions from the listening state to the execution state by listening to trusted external payment scenarios that meet the triggering conditions. By utilizing the associations established between the aforementioned payment channel contract and the payee contract and the payer contract respectively, the payee contract can call the payment channel contract and the payer contract, thereby realizing payment in the Internet of Things.

[0083] According to another embodiment of the present invention, after making an IoT payment, the method further includes: receiving a payment voucher returned by the payment channel contract through the payee contract and verifying the payment voucher; if the verification is successful, completing the IoT payment; wherein the payment voucher is generated by the payer contract after making the IoT payment.

[0084] As a receipt confirming the payment has been made by the payer, the payment voucher must have a mechanism to protect its integrity and authenticity. Unless absolutely necessary, the payment voucher must not contain private information. In cases where the payment voucher contains private information, the payer's contract must use information encryption to protect the private information.

[0085] As can be seen from the above payment method based on smart contracts deployed on IoT devices, the entire lifecycle of the machine contract mainly includes the initial state, the listening state, and the execution state.

[0086] Figure 5 This is a schematic diagram illustrating the state changes of a machine contract according to an embodiment of the present invention, where personalization refers to the personal instantiation registration in this invention, specifically:

[0087] (1) Initial state: After the machine contract is installed and deployed, before personalization, the machine contract in the initial state does not provide any services. The machine contract in this stage can enter the listening state through personalization;

[0088] (2) Listening State: This is the stage after a machine contract completes its personalized registration or executes a transaction. At this time, the machine contract is in an external event listening state. A machine contract in the listening state can enter the initial state by disabling the operation, which will clear all state information of the machine contract.

[0089] (3) Execution state: The machine contract enters the execution phase when its triggering conditions are met. The machine contract in the execution state continues to monitor the external state. If the external state no longer meets the machine contract's triggering conditions, the machine contract re-enters the monitoring state. The machine contract in the execution state can also enter the initial state through a disable operation.

[0090] Figure 6 This is a schematic diagram of the IoT payment process based on smart contracts according to an embodiment of the present invention. After the payee contract, payment channel contract, and payer contract are installed, deployed, and registered as personal instances, the payee contract, in a listening state, listens for trusted events in external payment scenarios. After verifying the data integrity and authenticity of the trusted events, as well as the security of the payee contract's basic environment, the payee contract determines the triggering conditions for the trusted events. When the triggering conditions are met, the payee contract changes from the listening state to the execution state and sends a payment request containing identity data to the payment channel contract. At this time, the payment channel contract waits to execute. Conversely, if the triggering conditions are not met, the payee contract continues to listen for trusted events in external payment scenarios. After receiving the payment request containing identity data from the payer contract, the payment channel verifies the payment request containing identity data. When the triggering conditions are met, the payment channel contract sends a payment request containing identity data. At this time, the payer contract waits to execute. Conversely, if the triggering conditions are not met, the payment channel contract continues to wait to execute. After receiving a payment request containing identity data from the payment channel contract, the payer contract verifies the payment request. If the triggering conditions are met, the payer contract makes the payment using a digital currency wallet and sends a payment voucher. At this point, the payee contract waits to execute. Conversely, if the triggering conditions are not met, the payer contract continues to wait to execute. The payment channel contract sends the payment voucher sent by the payer contract to the payee contract. The payee contract then checks the voucher for its completeness, authenticity, and payment rules. If the check conditions are met, the payee acknowledges the payment is complete and initiates the delivery of the goods or services. If the check conditions are not met, the payee contract continues to wait to execute.

[0091] Figure 7 This is a schematic diagram illustrating the process of IoT payment based on machine contracts, according to another embodiment of the present invention. In this embodiment, the payer contract is implemented as a merchant module, the payment channel contract is implemented as a cashier module, and the payer contract is implemented as a digital currency wallet module. The smart contract deployed in the IoT device is called a machine contract, and the personal instantiation registration is referred to as personalization. The main process of IoT payment is as follows:

[0092] (1) The various participants in the Internet of Things payment scenario jointly agree on the content of the machine contract to be deployed, and respectively develop or configure the digital currency wallet module, cashier module and merchant module that match the requirements of the machine contract.

[0093] (2) The cashier module is deployed to the device through a secure channel and is personalized. The association between the cashier module, the digital currency wallet module, and the merchant module can be done at this stage or when the payment occurs. The cashier module can only enter the execution state after it has been associated with the digital currency wallet module and the merchant module.

[0094] (3) The merchant module loads and executes and listens to external events in real time. If it finds that the external event meets the triggering conditions of the merchant module's machine contract, it sends a payment request to the cashier module. This allows the merchant module to perceive changes in the environmental state through infinite loop listening or by being woken up by the system.

[0095] (4) The cashier module verifies the payment request from the merchant module and the identity of the merchant module. If the conditions are met, it sends a payment request to the digital currency wallet module.

[0096] (5) After receiving a payment request, the digital currency wallet module verifies the payment conditions. If the conditions are met, it initiates the payment process and returns the payment voucher to the cashier module. The payment voucher must have integrity and authenticity protection mechanisms and generally does not contain private information.

[0097] (6) The cashier module provides the payment voucher to the merchant module for verification. If it passes the verification, the merchant module initiates the delivery process of goods or services.

[0098] The trusted events of external payment scenarios monitored by the payee contract are based on a hierarchical security model with an initial root of trust. A trust chain is established starting from an immutable hardware initial root of trust. Trusted transmission is used to ensure the trustworthiness of external payment scenarios. Moreover, since the smart contract is installed and deployed on IoT devices, it can actively sense trusted external payment scenarios by loading external sensors, thereby realizing intelligent automatic trusted sensing capabilities.

[0099] Furthermore, for smart contracts in the execution state, they continue to monitor external events. If an external event no longer meets the triggering conditions, the smart contract re-enters the monitoring state. For example, for a payee contract, while executing the payment collection process, it continuously monitors trusted events in external payment scenarios. After performing two-way verification and measurement on the trusted events, it determines whether the trusted events meet the triggering conditions. If they do not meet the conditions, the payee contract terminates the execution state and returns to the monitoring state to continue monitoring external payment scenarios.

[0100] Figure 8 This is a schematic diagram of the main modules of a device for IoT payment based on smart contracts according to an embodiment of the present invention. Figure 8As shown, the IoT payment device 800 based on smart contracts mainly includes a contract registration module 801 and a contract execution module 802.

[0101] The contract registration module 801 is used to register the smart contract after it has been deployed to an IoT device, so that the smart contract can enter a listening state.

[0102] Specifically, the smart contract has a security level, and before deploying the smart contract to an IoT device, the method further includes: obtaining the security level of the module on the IoT device to which the smart contract is to be deployed; comparing the security level of the module with the security level of the smart contract, and the comparison result meeting the security requirements.

[0103] The smart contract is implemented as a software module on the IoT device; the security of the hardware module on the IoT device is based on an initial root of trust embedded in the IoT device; and the software module on the IoT device is executed by the initial root of trust or other software modules guided by the initial root of trust.

[0104] The security level of the module is calculated based on the following principles: the security level of the module does not exceed the security level of the initial root of trust on the module's boot execution chain, which consists of the initial root of trust that guides the execution of the module or other software modules guided by the initial root of trust; the security level of a module enhanced by a module based on an initial root of trust with a higher security level is higher than the security level of the initial root of trust; the security level of a module that does not have confidentiality protection during loading and execution is lower than the security level of the initial root of trust.

[0105] The contract execution module 802 is used to listen to external events through the smart contract, and when the external event meets the triggering conditions, to switch the smart contract from the listening state to the execution state for IoT payment; wherein, the smart contract in the execution state continues to listen to external events.

[0106] Generally, the smart contract consists of three parts: a payee contract, a payer contract, and a payment channel contract, and these three parts are deployed on one or more IoT devices respectively.

[0107] During smart contract registration or before payment occurs: if the payee contract, payer contract, and payment channel contract are deployed on different IoT devices, the payment channel contract is associated with the payee contract and the payer contract respectively before the smart contract is switched from the listening state to the execution state for IoT payment; if the payment channel contract is deployed on the same IoT device as at least one of the payee contract and the payer contract, the payment channel contract is associated with the payee contract and the payer contract respectively during contract registration.

[0108] Additionally, the smart contract has identity data and can provide identity verification services; wherein, the identity data of the smart contract is implemented based on digital certificates and digital signature technology during contract registration; the identity verification service is based on the identity data of the smart contract and the digest value of the executable code of the smart contract.

[0109] The contract execution module 802 can also be used to: listen to external events through the payee contract; when the external event meets the triggering conditions, change the smart contract from the listening state to the execution state, and call the payment channel contract through the payee contract, so as to call the payer contract through the payment channel contract to process the payment request and perform IoT payment.

[0110] The contract execution module 802 can also be used to: receive the payment voucher returned by the payment channel contract through the payee contract and verify the payment voucher, and complete the IoT payment if the verification is successful. The payment voucher is generated by the payer contract after making the IoT payment.

[0111] Figure 9 An exemplary system architecture 900 is shown, which can be used to apply the method or apparatus for IoT payment based on smart contracts according to embodiments of the present invention.

[0112] like Figure 9 As shown, system architecture 900 may include terminal devices 901, 902, and 903, network 904, and server 905. Network 904 is used as a medium to provide a communication link between terminal devices 901, 902, and 903 and server 905. Network 904 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0113] Users can use terminal devices 901, 902, and 903 to interact with server 905 via network 904 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 901, 902, and 903, such as IoT digital payment applications and IoT payment wallet applications (for example only).

[0114] Terminal devices 901, 902, and 903 can be various electronic devices with displays that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0115] Server 905 can be a server providing various services, such as a backend management server supporting IoT payments based on smart contracts made by users using terminal devices 901, 902, and 903 (this is just an example). After deploying the smart contract to the IoT device, the backend management server registers the contract to put it into a listening state. It listens for external events through the smart contract, and when the external event meets the triggering conditions, it switches the smart contract from the listening state to the execution state to perform IoT payments. The smart contract in the execution state continues to listen for external events and feeds back the processing results (such as a payment success instruction – this is just an example) to the terminal device.

[0116] It should be noted that the method for IoT payment based on smart contracts provided in this embodiment of the invention is generally executed by server 905, and correspondingly, the device for IoT payment based on smart contracts is generally set in server 905.

[0117] It should be understood that Figure 9 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0118] The following is for reference. Figure 10 It shows a schematic diagram of the structure of a computer system 1000 suitable for implementing a terminal device of the present invention. Figure 10 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0119] like Figure 10 As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage section 1008 into a random access memory (RAM) 1003. The RAM 1003 also stores various programs and data required for the operation of the system 1000. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0120] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 1010 as needed so that computer programs read from it can be installed into storage section 1008 as needed.

[0121] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs the functions defined in the system of this invention.

[0122] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The units described in the embodiments of the present invention can be implemented in software or in hardware. The described units can also be housed in a processor; for example, a processor can be described as including a contract registration module and a contract execution module.

[0125] In some cases, the names of these modules do not constitute a limitation on the module itself. For example, the contract registration module can also be described as "a module used to register a smart contract after it has been deployed to an IoT device, so that the smart contract can enter a listening state".

[0126] On the other hand, the present invention also provides a computer-readable medium, which may be included in the device described in the embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, cause the device to: register a smart contract after it has been deployed to an IoT device, thereby putting the smart contract into a listening state; listen to external events through the smart contract, and, when the external events meet triggering conditions, convert the smart contract from the listening state to an execution state to perform IoT payments; wherein the smart contract in the execution state continues to listen to external events.

[0127] The technical solution according to the embodiments of the present invention has the following advantages or beneficial effects: after deploying the smart contract to the Internet of Things (IoT) device, the contract is registered to enable the smart contract to enter a listening state; the smart contract listens for external events, and when the external events meet the triggering conditions, the smart contract is switched from the listening state to the execution state to perform IoT payment; wherein the smart contract in the execution state continues to listen for external events, the technical solution realizes a trusted payment scenario based on the smart contract's proactive perception and a two-way measurable security perception mechanism. By applying the smart contract to IoT devices, trusted payment, reliable user privacy protection, and secure and convenient transaction payment are guaranteed.

[0128] The specific embodiments described herein do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for Internet of Things payment based on a smart contract, characterized in that, The method comprises the following steps: After the smart contract is deployed on the Internet of Things device, contract registration is performed to make the smart contract enter a listening state; The smart contract comprises a payee contract, a payer contract and a payment channel contract; The smart contract listens to an external event, and in the case that the external event meets a trigger condition, the smart contract is converted from the listening state to an execution state to perform Internet of Things payment; In the case that the external event meets the trigger condition, the smart contract is converted from the listening state to the execution state, the payment channel contract is called through the payee contract, and the payer contract is called through the payment channel contract to process a payment request and perform Internet of Things payment; The smart contract in the execution state continues to listen to the external event.

2. The method of claim 1, wherein, The payee contract, the payer contract and the payment channel contract are respectively deployed on one or more Internet of Things devices.

3. The method of claim 1, wherein, After the Internet of Things payment is performed, the following steps are further included: The payee contract receives a payment voucher returned by the payment channel contract and verifies the payment voucher, and in the case that the verification is passed, the Internet of Things payment is completed, wherein the payment voucher is generated after the Internet of Things payment is performed by the payer contract.

4. The method of claim 2, wherein, Further included are: If the payee contract, the payer contract and the payment channel contract are respectively deployed on different Internet of Things devices, the payment channel contract is associated with the payee contract and the payer contract respectively before the smart contract is converted from the listening state to the execution state to perform Internet of Things payment; If the payment channel contract and at least one of the payee contract and the payer contract are deployed on the same Internet of Things device, the payment channel contract is associated with the payee contract and the payer contract respectively when the contract is registered.

5. The method of claim 1, wherein, The smart contract has identity data and can provide an identity verification service; wherein The identity data of the smart contract is realized based on a digital certificate and a digital signature technology when the contract is registered; The identity verification service is based on the identity data of the smart contract and a digest value of executable code of the smart contract.

6. The method of claim 1, wherein, The smart contract has a security level, and before the smart contract is deployed on the Internet of Things device, the following steps are further included: The security level of a module on the Internet of Things device to which the smart contract is to be deployed is obtained; The security level of the module is compared with the security level of the smart contract, and the comparison result meets a security requirement.

7. The method of claim 6, wherein, The smart contract is realized as a software module on the Internet of Things device; The security of a hardware module on the Internet of Things device is realized based on an initial root of trust solidified in the Internet of Things device; And the software module on the Internet of Things device is executed by the initial root of trust or other software modules guided by the initial root of trust.

8. The method of claim 7, wherein, The security level of the module is calculated according to the following principles: The security level of a module is no higher than the security level of the first initial root of trust in a boot execution chain of the module, the boot execution chain being composed of the initial root of trust booting the module or other software modules booting the initial root of trust; The security level of a module enhanced by a module based on another higher security level initial root of trust is higher than the initial root of trust security level; The security level of a module without confidentiality protection when loaded for execution is lower than the initial root of trust security level.

9. An apparatus for Internet of Things payment based on a smart contract, the apparatus comprising: The method comprises: a contract registration module, configured to perform contract registration after deploying the smart contract on the Internet of Things device, so that the smart contract enters a listening state; The smart contract comprises three parts of a payee contract, a payer contract and a payment channel contract; a contract execution module, configured to listen to an external event through the smart contract, and convert the smart contract from the listening state to an execution state to perform Internet of Things payment when the external event meets a trigger condition; The contract execution module is further configured to listen to an external event through the payee contract, convert the smart contract from the listening state to the execution state when the external event meets a trigger condition, call the payment channel contract through the payee contract, call the payer contract through the payment channel contract to process a payment request, and perform Internet of Things payment. The smart contract in the execution state continues to listen to an external event.

10. A mobile electronic device terminal, characterized by The method comprises: one or more processors; a storage device configured to store one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-8.

11. A computer readable medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-8.

Images