Smart contract management authorization method and device, computer equipment and storage medium

Abstract

The invention provides an intelligent contract management authorization method and device, computer equipment and a storage medium. The method comprises the following steps: displaying an intelligent contract list, receiving management triggering of a target intelligent contract in the intelligent contract list, and displaying a physical signature sensing interface corresponding to the target intelligent contract; in response to induction triggering of the target physical device, displaying a physical signature verification interface, and when the target physical device is triggered by induction, sending a physical signature generated by identity information and preset private key information to a triggering object; when a feedback signal indicating that the verification of the physical signature is passed is received, a first prompt label is displayed, and the first prompt label indicates that the verification of the physical signature is passed; and in response to a confirmation operation on the first prompt tag, displaying a second prompt tag, the second prompt tag being used for prompting that the management operation on the target smart contract has been authorized. According to the method, the security of the management authorization process of the smart contract can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a method, device, computer equipment and storage medium for managing and authorizing smart contracts. Background Art

[0002] A smart contract is a computer protocol designed to disseminate, verify or execute contracts in an information-based manner. Smart contracts allow for trusted transaction processing without a third party. Smart contracts are based on blockchain technology. When a trigger condition of a smart contract is met, the smart contract will automatically execute the predetermined operation, thereby improving the efficiency of transaction processing and ensuring that the transaction processing process is transparent and cannot be tampered with.

[0003] Before managing a smart contract, for example, before executing a smart contract, identity authentication and authorization are required from an authorized object to ensure that the execution of the smart contract is authorized, thereby ensuring the security and reliability of the smart contract execution.

[0004] However, the method of managing and authorizing smart contracts in related technologies is not very secure. Summary of the invention

[0005] The embodiments of the present disclosure provide a method, apparatus, computer device, and storage medium for authorizing the management of a smart contract. The method for authorizing the management of a smart contract can improve the security of the process of authorizing the management of a smart contract.

[0006] A first aspect of the present disclosure provides a management authorization method for a smart contract, the method comprising:

[0007] Display a list of smart contracts, receive a management trigger for a target smart contract in the list of smart contracts, and display a physical signature sensing interface corresponding to the target smart contract;

[0008] In response to sensing the induction trigger of the target physical device, displaying a physical signature verification interface, the target physical device stores the identity information of the target object and the preset private key information, and when the target physical device is induction triggered, sends a physical signature generated by the identity information and the preset private key information to the triggering object;

[0009] When receiving a feedback signal indicating that the physical signature verification has passed, displaying a first prompt label, wherein the first prompt label indicates that the physical signature verification has passed;

[0010] In response to a confirmation operation on the first prompt label, a second prompt label is displayed, where the second prompt label is used to prompt that the management operation on the target smart contract has been authorized.

[0011] A second aspect of the present disclosure provides a management authorization device for a smart contract, the device comprising:

[0012] A first display unit, configured to display a list of smart contracts, receive a management trigger for a target smart contract in the list of smart contracts, and display a physical signature sensing interface corresponding to the target smart contract;

[0013] A second display unit is used to display a physical signature verification interface in response to sensing a trigger of a target physical device, wherein the target physical device stores identity information and preset private key information of a target object, and when the target physical device is sensed and triggered, a physical signature generated by the identity information and the preset private key information is sent to the triggering object;

[0014] A third display unit is configured to display a first prompt label indicating that the physical signature verification has passed when a feedback signal indicating that the physical signature verification has passed is received;

[0015] The fourth display unit is used to display a second prompt label in response to a confirmation operation on the first prompt label, wherein the second prompt label is used to prompt that the management operation on the target smart contract has been authorized.

[0016] Optionally, in some embodiments, the fourth display unit includes:

[0017] A first display subunit, configured to display an information collection area in the first prompt label, wherein the information collection area indicates the identity verification information to be collected and input;

[0018] The second display subunit is used to display a second prompt label in response to the trigger of the verification of the identity authentication information, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0019] Optionally, in some embodiments, the second display subunit includes:

[0020] A first display module, used to display a password input field in the information collection area;

[0021] The second display module is used to display a second prompt label in response to the trigger of passing the verification of the password received in the password input field.

[0022] Optionally, in some embodiments, the second display subunit includes:

[0023] a third display module, configured to display a facial recognition control in the information collection area;

[0024] A fourth display module, configured to display a facial image acquisition interface in response to a triggering operation on the facial recognition control;

[0025] The fifth display module is used to display a second prompt label in response to a trigger that the collected facial image is verified to be successful.

[0026] Optionally, in some embodiments, the first display unit includes:

[0027] A third display subunit is used to display a smart contract display list in the smart contract management application, wherein the smart contract display list includes display tags corresponding to multiple smart contracts;

[0028] The fourth display subunit is used to display a physical signature sensing interface corresponding to the target smart contract in response to a triggering operation on a target display tag corresponding to the target smart contract.

[0029] Optionally, in some embodiments, the fourth display subunit includes:

[0030] A sixth display module, configured to display a first status sub-tag in a target display tag corresponding to a target smart contract, and display an execution control when the first status sub-tag indicates that the target smart contract is in a pending execution state;

[0031] a seventh display module, configured to display a physical signature sensing interface corresponding to the target smart contract in response to a triggering operation on the execution control;

[0032] The fourth display unit is further used for:

[0033] In response to a confirmation operation on the first prompt label, a second prompt label is displayed, where the second prompt label is used to prompt that the execution of the target smart contract has been authorized.

[0034] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0035] The fifth display sub-unit is used to display a second display status sub-label in the target display label in response to a trigger operation of displaying the smart contract display interface, wherein the second display status sub-label indicates that the target smart contract is in an execution state.

[0036] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0037] a sixth display subunit, configured to display a stop control when the first status subtag indicates that the target smart contract is in an execution state;

[0038] a seventh display subunit, configured to display the physical signature sensing interface in response to a triggering operation on the abort control;

[0039] an eighth display subunit, configured to display a first prompt label in response to a trigger of the physical signature verification being passed, wherein the first prompt label indicates that the physical signature verification is passed;

[0040] A ninth display subunit is used to display a second prompt label in response to a confirmation operation on the first prompt label, wherein the second prompt label is used to prompt that the termination of the target smart contract has been authorized.

[0041] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0042] a tenth display subunit, configured to display a third prompt label indicating that the physical signature verification has failed, when receiving a feedback signal indicating that the physical signature verification has failed;

[0043] The eleventh display subunit is used to display the physical signature verification interface in response to a triggering operation on the third prompt label.

[0044] Optionally, in some embodiments, the physical signature verification interface includes an authorization mode switching control, and the management authorization device of the smart contract provided by the present application also includes:

[0045] A twelfth display subunit is used to display a first permission verification interface in response to a triggering operation on the authorization mode switching control, wherein the first permission verification interface is used to verify the authorization mode switching permission;

[0046] A thirteenth display subunit is configured to display a second permission verification interface in response to a trigger that the verification of the first verification information received in the first permission verification interface is successful, wherein the second permission verification interface is used to verify the authorization management authority for the target smart contract;

[0047] A fourteenth display sub-unit is used to display the second prompt label in response to the trigger of the verification of the second verification information received in the second permission verification interface being passed, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0048] Optionally, in some embodiments, the first display unit includes:

[0049] A first acquisition subunit, configured to receive a management trigger for a target smart contract and acquire contract information of the target smart contract;

[0050] an issuing subunit, configured to issue broadcast information based on the contract information, wherein the broadcast information is used to trigger a target physical device to generate a physical signature based on the contract information and broadcast the physical signature;

[0051] The fifteenth display subunit is used to display a physical signature sensing interface corresponding to the target smart contract.

[0052] Optionally, in some embodiments, the management authorization device for a smart contract provided by the present application further includes a generation unit, wherein the generation unit includes:

[0053] A first receiving subunit, configured to receive the broadcast information and extract the contract information from the broadcast information;

[0054] A second acquisition subunit is used to acquire the object identity information of the object holding the target physical device, the private key information stored in the target physical device, and a timestamp;

[0055] The first generating subunit is used to generate the physical signature based on the contract information, the object identity information, the private key information and the timestamp.

[0056] Optionally, in some embodiments, the third display unit includes:

[0057] A sending subunit, used to send the physical signature to the smart contract server for signature verification;

[0058] The second receiving subunit is used to receive the signature verification result returned by the smart contract server, and when the signature verification result is passed, display a first prompt label.

[0059] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0060] A third receiving subunit is used to receive an initialization instruction, wherein the initialization instruction includes the object identity information;

[0061] A second generating subunit, configured to generate a key pair based on the object identity information, the key pair comprising public key information and corresponding private key information;

[0062] The broadcast subunit is used to generate a physical device label and broadcast the public key information and the physical device label.

[0063] Optionally, in some embodiments, the first generating subunit comprises:

[0064] A verification module, used to perform permission verification based on the contract information;

[0065] A generation module is used to generate the physical signature based on the contract information, the object identity information, the private key information and the timestamp when the authority verification passes.

[0066] Optionally, in some embodiments, the verification module includes:

[0067] An extraction submodule, used to extract the contract number from the contract information and obtain a preset contract number whitelist;

[0068] The determination submodule is used to determine whether the permission verification is passed when the contract number belongs to the contract number whitelist.

[0069] A third aspect of the present disclosure provides a storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the management authorization method of the smart contract as described in the first aspect.

[0070] A fourth aspect of the present disclosure provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the management authorization method of the smart contract as described in the first aspect is implemented.

[0071] A fifth aspect of the present disclosure provides a computer program product, which includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device executes the management authorization method of the smart contract as described in the first aspect.

[0072] The management authorization method for smart contracts provided by the embodiments of the present disclosure displays a list of smart contracts, receives a management trigger for a target smart contract in the list of smart contracts, and displays a physical signature sensing interface corresponding to the target smart contract; in response to a sensing trigger sensing a target physical device, displays a physical signature verification interface, the target physical device stores the identity information of the target object and preset private key information, and when the target physical device is sensed and triggered, sends a physical signature generated by the identity information and the preset private key information to the triggering object; when a feedback signal of the physical signature verification is received, displays a first prompt label indicating that the physical signature verification is passed; in response to a confirmation operation on the first prompt label, displays a second prompt label, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0073] That is, the management authorization method of the smart contract provided by the embodiment of the present disclosure requires a physical signature through a physical device when authorizing various management operations of the smart contract. Since the private key in the physical signature exists in the physical device, it can be prevented from being stolen by network attacks on the Internet, thereby improving the security of smart contract management authorization.

[0074] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] The accompanying drawings are used to provide further understanding of the technical solution of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.

[0076] Figure 1 A system architecture diagram for a smart contract management authorization method according to an embodiment of the present disclosure;

[0077] Figure 2 A flowchart of a management authorization method for a smart contract provided by the present disclosure;

[0078] Figure 3 A schematic diagram of a scenario of the management authorization method of the smart contract provided in the present disclosure;

[0079] Figure 4 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0080] Figure 5 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0081] Figure 6 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0082] Figure 7 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0083] Figure 8 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0084] Fig. 9 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0085] Fig.10 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0086] Fig.11 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0087] Fig.12Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0088] Fig.13 Another scenario diagram of the management authorization method of the smart contract provided in this application;

[0089] Fig.14 Another flowchart of the management authorization method of the smart contract provided by the present disclosure;

[0090] Fig.15 An interactive sequence diagram of the execution authorization method of the smart contract provided by the present disclosure;

[0091] Fig.16 A schematic diagram of the structure of a management authorization device for a smart contract provided in an embodiment of the present disclosure;

[0092] Fig.17 is a terminal structure diagram for implementing various methods according to an embodiment of the present disclosure;

[0093] Fig.18 It is a server structure diagram for implementing various methods according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0094] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and are not used to limit the present disclosure.

[0095] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0096] Smart contracts (SC): A computer program based on blockchain technology that automatically executes contract terms. It allows trusted resource processing without a third party, and the process of resource processing is traceable and irreversible. The core of smart contracts lies in their ability to automate execution. They are defined in a programming language and stored on the blockchain. Once the preset conditions are triggered, the smart contract will automatically execute the corresponding instructions, thereby improving the efficiency of resource processing.

[0097] Hardware wallet: A physical device used to store private keys, which is highly secure and can prevent private keys from being stolen by cyber attacks and viruses.

[0098] Near Field Communication (NFC): A short-range, high-frequency wireless communication technology that allows contactless data exchange and communication between devices.

[0099] In the related art, since the smart contract will automatically execute the relevant protocol operations when the corresponding trigger conditions are met after the authorization execution, that is, the protocol operation no longer requires authorization or verification authority during subsequent execution, the security of the authorization operation during the execution of the smart contract is extremely important. In particular, for some smart contracts involving large amounts of resource transfer, the security of the execution authorization will affect the security of large amounts of resource transfer. If the security of the execution authorization is insufficient, it may cause greater losses. At present, the execution authorization of smart contracts is generally authorized by software, such as by entering a verification password to authorize the execution of the smart contract. However, the software authorization method is prone to network attacks, or the verification password is stolen by a virus, resulting in insufficient security.

[0100] In order to solve the problem of poor security of management authorization of smart contracts in the above scenarios, the present disclosure provides a management authorization method for smart contracts, in order to improve the security of management authorization of smart contracts to a certain extent.

[0101] System architecture and scenario description of the application of the embodiments of the present disclosure

[0102] Figure 1 It is a system architecture diagram applied by the management authorization method of the smart contract according to the embodiment of the present disclosure, and includes a terminal 140, the Internet 130, a gateway 120, a server 110, and a target physical device 150, etc.

[0103] Terminal 140 includes a variety of devices with NFC functions or devices that can be equipped with NFC functions, such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, vehicle-mounted terminals, home theater terminals, dedicated terminals, intelligent voice interaction devices, smart home appliances or aircraft. In addition, it can be a single device or a collection of multiple devices. Terminal 140 can communicate with Internet 130 in a wired or wireless manner to exchange data. In the disclosed embodiment, terminal 140 can be a terminal loaded with a smart contract management application.

[0104] The server 110 refers to a computer system that can provide certain services to the terminal 140. Compared with the ordinary terminal 140, the server 110 has higher requirements in terms of stability, security, performance, etc. The server 110 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a part of a high-performance computer (such as a virtual machine), a combination of parts of multiple high-performance computers (such as virtual machines), etc. In the embodiment of the present disclosure, the server 110 can specifically be a smart contract management server, which provides functions such as storage, management, and control execution of multiple aspects of data such as content management of multiple smart contracts and management of processing rights of smart contracts.

[0105] The gateway 120 is also called an internetwork connector or a protocol converter. The gateway realizes network interconnection at the transport layer and is a computer system or device that acts as a converter. The gateway is a translator between two systems that use different communication protocols, data formats or languages, or even completely different architectures. At the same time, the gateway can also provide filtering and security functions. The message sent by the terminal 140 to the server 110 must be sent to the corresponding server 110 through the gateway 120. The message sent by the server 110 to the terminal 140 must also be sent to the corresponding terminal 140 through the gateway 120. In the embodiment of the present disclosure, the terminal 140 sends a management request to the server 110 smart contract through the gateway 120, such as an execution request, a suspension request, etc., and the server 110 returns the management authorization verification instruction and the request processing result to the terminal 140 via the gateway 120.

[0106] The management authorization method of the smart contract provided in the embodiment of the present disclosure can be implemented in the terminal 140.

[0107] Specifically, the terminal 140 can display the application interface of the smart contract management application, and then in response to the management trigger of the target smart contract in the application interface, the terminal 140 displays the physical signature sensing interface corresponding to the target smart contract; further, in response to the sensing trigger of the target physical device, the terminal 140 displays the physical signature verification interface, and the target physical device stores the identity information of the target object and the preset private key information. When the target physical device is sensed and triggered, the physical signature generated by the identity information and the preset private key information is sent to the triggering object; then, in response to the trigger of the physical signature verification, the terminal 140 displays a first prompt label, and the first prompt label indicates that the physical signature verification is passed; further, in response to the confirmation operation of the first prompt label, the terminal 140 displays a second prompt label, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0108] The smart contract management authorization method provided by the embodiments of the present disclosure can be applied to various smart contract management authorization scenarios, especially some smart contract management authorization scenarios involving large-scale resource transfers.

[0109] For example, in a smart contract scenario involving large-amount settlements between an enterprise and a supplier, if the smart contract is set to meet the preset trigger conditions, such as the supplier delivering the goods on time and passing the quality inspection of the receiving department, it can trigger the settlement of the corresponding payment to the supplier. When the amount of the payment is small, the method of authorizing the execution of the smart contract can be authorized by software verification such as entering a password or verification code in the relevant technology; but when the amount of the payment is large, the corresponding key may be stolen by software verification methods such as passwords and verification codes under network attacks, resulting in unreliable authorization process, which may cause greater losses to the enterprise. In this scenario, by issuing a hardware wallet with a specific private key to the corporate finance, when it is necessary to authorize the management of such smart contracts, the corporate finance authorizes through the specific private key, thereby avoiding the problem of unreliable authorization process caused by the theft of private keys by network attacks in the software authorization method, and thus causing economic losses caused by the execution of smart contracts.

[0110] The above examples do not limit the scope of protection of this case.

[0111] General description of the disclosed embodiments

[0112] According to one embodiment of the present disclosure, a management authorization method for a smart contract is provided. Figure 2 As shown, it is a flow chart of the management authorization method of the smart contract provided by the present disclosure. The method can be applied to the management authorization device of the smart contract, and the management authorization device of the smart contract can be integrated in a computer device, and the computer device can be specifically a terminal. The management authorization method of the smart contract may include:

[0113] Step 210: display the smart contract list, receive a management trigger for a target smart contract in the smart contract list, and display a physical signature sensing interface corresponding to the target smart contract.

[0114] In the related art, hardware wallets are often used to store and manage private keys, which protect the virtual resources of the object from network attacks by means of physical isolation. When the object transfers virtual resources, a signature can be generated through the hardware wallet, and when the signature verification passes, the virtual resources of the object are transferred to the target resource pool. That is, in the related art, hardware wallets are generally used to provide signatures when virtual resources are transferred. In the disclosed embodiments, the inventors of the present application creatively apply hardware wallet technology to the management authorization of smart contracts to improve the security of smart contract management authorization, thereby ensuring that smart contracts are executed on the basis of valid authorization and avoiding the risks brought by the execution of smart contracts. Below, the solution provided by the present application will be introduced in detail.

[0115] Among them, in the embodiment of the present disclosure, when the terminal receives a management request for a target smart contract, it can display the physical signature sensing interface corresponding to the target smart contract to request the use of a hardware wallet to sign to authorize the management operation of the target smart contract. Specifically, the management operation of the target smart contract can be to execute the operation, terminate the operation, suspend the execution of the operation, and continue the execution of the operation.

[0116] In some embodiments, a list of smart contracts is displayed, and a management trigger for a target smart contract in the list of smart contracts is received, and a physical signature sensing interface corresponding to the target smart contract is displayed, including:

[0117] Display the smart contract display list in the smart contract management application, and the smart contract display list includes display tags corresponding to multiple smart contracts;

[0118] In response to a triggering operation on a target display tag corresponding to a target smart contract, a physical signature sensing interface corresponding to the target smart contract is displayed.

[0119] In the disclosed embodiments, the management authorization method of the smart contract provided by the present application can be applied to the smart contract management application. In the smart contract management application, various types of smart contracts can be managed. Specifically, when the smart contract management application is opened, the smart contract display interface can be displayed. In the smart contract display interface, the smart contract display list can be displayed; in the smart contract display list, display tags corresponding to multiple smart contracts can be displayed. Then, the operation object can select a target display tag from the display tags corresponding to the multiple smart contracts, and then the physical signature sensing interface corresponding to the target smart contract can be further displayed.

[0120] like Figure 3As shown, a schematic diagram of a scenario of management authorization of a smart contract provided by the present disclosure is provided. As shown in the figure, in response to a trigger for displaying a smart management contract received in a smart management application, a smart contract display interface 300 is displayed. In the smart contract display interface 300, multiple display tags 310 may be displayed.

[0121] like Figure 4 As shown, another schematic diagram of the management authorization of the smart contract provided by the present disclosure is shown. Figure 3 The triggering of any target display tag among the multiple display tags 310 in the physical signature sensing interface 400 of the target smart contract corresponding to the selected target display tag can be displayed. In the physical signature sensing interface 400, an operation prompt image 420, an operation prompt text 430 and a reading control 410 can be displayed. Among them, the operation prompt text is used to inform the user of the specific operation process of using the hardware wallet to perform the signature authorization of the smart contract management operation; the operation prompt image further displays the operation process in the form of a diagram, so that the user can further perceive the operation content clearly and improve the operation experience of smart contract signature authorization. When the user brings the hardware wallet close to the sensing position of the sensing terminal, the reading control 410 can be further touched to make the sensing terminal sense and read the hardware wallet. It can be understood that the physical signature sensing interface 400 here is only an example when the sensing terminal is a mobile phone. In some other embodiments, the sensing terminal can also be a tablet, a personal computer or other smart devices. When the sensing terminal is a tablet, a personal computer or other smart device, the operation prompt text and the operation prompt image can be adaptively adjusted, for example, the operation prompt text can be adjusted to "Please put the hardware wallet close to the sensing device".

[0122] The triggering of the target display tag can be triggered by single-clicking the target display tag, double-clicking the target display tag, short-pressing the target display tag, or long-pressing the target display tag. In some embodiments, in response to the triggering operation of the target display tag corresponding to the target smart contract, the physical signature sensing interface corresponding to the target smart contract is displayed, including:

[0123] In the target display tag corresponding to the target smart contract, a first display status sub-tag is displayed, and when the first status sub-tag indicates that the target smart contract is in a pending execution state, an execution control is displayed;

[0124] In response to the triggering operation on the execution control, the physical signature sensing interface corresponding to the target smart contract is displayed.

[0125] That is, in the embodiment of the present disclosure, in the display tag corresponding to the smart contract, a status sub-tag may be further displayed, and the status sub-tag may display the status information of the smart contract corresponding to the display tag. Among them, the status information may include pending execution status, executing status, suspended execution status, and completed execution status. Specifically, a first display status sub-tag may be displayed in the target display tag corresponding to the target smart contract, and when the first status sub-tag indicates that the target smart contract is in a pending execution state, an execution control may be further displayed. Then, the user object may display the physical signature sensing interface corresponding to the target smart contract by triggering the execution control.

[0126] like Figure 5 As shown, it is another scenario diagram of the management authorization of the smart contract provided by the present disclosure. As shown in the figure, in the display label 310, a status sub-label 311 and a management control 312 can be further displayed. When the status sub-label 311 indicates that the state of smart contract A is to be executed, the management control 312 can be an execution control, and in response to the triggering of the management control 312, the execution of smart contract A can be initiated; or, when the status sub-label 311 indicates that the state of smart contract A is in the execution state, the management control 312 can be a suspended execution control, and in response to the triggering of the management control 312, the suspension of execution of smart contract A can be initiated; or, when the status sub-label 311 indicates that the state of smart contract A is suspended execution, the management control 312 can be a continue execution control, so in response to the triggering of the management control 312, the execution of smart contract A can be continued.

[0127] That is, in some embodiments, after displaying the first display status sub-label in the target display label corresponding to the target smart contract, the method further includes:

[0128] When the first status sub-label indicates that the target smart contract is in the execution state, displaying the abort control;

[0129] In response to triggering the abort control, a physical signature sensing interface is displayed.

[0130] In some embodiments, the reading control 410 may not be displayed in the physical signature sensing interface 400. In this embodiment, when entering the physical signature sensing interface 400, the management authorization device of the smart contract can sense the hardware wallet, and automatically start reading when the hardware wallet is sensed.

[0131] In some embodiments, receiving a management trigger for a target smart contract in the smart contract list and displaying a physical signature sensing interface corresponding to the target smart contract includes:

[0132] Receive management triggers for target smart contracts and obtain contract information of target smart contracts;

[0133] Sending broadcast information based on the contract information, the broadcast information is used to trigger the target physical device to generate a physical signature based on the contract information and broadcast the physical signature;

[0134] Display the physical signature sensing interface corresponding to the target smart contract.

[0135] In the disclosed embodiment, when an object is used to initiate a management instruction for a target smart contract, the management authorization device of the smart contract can, in addition to displaying a physical signature sensing interface corresponding to the target smart contract, obtain the contract information of the target smart contract, such as the contract number or contract ID, and then send out a broadcast message based on the obtained contract information. The broadcast message can trigger the target physical device to generate a physical signature based on the contract information contained in the broadcast message, and trigger the target physical device to broadcast the generated physical signature.

[0136] like Figure 6 As shown, it is another schematic diagram of the management authorization of the smart contract provided by the present disclosure. As shown in the figure, when the user touches the reading control 410 in the physical signature sensing interface 400, the hardware wallet sensing interface 600 can be further displayed. In the hardware wallet sensing interface 600, a sensing prompt label 610 can be displayed to further prompt the user to place the hardware wallet correctly for convenient sensing. In addition, the sensing status label 620 can be further displayed in the hardware wallet sensing interface 600 to prompt that the hardware wallet is currently being sensed.

[0137] Step 220 , in response to sensing a trigger of the target physical device, displaying a physical signature verification interface.

[0138] When the user places the hardware wallet in the sensing area of ​​the smart contract management authorization device, the smart contract management authorization device can start to sense the hardware wallet. After sensing the hardware wallet, the signature transmitted by the sensed hardware wallet can be further verified, and the physical signature verification interface can be displayed in the display interface of the smart contract management authorization device. Among them, the hardware wallet can be specifically a target physical device that can store a key, and the target physical device communicates with the smart contract management authorization device using NFC technology. The target physical device stores the identity information and preset private key information of the target object. When the target device is triggered by induction, it sends a physical signature generated by the identity information and the preset private key information to the triggering object.

[0139] The target object may specifically be an object that has the authority to authorize the management of the target smart contract, such as a financial manager of an enterprise or a middle or senior manager of a bank.

[0140] like Figure 7 As shown, it is another schematic diagram of the management authorization of the smart contract provided by the present disclosure. As shown in the figure, when the management authorization device of the smart contract senses the existence of the hardware wallet, that is, after receiving the physical signature sent by the hardware wallet, the physical signature verification interface 700 can be further displayed. In the physical signature verification interface 700, the sensing prompt label 610 can still be displayed, but the sensing status label 620 will be switched to the signature verification label 710. To indicate that the hardware signature sent by the hardware wallet has been received and is being verified.

[0141] In some embodiments, the specific process of generating a physical signature of the target physical device based on the contract information includes the following steps:

[0142] Receive broadcast information and extract contract information from the broadcast information;

[0143] Obtaining object identity information of an object holding the target physical device, private key information stored in the target physical device, and a timestamp;

[0144] Generate a physical signature based on contract information, object identity information, private key information and timestamp.

[0145] Among them, when the object is used to bring the target physical device close to the management authorization device of the smart contract or the sensing device connected to the authorization management device of the smart contract, the target physical device senses the broadcast information containing the contract information of the target smart contract sent by the authorization management device of the smart contract, and can extract the contract information from the broadcast information. Then, the target physical device can obtain the object identity information of the object it holds, the stored private key information and the timestamp of the current moment, and then generate a physical signature based on the contract information, object identity information, private key information and timestamp.

[0146] When the target physical device generates a physical signature, the generated physical signature can be further broadcast. When the management authorization device of the smart contract receives the broadcast information sent by the target physical device, the physical signature can be extracted from the broadcast information and start to verify the extracted physical signature.

[0147] In some embodiments, before the hardware wallet is used to authorize the management operation of the smart contract, the hardware wallet may be activated first, wherein the activation process of the hardware wallet may include the following steps:

[0148] receiving an initialization instruction, wherein the initialization instruction includes object identity information;

[0149] Generate a key pair based on the object identity information, the key pair including public key information and corresponding private key information;

[0150] Generate a physical device tag and broadcast the public key information and the physical device tag.

[0151] In the disclosed embodiment, the activation of the hardware wallet may be performed by a hardware wallet activation device, which may receive a hardware wallet initialization instruction input by a user, and the hardware wallet initialization instruction may include the object identity information. The object identity information here may specifically be the identity information of the object that has the authorization authority to perform management operations on the smart contract.

[0152] Then, the hardware wallet activation device can generate a key pair based on the object identity information, and the key pair includes public key information and corresponding private key information. Furthermore, the hardware wallet activation device can also automatically generate a physical device tag, and then broadcast the public key information and physical device tag of the hardware wallet.

[0153] Among them, the activation device of the hardware wallet can provide an interface for inputting the object identity information, so that the user can input the corresponding information. Figure 8 As shown, it is another scenario schematic diagram of the management authorization of the smart contract provided by the present disclosure. As shown in the figure, the hardware wallet activation device can display the hardware wallet management interface 800, and the hardware wallet activation device communicates with the hardware wallet to be activated through NFC connection. In the hardware wallet management interface 800, an object identity information input area 810 and a hardware wallet activation control 820 can be displayed. Among them, in the object identity information input area 810, the object can enter identity parameters such as name, mobile phone number and ID card. After entering these identity parameters, the wallet activation control 820 can be clicked, so that the hardware wallet activation device sends the object identity information to the hardware wallet for storage through the NFC connection, and triggers the hardware wallet to generate a public-private key pair, and then saves the private key in the hardware wallet, and broadcasts the public key to the smart contract management device.

[0154] The hardware wallet in the related art adopts an anonymous method, that is, the hardware wallet only stores private key information but not object identity information, while in the embodiment of the present application, the hardware wallet is issued in a named manner, that is, in addition to the private key information, the object identity information can also be stored in the hardware wallet. Compared with the scheme of using the hardware wallet for physical signature when the hardware wallet only stores private key information in the related art, the scheme provided by the present application stores not only the private key information but also the object identity information in the hardware wallet, so that the security of smart contract management authorization can be further improved by combining hardware signature and software signature. Because the hardware wallet in the related art only stores the private key, if the hardware wallet is lost and picked up or stolen by others, the hardware wallet can be directly used for physical signature authorization, while in the embodiment of the present disclosure, even if the hardware wallet is picked up or stolen by others, it is still necessary to further verify the software authorization to realize the management authorization of the smart contract, thereby further improving the security of the management authorization of the smart contract.

[0155] In some embodiments, generating a physical signature based on contract information, object identity information, private key information, and a timestamp includes:

[0156] Verify permissions based on contract information;

[0157] When the permission verification is passed, a physical signature is generated based on the contract information, object identity information, private key information and timestamp.

[0158] In the disclosed embodiment, after the hardware wallet receives the broadcast information broadcast by the management authorization device of the smart contract and extracts the contract information from the broadcast information, it can first perform permission verification based on the contract information, and only trigger the generation of a physical signature based on the contract information, object identity information, private key information and timestamp after the permission verification is passed.

[0159] That is, in the management authorization method of the smart contract provided in this application, the hardware wallet only performs hardware signature authorization for some authorized smart contracts. The authority can be a pre-set authority, such as which smart contracts have the authority to trigger the hardware wallet to generate a physical signature; or it can be determined based on the amount of virtual resources involved in the smart contract, for example, when the amount of virtual resource transfer executed reaches a certain preset amount, the smart contract can trigger the hardware wallet to generate a physical signature. In this way, two-way verification between the hardware wallet and the smart contract can be achieved, thereby further improving the security of the management authorization process of the smart contract.

[0160] In some embodiments, performing permission verification based on contract information includes:

[0161] Extract the contract number from the contract information and obtain the preset contract number whitelist;

[0162] When the contract number belongs to the contract number whitelist, it is confirmed that the permission verification is passed.

[0163] In the disclosed embodiment, the hardware wallet can store a whitelist of contract numbers of authorized smart contracts in the hardware wallet when it is initialized. Then, when the hardware wallet extracts the contract number of the target smart contract from the broadcast information, it can match the contract number with the whitelist of contract numbers stored therein. When it is determined that the contract number belongs to the whitelist of contract numbers, it can be determined that the permission verification has passed.

[0164] When the permission verification is passed, the hardware wallet can generate a physical signature based on the contract information, object identity information, private key information and timestamp. Conversely, when the permission verification fails, the hardware wallet will not generate a physical signature.

[0165] Step 230: When a feedback signal indicating that the physical signature verification is successful is received, a first prompt label is displayed.

[0166] Among them, when the management authorization device of the smart contract senses the physical signature broadcast by the hardware wallet, it can trigger the verification of the physical signature. Specifically, the management authorization device of the smart contract can send the received physical signature broadcast by the hardware wallet to the smart contract management server, and the smart contract management server verifies the physical signature. Specifically, the smart contract management server obtains the pre-stored public key information, and then uses the pre-stored public key information to verify the physical signature. When the physical signature verification passes, the smart contract management server sends an instruction to the smart contract management authorization device, which can cause the smart contract management authorization device to display a first prompt label, and the first prompt label is used to prompt that the physical signature verification passes.

[0167] like Fig. 9 As shown, it is another scenario schematic diagram of the smart contract management authorization provided by the present application. As shown in the figure, in response to the triggering of the physical signature verification, the verification result interface 900 is displayed, and the first prompt label 910 is displayed in the verification result interface 900. Among them, the verification result prompt text can be displayed in the first prompt label 910 to prompt the verification result of the physical signature broadcast by the hardware wallet. For example, the prompt text can be verification successful. Among them, in some embodiments, a confirmation control 911 can also be displayed in the first prompt label 910, that is, after the physical signature verification of the hardware wallet is passed, the management operation of the smart contract can be not directly executed, and the management operation of the smart contract can be started after further confirmation of the use object (for example, touching the confirmation control 911).

[0168] In some embodiments, the management authorization method of the smart contract provided by the present application further includes:

[0169] When a feedback signal indicating that the physical signature verification fails is received, a third prompt label is displayed, wherein the third prompt label indicates that the physical signature verification fails;

[0170] In response to a triggering operation on the third prompt tag, a physical signature verification interface is displayed.

[0171] In an embodiment of the present application, when the verification result of the physical signature by the smart contract management server is not passed, an instruction of verification failure can be sent to the management authorization device of the smart contract. When the management authorization device of the smart contract receives the instruction of verification failure, a third prompt label can be displayed, and the third prompt label indicates that the physical signature verification has not passed. Specifically, a prompt text, such as verification failure, can be displayed in the third prompt label.

[0172] Then, the user can trigger the re-acquisition and verification of the physical signature of the hardware wallet by triggering the third prompt tag. For example, in the third prompt tag, a re-verification control can be further displayed, and in response to the touch operation of the re-verification control, the physical signature verification interface can be redisplayed.

[0173] In some embodiments, the physical signature verification interface includes an authorization mode switching control, and the method further includes:

[0174] In response to a triggering operation on the authorization mode switching control, displaying a first permission verification interface, the first permission verification interface is used to verify the authorization mode switching permission;

[0175] In response to a trigger that the verification of the first verification information received in the first permission verification interface is successful, a second permission verification interface is displayed, where the second permission verification interface is used to verify the authorization management authority for the target smart contract;

[0176] In response to the triggering of successful verification of the second verification information received in the second permission verification interface, a second prompt label is displayed, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0177] In the disclosed embodiment, when a physical signature is obtained from a hardware wallet, and then the obtained physical signature is verified but the verification result fails, and the verification result fails after multiple re-verifications, a backup scheme for authorizing the management operation of the target smart contract can be further provided. Specifically, when the third prompt tag is triggered and the physical signature verification interface is displayed, an authorization mode switching control can be further displayed in the physical signature verification interface, and in response to the triggering operation of the authorization mode switching control, a first permission verification interface can be displayed, and the first permission verification interface is used to verify the authorization mode switching permission.

[0178] When the first verification information is received in the first permission verification interface, the first verification information can be verified. When the first verification information is verified, the second permission verification interface can be triggered to display, and the second permission verification interface is used to verify the authorized management authority of the target smart contract. Then, when the second verification information is received in the second permission verification interface, the second verification information can be verified. When the second verification information is verified, the above-mentioned second prompt label can be displayed, that is, a prompt is displayed to indicate that the management operation of the target smart contract has been authorized.

[0179] like Fig.10 As shown, it is another scenario schematic diagram of the management authorization of the smart contract provided by the present disclosure. As shown in the figure, when the physical signature verification interface 400 is further displayed in response to the trigger operation of the third prompt tag, the authorization method switching control 1010 can be displayed in the physical signature verification interface 400. In response to the trigger operation of the authorization method switching control 1010, the first permission verification interface 1100 for verifying the authorization method switching permission can be further displayed. In the first permission verification interface 1100, a first verification information input area 1110 can be displayed, and the user can enter the first verification information in the first verification information input area. Furthermore, a confirmation change control 1120 can be further displayed in the first permission verification interface 1100, and the user can change the authorization method by touching the confirmation change control 1120.

[0180] Further, in response to the triggering operation of the confirmation change control 1120, the first verification information input in the first permission verification interface 1110 can be verified. When the first verification information is verified, the second permission verification interface 1200 can be further displayed. In the second permission verification interface 1200, a second verification information input area 1210 can be displayed, and the user can enter the second verification information in the second verification information input area 1210. In addition, an authorization verification control 1220 can be further displayed in the second permission verification interface 1200. In response to the triggering operation of the authorization verification control 1220, the second verification information can be verified, and when the verification is passed, the second prompt label can be displayed.

[0181] In the disclosed embodiment, when the authorization of the management operation process of the smart contract using hardware signature authorization fails, a two-layer authorization method can be further provided to remedy the management authorization of the smart contract, so as to avoid the management authorization process of the smart contract being affected due to the loss or damage of the hardware wallet. Compared with the one-layer software authorization method in the related technology, the two-layer authorization method can also improve the security of the management authorization process of the smart contract to a certain extent.

[0182] Step 240: In response to a confirmation operation on the first prompt label, display a second prompt label.

[0183] When the management authorization device of the smart contract verifies the physical signature, a first prompt label indicating that the physical signature verification has been passed may be displayed. Then, in response to the confirmation operation of the first prompt label, a second prompt label may be displayed, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0184] Specifically, a confirmation control 911 may be displayed in the first prompt label (see Fig. 9 ), in response to the touch operation on the confirmation control 911, a second prompt label can be displayed.

[0185] In some embodiments, in response to a confirmation operation on the first prompt label, a second prompt label is displayed, and the second prompt label is used to prompt that the management operation on the target smart contract has been authorized, including:

[0186] An information collection area is displayed in the first prompt label, and the information collection area indicates the identity authentication information to be collected and input;

[0187] In response to the triggering of successful verification of the identity authentication information, a second prompt label is displayed, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0188] In the disclosed embodiment, a management authorization method for a smart contract that requires a combination of a physical signature of a hardware wallet and a software signature is provided. That is, after the physical signature of the hardware wallet is verified and the first prompt label is displayed, an information collection area can be displayed in the first prompt label, and the information collection area indicates the identity authentication information that is collected and input. When the identity authentication information input in the information collection area is verified, a second prompt label can be displayed.

[0189] like Fig.13 As shown, it is another schematic diagram of a scenario of smart contract management authorization provided by the present application. As shown in the figure, when the first prompt label 910 is displayed, the information collection area 1310 can be further displayed in the first prompt label 910, and the user can enter the identity authentication information in the information collection area 1310. In addition, in the first prompt label 910, a verification control 1320 can also be displayed. In response to the touch operation of the verification control 1320, the verification of the identity authentication information collected in the information collection area 1310 can be triggered. When the identity authentication information collected in the information collection area 1310 is verified, the second prompt label can be displayed.

[0190] That is, in the embodiment of the present application, after the physical signature provided by the hardware wallet is verified, the software authorization verification must be further performed. Only when both the physical signature authorization verification and the software authorization verification of the hardware wallet are passed, the management authorization of the target smart contract can be realized. This method can further improve the security of the smart contract management authorization process.

[0191] As described above, in the disclosed embodiment, the hardware wallet adopts a registered issuance method, that is, during the initialization process of the hardware wallet, the identity information of the preset object will be stored in the hardware wallet. When the hardware wallet generates a hardware signature, not only can the private key information be packaged into the physical signature, but also the identity information of the preset object can be packaged into the physical signature. Then, when verifying the physical signature, the verification is performed using the preset public key and the private key in the physical signature; after the physical signature verification is passed, the identity information of the preset object can be further extracted from the physical signature, and then the corresponding information collection area 1310 is displayed based on the identity information of the preset object. After receiving the identity authentication information entered in the information collection area 1310, the identity authentication information is verified based on the identity information of the preset object.

[0192] In some embodiments, in response to a trigger that the identity authentication information is verified successfully, displaying a second prompt label includes:

[0193] Display a password input field in the information collection area;

[0194] In response to a trigger that the password received in the password input field is verified successfully, a second prompt label is displayed.

[0195] In the disclosed embodiment, when the identity information of the preset object is stored in the hardware wallet, the corresponding account and password can be registered in the smart contract management server using the identity information of the preset object. Then, when performing software authorization verification, a password input field can be displayed in the information collection area. After receiving the input password in the password input field, it can be matched with the password corresponding to the registered account. If they can match, it is determined that the verification is passed; otherwise, it is determined that the verification is not passed.

[0196] In some embodiments, in response to a trigger that the identity authentication information is verified successfully, displaying a second prompt label includes:

[0197] Display facial recognition controls in the information collection area;

[0198] In response to a triggering operation on the facial recognition control, displaying a facial image acquisition interface;

[0199] In response to a trigger that the collected facial image is verified to be successful, a second prompt label is displayed.

[0200] In some embodiments, a facial recognition control may be displayed in the information collection area, and then in response to a trigger operation on the facial recognition control, a facial image collection interface may be displayed. Further, when the collected facial image passes verification, a second prompt label may be displayed. That is, in the disclosed embodiment, facial recognition may be used to perform software authorization on the management operation of the smart contract.

[0201] In some embodiments, in response to a trigger that the identity authentication information is verified successfully, displaying a second prompt label includes:

[0202] Display graphic drawing labels in the information collection area;

[0203] In response to a trigger that the verification of the drawing operation received in the graphics drawing tag passes, a second prompt tag is displayed.

[0204] In the disclosed embodiment, software authorization verification can be performed by using a graphic drawing method, that is, a graphic drawing label can be displayed in the information collection area, and then in response to the verification of the drawing operation received in the graphic drawing label being triggered, a second prompt label can be displayed.

[0205] In some embodiments, in response to a trigger that the identity authentication information is verified successfully, displaying a second prompt label includes:

[0206] Display the mobile phone number input box and verification code input box in the information collection area;

[0207] In response to the trigger of successful verification of the received mobile phone number and verification code, a second prompt label is displayed.

[0208] In the disclosed embodiment, a combination of a mobile phone number and a verification code can be used to perform software authorization verification for management operations of smart contracts. Specifically, a mobile phone number input box and a verification code input box can be displayed in the information collection area. The user can enter the mobile phone number in the mobile phone number input box and then enter the corresponding verification code in the verification code input box. When the mobile phone number and the verification code are verified, the second prompt label can be displayed.

[0209] The management authorization method for a smart contract provided by the embodiment of the present disclosure displays a physical signature sensing interface corresponding to the target smart contract in response to a management trigger of the target smart contract; displays a physical signature verification interface in response to a sensing trigger of a target physical device, wherein the target physical device stores the identity information of the target object and preset private key information, and when the target physical device is sensed and triggered, a physical signature generated by the identity information and the preset private key information is sent to the triggering object; displays a first prompt label in response to a trigger of a passed physical signature verification, and the first prompt label indicates that the physical signature verification has passed; displays a second prompt label in response to a confirmation operation on the first prompt label, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0210] That is, the management authorization method of the smart contract provided by the embodiment of the present disclosure requires a physical signature through a physical device when authorizing various management operations of the smart contract. Since the private key in the physical signature exists in the physical device, it can be prevented from being stolen by network attacks on the Internet, thereby improving the security of smart contract management authorization.

[0211] The embodiments of the present disclosure are described in detail in combination with specific application scenarios.

[0212] like Fig.14 As shown, it is another flow chart of the management authorization method of the smart contract provided by the present disclosure. This embodiment will introduce the management authorization method of the smart contract in detail in combination with the execution subject of each step. The method specifically includes the following steps:

[0213] Step 1401: The hardware wallet initialization device receives input object information and sends the object information to the hardware wallet.

[0214] In the related art, the execution authorization of smart contracts is generally carried out in the form of software authorization, that is, when receiving the execution request of a smart contract from the user, the management authorization device of the smart contract can display the identity authentication interface for the user to enter the identity authentication information. Then, when the smart contract management server verifies the identity authentication information sent by the management authorization device of the smart contract and the verification result is qualified, the execution of the target smart contract can be triggered.

[0215] However, due to the unpredictable network security risks on the Internet, the identity authentication information required for the execution authorization of smart contracts may be at risk of being leaked by network attacks. If the amount of resources involved in the automatically executed virtual resource transfer involved in the smart contract is small, even if the identity authentication information is leaked, the economic loss caused is limited; however, when the amount of resources involved in the automatically executed virtual resource transfer involved in the smart contract is large, if the identity authentication information is leaked by a network attack, it will cause great economic losses. Therefore, in this type of scenario, it is necessary to adopt a secure smart contract execution authorization scheme to avoid the risk of economic losses caused by insufficient execution authorization security for smart contracts involving a large amount of virtual resources. The management authorization method for smart contracts provided in this application will be described in detail below. As described above, the management operations of smart contracts may include execution, suspension of execution, continuation of execution, termination of execution and other operations. This embodiment will take the execution method of smart contracts as an example for detailed introduction.

[0216] The execution authorization method of the smart contract provided in the embodiments of the present disclosure is specifically a smart contract execution authorization method based on a hardware wallet. Since the hardware wallet has the technical advantage of using hardware to store private key information, thereby avoiding the leakage of private key information caused by Internet network attacks, the use of a hardware wallet to execute authorization for smart contracts can improve the security of smart contract execution authorization.

[0217] In the embodiment of the present disclosure, before using a hardware wallet to execute authorization for a smart contract, the hardware wallet can be initialized first, and the initialized hardware wallet can be issued to the user. When the hardware wallet is initialized, the hardware wallet initialization device can communicate with the physical device corresponding to the hardware wallet through NFC technology, and then the hardware wallet initialization device can display an initialization interface so that the user can enter object information in the initialization interface. When the hardware wallet initialization device receives the object information entered by the user in the initialization interface and receives the initialization instruction entered by the user, it can start to initialize the hardware wallet. Specifically, the hardware wallet initialization device can send an initialization instruction carrying object information to the hardware wallet through NFC technology.

[0218] Step 1402, the hardware wallet stores the object information and generates a public-private key pair, stores the private key in the hardware wallet and returns the public key and the hardware wallet tag to the hardware wallet initialization device.

[0219] After receiving the initialization instruction, the hardware wallet stores the object information in the hardware wallet and starts to generate a public-private key pair and a hardware wallet tag (i.e., the hardware wallet ID), i.e., a public key (Pub) and a private key (Pri). Then, the hardware wallet stores the public-private key pair locally and returns the hardware wallet ID and public key to the hardware wallet initialization device.

[0220] Among them, the process of the hardware wallet generating a public-private key pair can be to generate the corresponding public-private key pair based on the object information, or to generate the public-private key pair according to a preset rule.

[0221] Step 1403: The hardware wallet initialization device sends the hardware wallet tag and the public key to the smart contract management server for storage.

[0222] After receiving the hardware wallet ID and public key information returned by the hardware wallet, the hardware wallet initialization device can further establish a communication connection with the smart contract management server, thereby sending the hardware wallet ID and public key information to the smart contract management server, and the smart contract management server stores the received hardware wallet tag and public key information.

[0223] In some embodiments, the smart contract management server can further obtain the tag information of the smart contract, and then associate the tag information of the smart contract with the hardware wallet tag. Specifically, it can be set that only the smart contracts whose amount of transferred virtual resources corresponding to the automatically executed virtual resource transfer event is greater than the preset threshold need to use the hardware wallet for execution authorization, that is, only the tag information of these smart contracts is associated with the hardware wallet tag, and the tag information of other smart contracts is not associated with the hardware wallet tag, so that other smart contracts do not need to use the hardware wallet for execution authorization when executing authorization.

[0224] Step 1404, in response to the smart contract viewing request, the smart contract management authorization device obtains the smart contract information and displays the smart contract list.

[0225] Among them, when the user object opens the smart contract management application loaded in the smart contract management authorization device and initiates a smart contract viewing request to view the smart contract in the smart contract management application, the smart contract management authorization device can obtain smart contract information from the smart contract management server and display the smart contract list. The smart contract list can display the information of all smart contracts managed by the smart contract management server, and can also display the information of some smart contracts.

[0226] Specifically, the smart contract viewing request can carry category information of the smart contracts that you want to view, such as only viewing smart contracts involving a resource transfer amount greater than a preset threshold; or only viewing smart contracts associated with a specific financial institution or a specific enterprise.

[0227] Step 1405, in response to receiving the execution request for the target smart contract, the management authorization device of the smart contract broadcasts an authorization signature request for the target smart contract.

[0228] After displaying the list of smart contracts, the user can select a target smart contract from the list of smart contracts, and then initiate the execution of the selected target smart contract. After receiving the execution request for the target smart contract input by the user, the management and authorization device of the smart contract starts to initiate the hardware signature authorization process of the smart contract. Specifically, the management and authorization device of the smart contract can first display the physical signature sensing interface of the target smart contract, and then the user can initiate the sensing instruction to the hardware wallet in the physical signature sensing interface. After receiving the sensing instruction to the hardware wallet, the management and authorization device of the smart contract can start broadcasting the authorization signature request for the target smart contract.

[0229] Step 1406: The hardware wallet obtains the timestamp, contract information, hardware wallet tag information, and object information according to the authorization signature request to generate a physical signature, and broadcasts the physical signature.

[0230] When the object is used to bring the hardware wallet close to the management authorization device of the smart contract, the hardware wallet can sense the authorization signature request for the target smart contract broadcast by the management authorization device of the smart contract. After sensing the authorization signature request, the hardware wallet can obtain the corresponding timestamp according to the authorization signature request, as well as the contract information, hardware wallet tag information and object information. Then, a physical signature can be generated based on the obtained timestamp, contract information, hardware wallet tag information and object information.

[0231] The contract information may specifically refer to the contract number information of the target smart contract. When the hardware wallet generates a physical signature based on the acquired information, it may first verify the contract number information. When the contract number information is the contract number corresponding to the smart contract for which a physical signature needs to be generated, a physical signature is generated. Otherwise, no physical signature may be generated.

[0232] After the hardware wallet generates a physical signature based on the acquired information, it can further broadcast the physical signature to send the generated physical signature to the management authorization device of the smart contract through NFC technology.

[0233] Step 1407, the management authorization device of the smart contract senses the broadcast physical signature and sends the physical signature to the smart contract management server.

[0234] After broadcasting the authorization signature request of the target smart contract, the management authorization device of the smart contract can start sensing the physical signature broadcast by the hardware wallet. When the management authorization device of the smart contract senses the physical signature broadcast by the hardware wallet, it can trigger the verification process of the sensed hardware signature.

[0235] Specifically, after sensing the physical signature broadcast by the hardware wallet, the management authorization device of the smart contract can send a smart contract verification request carrying the physical signature to the smart contract management server, so that the smart contract management server starts to verify the physical signature after receiving the smart contract verification request.

[0236] Step 1408: The smart contract management server verifies the physical signature based on the public key and returns the verification result to the management authorization device of the smart contract.

[0237] After receiving a smart contract verification request with a physical signature, the smart contract management server can first obtain the pre-stored public key information, and then use the public key information to verify the physical signature contained in the smart contract verification request. Then, the smart contract management server can further send the verification result of the physical signature to the smart contract management authorization device for display.

[0238] Specifically, when the verification result of the physical signature is failure, the smart contract management server can send a verification failure notification message to the management authorization device of the smart contract. At this time, a verification failure prompt can be displayed in the display interface of the management authorization device of the smart contract, thereby prompting the user to further retry authorization based on the hardware wallet or switch to other authorization methods for authorization.

[0239] When the verification result of the physical signature is passed, the smart contract management server can send a verification passed notification message to the management authorization device of the smart contract. At this time, a prompt of successful verification can be displayed in the display interface of the management authorization device of the smart contract.

[0240] Step 1409: The management authorization device of the smart contract receives the confirmation authorization instruction and sends an execution instruction for the target smart contract to the smart contract management server.

[0241] When the verification result of the smart contract management server for the physical signature is a passed verification, and the management authorization device of the smart contract displays a prompt of the passed verification in its display interface, the user can further perform a confirmation authorization operation, thereby sending a confirmation authorization instruction to the management authorization device of the smart contract. After the management authorization device of the smart contract receives the confirmation authorization instruction, it can further send an execution instruction for the target smart contract to the smart contract management server. After receiving the execution instruction for the target smart contract, the smart contract management server can trigger the execution of the target smart contract.

[0242] Specifically, the smart contract management server can generate various execution instructions based on the smart contract, and then send the various execution instructions to multiple execution terminals to execute the target smart contract. During the execution of the smart contract, the execution terminal can also feed back the execution result of the smart contract to the smart contract management server in real time, and the smart contract management server can feed back the execution result to the management authorization device of the smart contract for display.

[0243] like Fig.15 As shown, it is an interactive sequence diagram of the execution authorization method of the smart contract provided by the present application. As shown in the figure, at the beginning of the scheme, the management terminal 1520 sends an initialization instruction to the hardware wallet 1530, so that the hardware wallet 1530 starts the initialization operation. Specifically, the recipient of the hardware wallet can first obtain a hardware wallet that has not been initialized and configured. The hardware wallet can be a physical device equipped with an integrated circuit (IC) card, such as a card or other non-sheet object. Then, the hardware wallet that has not been initialized and configured is connected to the management terminal 1520. Specifically, the connection can be made using NFC technology, or by inserting the hardware wallet into the management terminal 1520. Among them, the management terminal 1520 can be a separate initialization device or a device combination consisting of a parameter acquisition device and an initialization execution device. When the management terminal 1520 is a device combination consisting of a parameter collection device and an initialization execution device, the hardware wallet to be initialized can be first connected to the initialization execution device through NFC connection or card insertion connection, and then a parameter collection page for collecting the initialization parameters required for the initialized hardware wallet can be displayed on the parameter collection device. The issuing object of the hardware wallet can enter the identity parameters of the issuing object of the hardware wallet in the parameter collection page, such as name, mobile phone number, and ID card number, etc., where these parameters can be used to initialize the hardware wallet on the basis of being provided and authorized by the issuing object. After collecting the above-mentioned object parameters, the parameter collection device can further receive the initialization instruction input by the issuing object, so as to transmit these object parameters to the hardware wallet to be initialized through the initialization execution device.

[0244] The hardware wallet 1530 first stores the object information contained in the initialization instruction, and then generates a public-private key pair and a hardware wallet ID. After the public-private key pair is generated, the public-private key pair is stored in the hardware wallet 1530. Specifically, after receiving the object parameters and initialization instructions sent by the management terminal 1520, the hardware wallet can perform the initialization of the hardware wallet based on the received object parameters. The hardware wallet first stores the object information in a preset storage location, which can be stored in an encrypted storage manner for subsequent operations such as authority verification or loss and recovery. Then, the hardware wallet starts to generate a key pair, which includes a public key and a private key. Among them, in the embodiment of the present disclosure, the IC card in the hardware wallet can be pre-loaded with key generation software. After receiving the initialization instruction, the key generation software can be triggered based on the initialization instruction to generate a public-private key pair. In addition, the key generation software can also be used to generate the hardware wallet ID of the hardware wallet.

[0245] The hardware wallet 1530 may also send the public key information and the hardware wallet ID to the management terminal 1520 .

[0246] After the hardware wallet generates a key pair and a hardware wallet ID based on the received object information and initialization instructions, the public key information in the key pair and the hardware wallet ID can be sent to the management terminal 1520 through NFC connection or card insertion connection, so that the management terminal 1520 can send the public key information and the hardware wallet ID to the smart contract server 1540 for entry. That is, the hardware wallet is registered in the smart contract server 1540, so that the hardware wallet 1530 has the legal authority to authorize the smart contract in the smart contract server 1540.

[0247] After receiving the public key information and the hardware wallet ID returned by the hardware wallet, the management terminal 1520 can send the hardware wallet ID and the public key information to the smart contract server 1540. After receiving the hardware wallet ID and the public key information, the smart contract server 1540 stores the hardware wallet ID and the public key information. Then the smart contract server 1540 returns the storage result to the management terminal 1420.

[0248] After the hardware wallet ID and public key information are stored in the smart contract server 1540, when the object needs to execute a smart contract, the client 1510 of the smart contract application can be opened and then logged in. At this time, the client 1510 can send a login request to the smart contract server 1540. After receiving the login request, the smart contract server 1540 can log in after verification based on the identity information in the login request. Then, the smart contract server 1540 can send the contract list of the smart contract to the client 1510. The client 1510 receives the contract selection operation entered by the object in the smart contract list, and sends the target smart contract selected by the contract selection operation to the smart contract server 1540.

[0249] The smart contract server 1540 sends the contract details of the target smart contract to the client 1510 for display, and then the client 1510 can receive the contract execution operation input by the object, convert the contract execution operation into a contract execution instruction, and then send the contract execution instruction to the smart contract server 1540. Among them, the smart contract server 1540 can send the smart contracts stored therein to the client 1510 for display by category, for example, dividing the smart contracts into those that require execution authorization using a hardware wallet and those that do not require execution authorization using a hardware wallet. For smart contracts that do not require a hardware wallet for execution authorization, a verification information input interface can be displayed when an execution instruction is received. When the correct verification information is entered and verified, the corresponding smart contract can be executed. For smart contracts that require a hardware wallet for execution authorization, a hardware wallet signature authorization interface will be displayed after receiving the execution instruction. When an instruction to sense the hardware wallet is received in the hardware wallet signature authorization interface, the client 1510 begins to broadcast an authorization signature request, that is, the smart contract server 1540 sends an authorization signature request to the hardware wallet 1530 via the client 1510. After receiving the authorization signature request, the hardware wallet 1530 generates an authorization signature based on the timestamp, contract information, wallet information, and object information, and sends the authorization signature to the client 1510.

[0250] Then, the client 1510 sends the authorization signature to the smart contract server 1540 for signature verification. After receiving the authorization signature, the smart contract server 1540 can obtain the locally stored public key, and then use the public key to verify the authorization signature. When the authorization signature verification is passed, the smart contract server can send an instruction to execute the smart contract to the smart contract execution component 1550, thereby starting to execute the smart contract. In the process of executing the smart contract, the execution component 1550 can also feed back the execution status of the smart contract to the smart contract server 1540 in real time. The smart contract server 1540 can forward the execution status of the smart contract to the client 1510 in real time. The client 1510 can update the status data in each smart contract tag in the smart contract display list according to the execution status of the smart contract sent by the smart contract server 1540, so that the user object knows the execution status of each smart contract in real time.

[0251] The apparatus and device description of the present disclosure embodiments

[0252] It is to be understood that, although the steps in the above-mentioned flowcharts are sequentially displayed according to the characterization of arrows, these steps are not necessarily executed in sequence according to the order of arrow characterization. Unless there is a clear description in the present embodiment, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0253] It should be noted that in each specific embodiment of the present disclosure, when it comes to the need to perform relevant processing based on data related to the characteristics of the target object such as the target object attribute information or attribute information set, the permission or consent of the target object will be obtained first, and the collection, use and processing of these data will comply with the relevant laws, regulations and standards of the relevant region. In addition, when the embodiment of the present application needs to obtain the attribute information of the target object, the separate permission or separate consent of the target object will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the separate permission or separate consent of the target object, the necessary target object-related data used to enable the normal operation of the embodiment of the present application will be obtained.

[0254] Fig.16 This is a schematic diagram of the structure of the smart contract management authorization device 1700 provided in the embodiment of the present disclosure. The device includes:

[0255] The first display unit 1610 is used to display a list of smart contracts, receive a management trigger for a target smart contract in the list of smart contracts, and display a physical signature sensing interface corresponding to the target smart contract;

[0256] The second display unit 1620 is used to display a physical signature verification interface in response to sensing a trigger of a target physical device, wherein the target physical device stores identity information and preset private key information of a target object, and when the target physical device is triggered by the sensing, a physical signature generated by the identity information and the preset private key information is sent to the triggering object;

[0257] The third display unit 1630 is configured to display a first prompt label indicating that the physical signature verification has passed when a feedback signal indicating that the physical signature verification has passed is received;

[0258] The fourth display unit 1640 is used to display a second prompt label in response to a confirmation operation on the first prompt label, where the second prompt label is used to prompt that the management operation on the target smart contract has been authorized.

[0259] Optionally, in some embodiments, the fourth display unit includes:

[0260] A first display subunit is used to display an information collection area in a first prompt label, where the information collection area indicates the identity verification information to be collected and input;

[0261] The second display subunit is used to display a second prompt label in response to the trigger of the verification of the identity authentication information, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0262] Optionally, in some embodiments, the second display subunit includes:

[0263] A first display module, used to display a password input field in the information collection area;

[0264] The second display module is used to display a second prompt label in response to a trigger of passing the verification of the password received in the password input field.

[0265] Optionally, in some embodiments, the second display subunit includes:

[0266] A third display module, used to display facial recognition controls in the information collection area;

[0267] A fourth display module, configured to display a facial image acquisition interface in response to a triggering operation on the facial recognition control;

[0268] The fifth display module is used to display a second prompt label in response to a trigger that the collected facial image is verified to be successful.

[0269] Optionally, in some embodiments, the first display unit includes:

[0270] A third display subunit is used to display a smart contract display list in the smart contract management application, where the smart contract display list includes display tags corresponding to multiple smart contracts;

[0271] The fourth display subunit is used to display a physical signature sensing interface corresponding to the target smart contract in response to a triggering operation on a target display tag corresponding to the target smart contract.

[0272] Optionally, in some embodiments, the fourth display subunit includes:

[0273] A sixth display module, configured to display a first status sub-tag in the target display tag corresponding to the target smart contract, and display an execution control when the first status sub-tag indicates that the target smart contract is in a pending execution state;

[0274] A seventh display module, configured to display a physical signature sensing interface corresponding to a target smart contract in response to a trigger operation on an execution control;

[0275] The fourth display unit is further used for:

[0276] In response to a confirmation operation on the first prompt label, a second prompt label is displayed, and the second prompt label is used to prompt that the target smart contract has been authorized to execute.

[0277] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0278] The fifth display sub-unit is used to display a second display status sub-label in the target display label in response to a trigger operation of displaying the smart contract display interface, and the second display status sub-label indicates that the target smart contract is in an execution state.

[0279] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0280] a sixth display subunit, configured to display a stop control when the first status subtag indicates that the target smart contract is in an execution state;

[0281] a seventh display subunit, for displaying a physical signature sensing interface in response to a triggering operation on the abort control;

[0282] an eighth display subunit, configured to display a first prompt label in response to a trigger of passing the physical signature verification, wherein the first prompt label indicates that the physical signature verification has passed;

[0283] The ninth display subunit is used to display a second prompt label in response to a confirmation operation on the first prompt label, where the second prompt label is used to prompt that the target smart contract has been authorized to be terminated.

[0284] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0285] a tenth display subunit, configured to display a third prompt label indicating that the physical signature verification has failed, when receiving a feedback signal indicating that the physical signature verification has failed;

[0286] The eleventh display subunit is used to display a physical signature verification interface in response to a triggering operation on the third prompt tag.

[0287] Optionally, in some embodiments, the physical signature verification interface includes an authorization mode switching control, and the management authorization device of the smart contract provided by the present application also includes:

[0288] A twelfth display subunit is used to display a first permission verification interface in response to a trigger operation on the authorization mode switching control, where the first permission verification interface is used to verify the authorization mode switching permission;

[0289] A thirteenth display subunit is used to display a second permission verification interface in response to a trigger of passing the verification of the first verification information received in the first permission verification interface, where the second permission verification interface is used to verify the authorization management authority for the target smart contract;

[0290] The fourteenth display sub-unit is used to display a second prompt label in response to the trigger of passing the verification of the second verification information received in the second permission verification interface, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

[0291] Optionally, in some embodiments, the first display unit includes:

[0292] A first acquisition subunit, configured to receive a management trigger for a target smart contract and acquire contract information of the target smart contract;

[0293] An issuing subunit, used to issue broadcast information based on the contract information, the broadcast information is used to trigger the target physical device to generate a physical signature based on the contract information and broadcast the physical signature;

[0294] The fifteenth display subunit is used to display a physical signature sensing interface corresponding to the target smart contract.

[0295] Optionally, in some embodiments, the management authorization device for the smart contract provided by the present application further includes a generation unit, and the generation unit includes:

[0296] A first receiving subunit, used for receiving broadcast information and extracting contract information from the broadcast information;

[0297] A second acquisition subunit is used to acquire the object identity information of the object holding the target physical device, the private key information stored in the target physical device, and a timestamp;

[0298] The first generation subunit is used to generate a physical signature based on the contract information, the object identity information, the private key information and the timestamp.

[0299] Optionally, in some embodiments, the third display unit includes:

[0300] The sending subunit is used to send the physical signature to the smart contract server for signature verification;

[0301] The second receiving subunit is used to receive the signature verification result returned by the smart contract server, and when the signature verification result is passed, the first prompt label is displayed.

[0302] Optionally, in some embodiments, the management authorization device of the smart contract provided by the present application further includes:

[0303] A second receiving subunit is used to receive an initialization instruction, wherein the initialization instruction includes object identity information;

[0304] A second generating subunit is used to generate a key pair based on the object identity information, where the key pair includes public key information and corresponding private key information;

[0305] The broadcast subunit is used to generate a physical device label and broadcast public key information and the physical device label.

[0306] Optionally, in some embodiments, the first generating subunit includes:

[0307] Verification module, used to verify permissions based on contract information;

[0308] The generation module is used to generate a physical signature based on the contract information, object identity information, private key information and timestamp when the permission verification is passed.

[0309] Optionally, in some embodiments, the verification module includes:

[0310] The extraction submodule is used to extract the contract number from the contract information and obtain the preset contract number whitelist;

[0311] The determination submodule is used to determine whether the permission verification has passed when the contract number belongs to the contract number whitelist.

[0312] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0313] Reference Fig.17 , Fig.17 The structural block diagram of the terminal 140 for implementing the management authorization method of the smart contract of the embodiment of the present disclosure is as follows: the terminal 140 includes: a radio frequency (RF) circuit 1410, a memory 1715, an input unit 1730, a display unit 1740, a sensor 1750, an audio circuit 1760, a wireless fidelity (WiFi) module 1770, a processor 1780, and a power supply 1790. Those skilled in the art can understand that Fig.17 The structure of the terminal 140 shown does not constitute a limitation on a mobile phone or a computer, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0314] RF circuit 1710 may be used for receiving and sending signals during information transmission or calls. In particular, after receiving downlink information from a base station, it is sent to processor 1780 for processing. In addition, uplink data is sent to the base station.

[0315] The memory 1715 may be used to store software programs and modules. The processor 1780 executes various functional applications and document editing of the terminal by running the software programs and modules stored in the memory 1715 .

[0316] The input unit 1730 may be used to receive input digital or character information and generate key signal input related to the terminal's settings and function control. Specifically, the input unit 1730 may include a touch panel 1731 and other input devices 1732 .

[0317] The display unit 1740 may be used to display input information or provided information and various menus of the terminal. The display unit 1740 may include a display panel 1741 .

[0318] The audio circuit 1760 , the speaker 1761 , and the microphone 1762 may provide an audio interface.

[0319] In this embodiment, the processor 1780 included in the terminal 140 can execute the management authorization method of the smart contract in the previous embodiment.

[0320] The terminal 140 of the embodiment of the present disclosure includes but is not limited to a mobile phone, a computer, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, etc.

[0321] Fig.18 A block diagram of the structure of a portion of the server 110 for implementing the management authorization method of the smart contract of the embodiment of the present disclosure. The server 110 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 1822 (for example, one or more processors) and storage devices 1832, and one or more storage media 1830 (for example, one or more mass storage devices) storing application programs 1842 or data 1844. Among them, the storage device 1832 and the storage medium 1830 can be short-term storage or permanent storage. The program stored in the storage medium 1830 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the server 110. Furthermore, the central processing unit 1822 can be configured to communicate with the storage medium 1830 and execute a series of instruction operations in the storage medium 1830 on the server 110.

[0322] The server 110 may also include one or more power supplies 1826, one or more wired or wireless network interfaces 1850, one or more input and output interfaces 1858, and / or, one or more operating systems 1841, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0323] The central processor 1822 in the server 110 can be used to execute the management authorization method of the smart contract of the embodiment of the present disclosure.

[0324] The embodiments of the present disclosure also provide a storage medium, which is used to store program code, and the program code is used to execute the management authorization method of the smart contract of the aforementioned embodiments.

[0325] The embodiment of the present disclosure also provides a computer program product, which includes a computer program. The processor of the computer device reads and executes the computer program, so that the computer device executes the management authorization method for implementing the above-mentioned smart contract.

[0326] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0327] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0328] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0329] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0330] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0331] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0332] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0333] It should also be understood that the various implementations provided in the embodiments of the present disclosure can be combined arbitrarily to achieve different technical effects.

[0334] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A management authorization method for a smart contract, characterized in that: The method comprises: Display a list of smart contracts, receive a management trigger for a target smart contract in the list of smart contracts, and display a physical signature sensing interface corresponding to the target smart contract; In response to sensing the induction trigger of the target physical device, displaying a physical signature verification interface, the target physical device stores the identity information of the target object and the preset private key information, and when the target physical device is induction triggered, sends a physical signature generated by the identity information and the preset private key information to the triggering object; When receiving a feedback signal indicating that the physical signature verification has passed, displaying a first prompt label, wherein the first prompt label indicates that the physical signature verification has passed; In response to a confirmation operation on the first prompt label, a second prompt label is displayed, where the second prompt label is used to prompt that the management operation on the target smart contract has been authorized.

2. The method according to claim 1, characterized in that In response to the confirmation operation on the first prompt label, displaying a second prompt label, wherein the second prompt label is used to prompt that the management operation on the target smart contract has been authorized, including: Displaying an information collection area in the first prompt label, wherein the information collection area indicates the identity verification information to be collected and input; In response to the triggering of the verification of the identity authentication information being passed, a second prompt label is displayed, where the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

3. The method according to claim 2, characterized in that The displaying of the second prompt label in response to the triggering of the verification of the identity authentication information passing includes: Displaying a password input field in the information collection area; In response to a trigger that the password received in the password input field is successfully verified, a second prompt label is displayed.

4. The method according to claim 2, characterized in that: The displaying of the second prompt label in response to the triggering of the verification of the identity authentication information passing includes: displaying a facial recognition control in the information collection area; In response to a triggering operation on the facial recognition control, displaying a facial image acquisition interface; In response to a trigger that the collected facial image is verified to be successful, a second prompt label is displayed.

5. The method according to claim 1, characterized in that The displaying of the smart contract list, receiving a management trigger for a target smart contract in the smart contract list, and displaying a physical signature sensing interface corresponding to the target smart contract include: Displaying a smart contract display list in a smart contract management application, wherein the smart contract display list includes display tags corresponding to multiple smart contracts; In response to a triggering operation on a target display tag corresponding to a target smart contract, a physical signature sensing interface corresponding to the target smart contract is displayed.

6. The method according to claim 5, characterized in that The method of displaying a physical signature sensing interface corresponding to the target smart contract in response to a triggering operation on a target display tag corresponding to the target smart contract includes: Displaying a first display status sub-tag in the target display tag corresponding to the target smart contract, and displaying an execution control when the first status sub-tag indicates that the target smart contract is in a pending execution state; In response to a triggering operation on the execution control, displaying a physical signature sensing interface corresponding to the target smart contract; In response to the confirmation operation on the first prompt label, displaying a second prompt label, wherein the second prompt label is used to prompt that the management operation on the target smart contract has been authorized, including: In response to a confirmation operation on the first prompt label, a second prompt label is displayed, where the second prompt label is used to prompt that the execution of the target smart contract has been authorized.

7. The method according to claim 6, characterized in that In response to the confirmation operation on the first prompt label, a second prompt label is displayed, wherein the second prompt label is used to prompt that the execution of the target smart contract has been authorized, and the method further includes: In response to a triggering operation to display a smart contract display interface, a second display status sub-label is displayed in the target display label, and the second display status sub-label indicates that the target smart contract is in an execution state.

8. The method according to claim 6, characterized in that After displaying the first display status sub-tag in the target display tag corresponding to the target smart contract, the method further includes: When the first status sub-label indicates that the target smart contract is in an execution state, displaying an abort control; In response to a triggering operation on the abort control, displaying the physical signature sensing interface; In response to a trigger of passing the physical signature verification, displaying a first prompt label, wherein the first prompt label indicates that the physical signature verification has passed; In response to a confirmation operation on the first prompt label, a second prompt label is displayed, where the second prompt label is used to prompt that the termination of the target smart contract has been authorized.

9. The method according to claim 1, characterized in that: The method further comprises: When receiving a feedback signal indicating that the physical signature verification fails, displaying a third prompt label, wherein the third prompt label indicates that the physical signature verification fails; In response to a triggering operation on the third prompt tag, the physical signature verification interface is displayed.

10. The method according to claim 9, characterized in that The physical signature verification interface includes an authorization mode switching control, and the method further includes: In response to a triggering operation on the authorization mode switching control, displaying a first permission verification interface, wherein the first permission verification interface is used to verify the authorization mode switching permission; In response to a trigger that the verification of the first verification information received in the first permission verification interface is successful, a second permission verification interface is displayed, where the second permission verification interface is used to verify the authorization management authority for the target smart contract; In response to the triggering of successful verification of the second verification information received in the second permission verification interface, the second prompt label is displayed, and the second prompt label is used to prompt that the management operation of the target smart contract has been authorized.

11. The method according to claim 1, characterized in that: The receiving a management trigger for a target smart contract in the smart contract list and displaying a physical signature sensing interface corresponding to the target smart contract includes: Receive a management trigger for a target smart contract and obtain contract information of the target smart contract; Sending broadcast information based on the contract information, wherein the broadcast information is used to trigger the target physical device to generate a physical signature based on the contract information and broadcast the physical signature; Display a physical signature sensing interface corresponding to the target smart contract.

12. The method according to claim 11, characterized in that The specific process of the target physical device generating a physical signature based on the contract information includes the following steps: receiving the broadcast information, and extracting the contract information from the broadcast information; Acquire object identity information of an object holding the target physical device, private key information stored in the target physical device, and a timestamp; The physical signature is generated based on the contract information, the object identity information, the private key information, and the timestamp.

13. The method according to claim 12, characterized in that When receiving a feedback signal indicating that the physical signature has been verified, displaying a first prompt label includes: Sending the physical signature to the smart contract server for signature verification; Receive the signature verification result returned by the smart contract server, and when the signature verification result is passed, display the first prompt label.

14. The method according to claim 12, characterized in that Before receiving the broadcast information and extracting the contract information from the broadcast information, the method further includes: receiving an initialization instruction, wherein the initialization instruction includes the object identity information; Generate a key pair based on the object identity information, the key pair including public key information and corresponding private key information; A physical device tag is generated, and the public key information and the physical device tag are broadcasted.

15. The method according to claim 12, characterized in that The generating the physical signature based on the contract information, the object identity information, the private key information and the timestamp includes: Performing authority verification based on the contract information; When the authority verification passes, the physical signature is generated based on the contract information, the object identity information, the private key information and the timestamp.

16. The method according to claim 15, characterized in that The performing authority verification based on the contract information includes: Extracting the contract number from the contract information and obtaining a preset contract number whitelist; When the contract number belongs to the contract number whitelist, it is determined that the authority verification is passed.

17. A management authorization device for a smart contract, characterized in that: The device comprises: A first display unit, configured to display a list of smart contracts, receive a management trigger for a target smart contract, and display a physical signature sensing interface corresponding to the target smart contract; A second display unit is used to display a physical signature verification interface in response to sensing a trigger of a target physical device, wherein the target physical device stores identity information and preset private key information of a target object, and when the target physical device is sensed and triggered, a physical signature generated by the identity information and the preset private key information is sent to the triggering object; A third display unit is configured to display a first prompt label indicating that the physical signature verification has passed when a feedback signal indicating that the physical signature verification has passed is received; The fourth display unit is used to display a second prompt label in response to a confirmation operation on the first prompt label, wherein the second prompt label is used to prompt that the management operation on the target smart contract has been authorized.

18. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the management authorization method of the smart contract described in any one of claims 1 to 16 is implemented.

19. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the management authorization method of the smart contract described in any one of claims 1 to 16 is implemented.

20. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the management authorization method of a smart contract as described in any one of claims 1 to 16.

Images