Startup method, device, equipment and storage medium for decentralized applications

Abstract

An embodiment of the present application discloses a method, device, equipment, and storage medium for starting a decentralized application. The method includes: when detecting a start instruction triggered by a user terminal, obtaining the digital signature and application identifier of the start instruction carried by the start instruction; obtaining target application configuration data of the decentralized application from the local storage space according to the application identifier; determining a first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and executing the first smart contract to obtain a first data hash of the target application configuration data from the blockchain; determining a second data hash of the target application configuration data, and when the first data hash is consistent with the second data hash, generating a target application window of the decentralized application according to the target application configuration data; establishing a communication mechanism between the target application window and the blockchain to display the target application window. By adopting the embodiment of the present application, the decentralized application can be started quickly and safely, and has high applicability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a method, device, equipment, and storage medium for starting a decentralized application. Background Art

[0002] With the development of blockchain technology, many Dapps (Decentralized Applications) running on the blockchain network have emerged on the Internet. For example, game Dapps, shopping Dapps, and so on.

[0003] Although decentralized applications run on the blockchain network, for devices accessing decentralized applications, the application configuration data of decentralized applications is often stored in local storage, and when starting a decentralized application, it is started and accessed according to the application configuration data in local storage. However, for the application configuration data stored in local storage, it is easily tampered with, resulting in abnormal startup of decentralized applications and poor adaptability. Therefore, how to safely start a decentralized application has become an urgent problem to be solved. Summary of the Invention

[0004] Embodiments of this application provide a method, device, equipment, and storage medium for starting a decentralized application, which can quickly and safely start a decentralized application and has high applicability.

[0005] Embodiments of this application provide a method for starting a decentralized application, and the method includes:

[0006] When detecting a startup instruction triggered by a client, obtain the digital signature of the startup instruction carried by the startup instruction and the application identifier of the decentralized application to be started by the client;

[0007] Obtain the public key of the client, and when it is determined that the startup instruction is a valid instruction according to the public key and the digital signature, obtain the target application configuration data of the decentralized application from the local storage space according to the application identifier;

[0008] Determine the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and execute the first smart contract to obtain the first data hash of the target application configuration data from the blockchain;

[0009] Determine the second data hash of the target application configuration data, and match the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generate the target application window of the decentralized application according to the target application configuration data;

[0010] Establish a communication mechanism between the target application window and the blockchain according to the above-mentioned target application configuration data to display the target application window.

[0011] An embodiment of the present application provides a startup device for a decentralized application, and the device includes:

[0012] A first acquisition module, configured to, when detecting a startup instruction triggered by a client, acquire the digital signature of the startup instruction carried by the startup instruction and the application identifier of the decentralized application to be started by the client;

[0013] A second acquisition module, configured to acquire the public key of the client, and when determining that the startup instruction is a valid instruction according to the public key and the digital signature, acquire the target application configuration data of the decentralized application from the local storage space according to the application identifier;

[0014] A third acquisition module, configured to determine a first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and execute the first smart contract to acquire a first data hash of the target application configuration data from the blockchain;

[0015] A first processing module, configured to determine a second data hash of the target application configuration data, and match the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generate a target application window of the decentralized application according to the target application configuration data;

[0016] A second processing module, configured to establish a communication mechanism between the target application window and the blockchain according to the target application configuration data to display the target application window.

[0017] In a possible implementation manner, the second acquisition module includes:

[0018] A first acquisition unit, configured to acquire first application configuration data marked with the application identifier from the local storage space;

[0019] A first determination unit, configured to determine first version information corresponding to the first application configuration data, and send the first version information to a consensus node in the blockchain, so that the consensus node verifies whether the first version information is lower than the preset version information of the decentralized application in the blockchain;

[0020] A second determination unit, configured to, if the first version information is not lower than the preset version information, determine the first application configuration data as the target application configuration data, and acquire the target application configuration data from the local storage space.

[0021] In a possible implementation manner, the above-mentioned second acquisition module further includes:

[0022] A first sending unit, further configured to, if the above-mentioned first version information is lower than the above-mentioned preset version information, send a data acquisition request to the above-mentioned blockchain to determine the second smart contract corresponding to the above-mentioned target application configuration data from the above-mentioned blockchain;

[0023] A second acquisition unit, further configured to execute the above-mentioned second smart contract to acquire the first application update data of the above-mentioned decentralized application from the above-mentioned blockchain, and update the above-mentioned first application configuration data according to the above-mentioned first application update data to obtain the above-mentioned target application configuration data.

[0024] In a possible implementation manner, the above-mentioned first processing module includes:

[0025] A third determination unit, configured to determine whether there is a first application process in the above-mentioned decentralized application;

[0026] A first generation unit, configured to, when there is the above-mentioned first application process in the above-mentioned decentralized application, generate a target application window according to the above-mentioned first application process and the above-mentioned target application configuration data;

[0027] A second sending unit, configured to, when there is no above-mentioned first application process in the above-mentioned decentralized application, send a start request to the above-mentioned blockchain consensus node to enable the consensus node to verify whether the start request is a valid request;

[0028] A second generation unit, configured to, when the above-mentioned start request is a valid request, create a second application process for the above-mentioned decentralized application, and generate the above-mentioned target application window according to the above-mentioned second application process and the above-mentioned target application configuration data.

[0029] In a possible implementation manner, the above-mentioned device further includes:

[0030] A fourth acquisition module, further configured to acquire the user data generated by the above-mentioned client when accessing the above-mentioned decentralized application, and determine the time of each application window for the above-mentioned client to access the above-mentioned decentralized application according to the above-mentioned user data;

[0031] A determination module, further configured to determine the application window with the longest access time as the default application window, and determine the third data hash of the above-mentioned second application configuration data corresponding to the above-mentioned default application window;

[0032] A first storage module, further configured to store the above-mentioned second application configuration data in the above-mentioned local storage space, and store the above-mentioned third data hash in the above-mentioned blockchain, so as to display the above-mentioned default application window to the above-mentioned user according to the above-mentioned second application configuration data and the above-mentioned third data hash when the above-mentioned client starts the above-mentioned decentralized application again.

[0033] In a possible implementation, the above device further includes:

[0034] A sending module, further configured to, when detecting an application update request triggered by the above user terminal, send the application update request to an application update node of the above blockchain, so that the application update node determines whether the user terminal has the update permission for the above decentralized application according to the user node information and the above application identifier carried in the application update request;

[0035] An update module, further configured to, when the above user terminal has the above update permission, determine second application update data, and update the above target application configuration data according to the second application update data to obtain updated target application configuration data;

[0036] A second storage module, further configured to determine a fourth data hash of the above updated target application configuration data, and store the fourth data hash in the above blockchain so that the application update node sends a transferred data volume to the above user terminal.

[0037] In a possible implementation, the above device further includes:

[0038] A third storage module, further configured to store the above updated target application configuration data in the above local storage space;

[0039] A fourth storage module, further configured to update the above first smart contract according to the second application update data to obtain a third smart contract, and store the third smart contract in the above blockchain, so that when it is detected again that the above user terminal starts the above decentralized application, the third smart contract is determined from the above blockchain and the fourth data hash is obtained according to the third smart contract.

[0040] An embodiment of the present application provides a device, which includes a processor and a memory, and the processor and the memory are connected to each other. The memory is used to store a computer program that supports the terminal device to execute the method for starting a decentralized application provided by the embodiment of the present application. The computer program includes program instructions, and the processor is configured to call the above program instructions to execute the method for starting a decentralized application provided by the embodiment of the present application.

[0041] An embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method for starting a decentralized application provided by the embodiment of the present application.

[0042] In the embodiments of the present application, when a start instruction triggered by a client is detected, the validity of the start instruction can be verified based on the public key and digital signature of the client, thereby avoiding the mis-start of the decentralized application to a certain extent. Secondly, the data hash of the target application configuration data can be obtained from the blockchain, and the integrity of the target application configuration data stored in the local storage space can be verified based on the data hash, thereby realizing the verification of the local application configuration data before starting the decentralized application, improving the security of the decentralized application, and having high applicability. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0044] Figure 1 FIG. is a schematic diagram of the scenario of the method for starting a decentralized application provided by an embodiment of the present application;

[0045] Figure 2 FIG. is a schematic flowchart of the method for starting a decentralized application provided by an embodiment of the present application;

[0046] Figure 3 FIG. is a schematic diagram of the scenario for determining the digital signature of the start instruction provided by an embodiment of the present application;

[0047] Figure 4 FIG. is a schematic diagram of the scenario for verifying the start instruction provided by an embodiment of the present application;

[0048] Figure 5 FIG. is a schematic diagram of the principle for determining the target application configuration data provided by an embodiment of the present application;

[0049] Figure 6 FIG. is another schematic flowchart of the method for starting a decentralized application provided by an embodiment of the present application;

[0050] Figure 7 FIG. is yet another schematic flowchart of the method for starting a decentralized application provided by an embodiment of the present application;

[0051] Figure 8 FIG. is a schematic structural diagram of the starting device of the decentralized application provided by an embodiment of the present application;

[0052] Figure 9 FIG. is a schematic structural diagram of the device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0053] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0054] Please refer to Figure 1 , Figure 1 which is a schematic diagram of the scenario of the method for starting a decentralized application provided by an embodiment of the present application. In Figure 1 , nodes 10a, 10b, 10c, and 10d are some nodes in blockchain 10, and nodes 10a, 10b, and 10c can be any device that accesses blockchain 10 and can access the decentralized application, including but not limited to laptop computers, mobile terminals, servers, and wearable portable devices, etc., which can be specifically determined according to the actual application scenario and are not limited herein. In addition, nodes 10a, 10b, 10c, and 10d can also be consensus nodes in blockchain 10 or nodes with other functions, which can also be specifically determined according to the actual application scenario and are not limited herein. In Figure 1 , node 10a is a user node that can run (start) the decentralized application. When node 10a detects the start instruction 30 triggered by the user terminal 20, node 10a can obtain the digital signature 301 of the start instruction carried by the start instruction 30 and the application identifier 302 of the decentralized application to be started by the user terminal 20. At this time, node 10a can obtain the public key of the user terminal 20 and, when determining that the start instruction 30 is a valid instruction according to the public key of the user terminal 20 and the digital signature, obtain the target application configuration data of the decentralized application from the local storage of node 10a according to the application identifier 302. On the other hand, node 10a can determine the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier 302, and execute the first smart contract to obtain the first data hash of the target application configuration data from the blockchain. Further, node 10a can determine the second data hash of the target application configuration data, and match the first data hash and the second data hash. When the first data hash is consistent with the second data hash, node 10a can generate the target application window 40 of the decentralized application according to the target application configuration data. Further, node 10a can also establish a communication mechanism between the above-mentioned target application window 40 and the blockchain according to the target application configuration data to display the target application window 40 to the user terminal, realizing the start of the decentralized application.

[0055] Refer to Figure 2 , Figure 2 which is a flowchart of the method for starting a decentralized application provided by an embodiment of the present application. Figure 2The method for starting a decentralized application shown includes the following steps S201 to S205.

[0056] S201. When a start instruction triggered by the user side is detected, obtain the digital signature of the start instruction carried by the start instruction and the application identifier of the decentralized application to be started by the user side.

[0057] In some feasible implementation manners, the user side can start the decentralized application through the user node. Among them, the user node can be any device that accesses the blockchain and can access the decentralized application, including but not limited to laptop computers, mobile terminals, servers, wearable portable devices, etc., which can be specifically determined according to the actual application scenario and are not limited here. Among them, the user side can trigger the start instruction of the decentralized application through touch instructions, voice instructions, gesture instructions, etc. The specific triggering method and the specific manifestation form of the start instruction can be determined according to the actual application scenario and are not limited here.

[0058] Optionally, when the client triggers the start instruction of the decentralized application, the start instruction needs to carry the digital signature of the start instruction and the application identifier of the decentralized application to be started by the client. Among them, the digital signature of the start instruction is used to enable the user node to verify whether the start instruction triggered by the client is a valid instruction to avoid unsuccessful startup of the decentralized application. The application identifier is used to mark the decentralized application to inform the user node to start the decentralized application corresponding to the application identifier and avoid incorrect startup. Among them, after the client triggers the start instruction, the client can perform a hash calculation on the start instruction to obtain the digest corresponding to the start instruction, and further sign the digest corresponding to the start instruction with the private key of the client to obtain the digital signature of the start instruction. Among them, when performing the hash calculation on the start instruction, the message digest algorithm can be used. The message digest algorithms include, but are not limited to, Cyclic Redundancy Check-8 (CRC8), Cyclic Redundancy Check-16 (CRC16), Cyclic Redundancy Check-32 (CRC32), Message-Digest Algorithm 2 (MD2), Message-Digest Algorithm 4 (MD4), Message-Digest Algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA1), Secure Hash Algorithm 256 (SHA256), Secure Hash Algorithm 384 (SHA384), Secure Hash Algorithm 512 (SHA512), RACE Integrity Primitives Evaluation Message Digest (RIPEMD), PANAMA, TIGER, and Adler-3 algorithm, etc. Specifically, it can be determined based on the actual application scenario and is not limited here. Among them, the lengths and forms of the digests obtained by different message digest algorithms are different. For example, based on CRC32, a digest represented by an 8-bit hexadecimal number can be obtained, based on MD5, a digest represented by a 32-bit hexadecimal number can be obtained, and based on SHA256, a digest with a length of 32 bytes (256 bits) can be obtained. See Figure 3 , Figure 3It is a schematic diagram of the scenario for determining the digital signature of the start instruction provided by an embodiment of the present application. As Figure 3 shown, assume that after performing a hash calculation on the start instruction, the digest of the start instruction is 1000100. After further signing the digest 1000100 with the private key of the user terminal, 0010101 is obtained. At this time, 0010101 is the digital signature of the start instruction.

[0059] S202. Obtain the public key of the user terminal, and when it is determined that the start instruction is a valid instruction according to the public key and the digital signature, obtain the target application configuration data of the decentralized application from the local storage space according to the application identifier.

[0060] In some feasible embodiments, since the start instruction may be lost or tampered with during the process of the user node detecting the start instruction, after the user node obtains the digital signature and the application identifier carried by the start instruction, the user node can obtain the public key of the user terminal to determine whether the detected start instruction is a valid instruction according to the public key of the user terminal and the digital signature. Among them, the user node can send a acquisition request carrying the user identifier of the user terminal to the data management node in the blockchain, so that the data management node determines the public key of the user terminal from the blockchain according to the user identifier and sends the public key of the user terminal to the user node. Optionally, the user node determines the user identifier of the user terminal and executes the smart contract corresponding to the user identifier to directly obtain the public key of the user terminal from the blockchain. Optionally, the user node can send a request to the user terminal to obtain the private key of the user terminal from the user terminal. It should be particularly noted that the above acquisition of the public key of the user terminal is only an example, and can be specifically determined according to the actual application scenario, and is not limited here. Specifically, the user node can decrypt the digital signature according to the public key of the user terminal to obtain the first digest of the start instruction. On the other hand, the user node can perform a hash calculation on the detected start instruction to obtain the second digest of the start instruction. The user node can thus compare the first digest and the second digest. If the first digest and the second digest are consistent, it means that the start instruction triggered by the user has not lost data and has not been tampered with. Therefore, the user node can determine that the detected start instruction is a valid instruction. See Figure 4 , Figure 4 It is a schematic diagram of the scenario for verifying the start instruction provided by an embodiment of the present application. In Figure 4 it, assume that the digital signature carried by the start instruction obtained by the user node is 0010101, and the first digest obtained by the user node after decrypting the digital signature according to the public key of the user terminal is 1000100. At this time, if the second digest information obtained by the user node after performing a hash calculation on the start instruction is also 1000100, the user node can determine that the start instruction triggered by the user terminal is a valid instruction.

[0061] In some feasible embodiments, when the startup instruction triggered by the client is a valid instruction, the user node can obtain the target application configuration data of the decentralized application from the local storage space according to the application identifier carried in the startup instruction. Among them, the above decentralized application is the application marked by the above application identifier, and the above local storage space can be the device memory, hard disk, mobile hard disk corresponding to the user node, or the cloud storage space connected to the user node, etc., which can be specifically determined according to the actual application scenario and is not limited here. Specifically, the user node can first obtain the first application configuration data marked by the above application identifier from the local storage space. The above first application configuration data is the configuration data that can start the decentralized application, such as all application configuration data generated after installing the installation package of the decentralized application, including but not limited to UI data, executable file data, etc., which can be specifically determined according to the actual application scenario and is not limited here. Further, the user node can obtain the first version information corresponding to the first application configuration data, that is, the application version information of the decentralized application obtained through the first application configuration data, and send the first version information to the consensus node in the blockchain so that the consensus node can verify whether the first version information is lower than the preset version information of the decentralized application running on the blockchain. The above preset version information is the latest version information of the decentralized application at the current time. If the consensus node determines that the first version information is not lower than the preset version information, it means that the decentralized application obtained according to the first application configuration data is the latest version of the decentralized application. At this time, the user node can obtain the first application configuration data (which is the target application configuration data at this time) from the local storage space. Among them, for each consensus node in the blockchain, each consensus node can respectively determine whether the first version information is lower than the preset version information of the decentralized application. When more than half of the consensus nodes in the blockchain think that the first version information is not lower than the preset version information of the decentralized application, it can be shown that after verification by the consensus nodes in the blockchain, the first version information is not lower than the preset version information of the decentralized application. Otherwise, it means that after the user node sends the first version information to the consensus node, the consensus node determines that the first version information is lower than the preset version information, which will not be elaborated here.

[0062] In some feasible embodiments, when the consensus node of the blockchain determines that the first version information of the first application configuration data is lower than the preset version information of the decentralized application, the user node can obtain the target application configuration data according to the first application update data of the decentralized application. For details, please refer to Figure 5 , Figure 5 which is a schematic diagram of the principle for determining the target application configuration data provided by the embodiments of the present application. As Figure 5As shown, the user node can send a data acquisition request to the blockchain to determine the second smart contract corresponding to the target application data from the blockchain, so as to obtain the first application update data of the decentralized application from the blockchain by executing the second smart contract. Further, the user node can update the first application configuration data according to the first application update data to obtain the updated application configuration data. At this time, the version information corresponding to the updated application configuration data is not lower than the preset version information of the decentralized application. Furthermore, the user node can determine the updated application configuration data as the target application configuration data.

[0063] S203. Determine the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and execute the first smart contract to obtain the first data hash of the target application configuration data from the blockchain.

[0064] In some feasible implementation manners, since the target application configuration data obtained by the user node may have problems such as data loss and human tampering during storage, resulting in the user node being unable to start the decentralized application according to the target application configuration data, after the user node obtains the target application configuration data according to the application identifier, it is necessary to obtain the first data hash of the target application configuration data from the blockchain to verify the target application configuration data. Among them, when the user node obtains the first data hash from the blockchain, it can determine the first smart contract corresponding to the target application configuration data from the blockchain, and then execute the first smart contract to determine the target block corresponding to the application identifier from the blockchain, and obtain the first data hash of the target application configuration data from the target block. Or, the user node can execute the first smart contract to obtain the first data hash of the target application configuration data from the contract code of the first smart contract. The specific acquisition method can be determined according to the actual application scenario and will not be limited here.

[0065] S204. Determine the second data hash of the target application configuration data, and match the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generate the target application window of the decentralized application according to the target application configuration data.

[0066] In some feasible embodiments, after the user node obtains the target application configuration data and the first data hash of the target application configuration data, the user node can determine the second data hash of the target application configuration data and compare the first data hash with the second data hash. If the first data hash and the second data hash of the target application configuration data are consistent, it indicates that there are no phenomena such as data loss or data tampering in the target application configuration data stored in the local storage space. At this time, the user node can generate a target application window for the decentralized application according to the target application configuration data. Among them, the user node completes the startup of the decentralized application by generating the target window of the decentralized application. The target application window of the decentralized application can be the default home page, user settings page, etc. of the decentralized application, which can be specifically determined according to the actual application scenario and is not limited here.

[0067] In some feasible embodiments, since the application background of the decentralized application may be running the application process of the decentralized application, that is, the decentralized application is not actually closed. Therefore, when starting the decentralized application, it is necessary to first determine whether there is a relevant application process for the decentralized application (for convenience of description, hereinafter referred to as the first application process). Then, the user node can determine whether to use the hot start or cold start method to generate the target application window based on whether there is a first application process for the decentralized application. When there is a first application process for the decentralized application, it means that the decentralized application has not been completely closed by the user node (for example, pressing the back key or home key, although the decentralized application will exit, the process of the decentralized application will still remain in the background and can be viewed by entering the task list). At this time, the user node can use the hot start method to create and initialize the MainActivity according to the target application configuration data and further execute the MainActivity to obtain the target application window. Among them, executing the MainActivity can implement the layout, size measurement, drawing, etc. of the target application window, and improve the functions of the target application window, etc., which can be specifically determined according to the actual application scenario and are not limited here. When there is no first application process for the decentralized application, it means that the decentralized application has been completely closed. The user node will send a start request to the blockchain consensus node. When the consensus node determines that the start request is a valid request, the user node will create a second application process for the decentralized application and then generate the target application window according to the second application process. Among them, when verifying the start request sent by the user node, the consensus node can verify whether the request parameters of the start request meet the preset parameter requirements of the decentralized application. If more than half of the consensus nodes in the blockchain think that the request parameters of the start request meet the preset parameter requirements of the decentralized application, it can be determined that the start request sent by the user node is a valid request. Optionally, when the start request sent by the user node carries a digital signature of the start request, each consensus node can also obtain the public key of the user node and verify whether the digital signature and the start request match according to the public key. If they match, it can be determined that the start request is a valid request.

[0068] S205. Establish a communication mechanism between the target application window and the blockchain according to the target application configuration data to display the target application window.

[0069] In some feasible embodiments, since the decentralized application runs on the blockchain, when the user node generates the target application window based on the target application configuration data, or after that, the user node needs to establish a communication mechanism between the target application window and the blockchain so that the target application window can run properly, and then display the target application window to the user side. Specifically, after generating the target application window, the user node can determine the communication protocol supported by the decentralized application according to the target application configuration data, and on the other hand, determine the communication protocol satisfied by the blockchain. Further, the user node can establish a communication mechanism between the target application window and the blockchain according to the common communication protocol in the communication protocol supported by the decentralized application and the communication protocol satisfied by the blockchain, so that the user side can communicate with the blockchain through the target application window generated by the user node.

[0070] Optionally, in some feasible embodiments, when the user node starts the decentralized application in a cold start manner, it can be implemented through an inter-process communication mechanism. For example, the desktop launcher of the user node can use the Binder inter-process communication mechanism to notify the ActivityManagerService (a system process provided by Android for managing the running state of Activities) that the user node needs to start an Activity at this time. At this time, the ActivityManagerService can use the Binder inter-process communication mechanism to notify the desktop launcher to enter the paused state. The desktop launcher uses the Binder inter-process communication mechanism to notify the ActivityManagerService that it is ready to enter the Paused state. Then the ActivityManagerService uses Zygote.fork() to create a new process to start an instance of the ActivityThread, and the Activity to be started will run in this ActivityThread instance. The ActivityThread passes a Binder object of the ApplicationThread type to the ActivityManagerService through the Binder inter-process communication mechanism, so that the ActivityManagerService can communicate with it through this Binder object in the future. The ActivityManagerService notifies the ActivityThread through the Binder inter-process communication mechanism to execute the start operation of the Activity, and then generates the target application window.

[0071] See Figure 6 , Figure 6 is another flowchart of the method for starting a decentralized application provided by the embodiments of the present application. Figure 6The method for starting a decentralized application shown may include the following steps S601 to S608.

[0072] S601. When a start instruction triggered by a client is detected, obtain the digital signature of the start instruction carried by the start instruction and the application identifier of the decentralized application to be started by the client.

[0073] S602. Obtain the public key of the client, and when it is determined that the start instruction is a valid instruction according to the public key and the digital signature, obtain the target application configuration data of the decentralized application from the local storage space according to the application identifier.

[0074] S603. Determine the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and execute the first smart contract to obtain the first data hash of the target application configuration data from the blockchain.

[0075] S604. Determine the second data hash of the target application configuration data, and match the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generate the target application window of the decentralized application according to the target application configuration data.

[0076] S605. Establish a communication mechanism between the target application window and the blockchain according to the target application configuration data to display the target application window.

[0077] In some feasible implementation manners, the specific implementation manners of the above steps S601 to S605 may refer to Figure 2 the implementation manners shown in steps S201 to S205 in

[0078] S606. Obtain the user data generated when the user accesses the decentralized application, and determine the time of each application window accessed by the client to the decentralized application according to the user data.

[0079] In some feasible embodiments, after the user node displays the target application window to the user d - end, the user node can obtain the user data generated by the user - end when accessing the decentralized application. Specifically, the user node can obtain the user data of each application window of each decentralized application, and determine the log data of the window from the user data of each window. Further, the log generation time can be determined from the log data of each application window, and the time interval from the earliest log generation time to the latest log generation time is determined as the time when the user - end accesses the application window. Optionally, the user node can determine the window identifier of each application window according to the user data of each application window when the user accesses the decentralized application, and send the window identifier of each application window and the user information of the user - end to the application management node of the blockchain, so that the application management node of the blockchain can determine the time when the user - end accesses each application window, and send the time when the user - end accesses each application window to the user node.

[0080] S607. Determine the application window with the longest access time as the default application window, and determine the third data hash of the second application configuration data corresponding to the default application window.

[0081] In some feasible embodiments, when the user - end accesses a certain application window for a long time, it indicates that the user - end is interested in the application window or the application window is an application window frequently accessed by the user - end. Therefore, the user node can determine the application window with the longest access time by the user - end as the default application window of the user - end in the decentralized application, and determine the third data hash of the second application configuration data corresponding to the default application window. At this time, the user node can, according to the above - mentioned second application configuration data and the above - mentioned third data hash, display the above - mentioned default application window to the user - end when the user - end starts the decentralized application again. Optionally, the user node can also determine the stop time when the user - end stops accessing each application window according to the user data generated by the user - end when accessing the decentralized application, and determine the application window corresponding to the stop time closest to the current moment as the default application window. That is, the user node can determine the application window of the decentralized application that the user - end accessed last time as the default window, so that when the user - end starts the decentralized application again and according to the second application configuration data of the default window, the application window that the user - end accessed last time is displayed to the user - end.

[0082] S608. Store the second application configuration data in the local storage space, and store the third data hash in the blockchain, so that when the user - end starts the decentralized application again, the user node can display the default application window according to the second application configuration data and the third data hash.

[0083] In some feasible embodiments, in order to display the default application window to the user when the user node restarts the decentralized application at the user side, the user node may store the second application configuration data of the default application window in the local storage space of the user node, and at the same time, store the third data hash of the second application configuration data in the blockchain. Thus, when the user side restarts the decentralized application again, the user node can obtain the above-mentioned third data hash from the blockchain and verify the second application configuration data in the local storage space according to the third data hash. When the third data hash is consistent with the data hash of the second application configuration data, the user node can generate a default application window according to the second application configuration data to complete the startup of the decentralized application.

[0084] See Figure 7 , Figure 7 is another flowchart of the method for starting a decentralized application provided by an embodiment of the present application. Figure 7 The method for starting the decentralized application shown includes the following steps S701 to S708.

[0085] S701. When a startup instruction triggered by the user side is detected, obtain the digital signature of the startup instruction carried by the startup instruction and the application identifier of the decentralized application to be started by the user side.

[0086] S702. Obtain the public key of the user, and when it is determined that the startup instruction is a valid instruction according to the public key and the digital signature, obtain the target application configuration data of the decentralized application from the local storage space according to the application identifier.

[0087] S703. Determine the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and execute the first smart contract to obtain the first data hash of the target application configuration data from the blockchain.

[0088] S704. Determine the second data hash of the target application configuration data, and match the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generate a target application window of the decentralized application according to the target application configuration data.

[0089] S705. Establish a communication mechanism between the target application window and the blockchain according to the target application configuration data to display the target application window.

[0090] In some feasible embodiments, the specific implementation manners of the above steps S701 to S705 may refer to Figure 2 the implementation manners shown in steps S201 to S205 in

[0091] S706. When an application update request triggered by a client is detected, send the application update request to the application update node of the blockchain, so that the application update node can determine whether the client has the update permission for the decentralized application according to the user information and application identifier carried in the application update request.

[0092] In some feasible implementation manners, the client can also update the decentralized application through the user node. Therefore, when an application update request triggered by the client is detected, the user node can send the above application update request to the application update node in the blockchain to update the decentralized application. Specifically, after the user node sends the application update request, the application update node can determine whether the client has the update permission for the decentralized application according to the user information and application identifier carried in the update request. Among them, the application update node can determine the update permission list of the decentralized application marked by the application identifier, and when the client corresponding to the user information exists in the update permission list, it can be determined that the client has the update permission for the decentralized application. Optionally, the application update node can send the application identifier and the user information to the consensus node of the blockchain so that the consensus node can verify whether the client has the update permission for the decentralized application marked by the application identifier. When the consensus node verifies that the client has the update permission for the decentralized application, the application update node can determine that the client has the update permission for the decentralized application. Among them, the consensus node can verify whether the client has the update permission by calling the above application update node, or can also verify according to the user behavior data of the client obtained from the blockchain and the historical user behavior of the client. It should be particularly noted that the specific implementation manner of determining that the client has the update permission for the decentralized application can be determined according to the actual application scenario and is not limited here.

[0093] S707. When the client has the update permission, determine the second application update data, and update the target application configuration data according to the second application update data to obtain the updated target application configuration data.

[0094] In some feasible implementation manners, the user node can obtain the second application update data configured by the user in the target application window, or the user node can obtain the second application update data from the blockchain according to the application update instruction triggered by the client. The specific implementation manner can be determined according to the actual application scenario and is not limited here. On the other hand, the user node can update the target application configuration data in the local storage space according to the second application update data to obtain the updated target application configuration data. Among them, when updating the target application configuration data, the UI data, function data, etc. can be updated, and the specific can be determined according to the actual application scenario and is not limited here. Optionally, the specified part of the data in the target application configuration data can also be replaced to obtain the updated target application configuration data.

[0095] S708. Determine the fourth data hash of the updated target application configuration data, and store the fourth data hash in the blockchain so that the update node sends the transferred data volume to the user terminal.

[0096] In some feasible implementation manners, after the user node updates the target application configuration data to obtain the updated target application configuration data, the user node can determine the fourth data hash of the updated target application configuration data. Further, the user node can store the fourth data hash in the blockchain. Thus, the application update node can determine the data volume receiving address of the user node according to the user node information, and send the transferred data volume to the data volume receiving address of the user terminal. That is, after the decentralized application is updated by the user node for the target application data, a certain amount of transferred data volume can be sent to the user node as a reward.

[0097] Optionally, in some feasible implementation manners, the user node can also store the updated target application configuration data in the local storage space. Further, since the user node needs to execute the first smart contract when obtaining the first data hash of the target application configuration data from the blockchain, when the user node obtains the fourth data hash of the updated target application configuration data from the blockchain, the corresponding smart contract also needs to be executed to obtain the fourth data hash. For the above reasons, the user node can update the first smart contract according to the second application update data to obtain the third smart contract. Thus, when it is detected again that the user terminal starts the decentralized application, the user node can obtain the fourth data hash from the blockchain according to the third smart contract to verify the updated target application configuration data stored in the local storage space, and start the decentralized application according to the updated application configuration data after the verification passes.

[0098] In the embodiment of the present application, when a start instruction triggered by the user terminal is detected, the validity of the start instruction can be verified according to the public key and digital signature of the user terminal, so as to avoid the mis-start of the decentralized application to a certain extent. Secondly, the data hash of the target application configuration data can be obtained from the blockchain, and the integrity of the target application configuration data stored in the local storage space can be verified according to the data hash, so as to realize the verification of the local application configuration data before starting the decentralized application, improve the security of the decentralized application, and have high applicability.

[0099] See Figure 8 , Figure 8 is a schematic structural diagram of a start device of a decentralized application provided by an embodiment of the present application. The device 1 provided by the embodiment of the present application includes:

[0100] A first acquisition module 11, configured to, when detecting a start instruction triggered by a user terminal, acquire the digital signature of the start instruction carried by the start instruction and the application identifier of the decentralized application to be started by the user terminal;

[0101] A second acquisition module 12, configured to acquire the public key of the above user terminal, and when it is determined that the above start instruction is a valid instruction according to the above public key and the above digital signature, acquire the target application configuration data of the above decentralized application from the local storage space according to the above application identifier;

[0102] A third acquisition module 13, configured to determine a first smart contract corresponding to the above target application configuration data from the blockchain according to the above application identifier, and execute the above first smart contract to acquire a first data hash of the above target application configuration data from the blockchain;

[0103] A first processing module 14, configured to determine a second data hash of the above target application configuration data, and match the above first data hash with the above second data hash. When the above first data hash is consistent with the above second data hash, generate a target application window of the above decentralized application according to the above target application configuration data;

[0104] A second processing module 15, configured to establish a communication mechanism between the above target application window and the above blockchain according to the above target application configuration data to display the above target application window.

[0105] In some feasible implementation manners, the above second acquisition module 12 includes:

[0106] A first acquisition unit 121, configured to acquire first application configuration data marked with the above application identifier from the local storage space;

[0107] A first determination unit 122, configured to determine a first version information corresponding to the above first application configuration data, and send the above first version information to a consensus node in the blockchain, so that the above consensus node verifies whether the above first version information is lower than a preset version information of the above decentralized application in the blockchain;

[0108] A second determination unit 123, configured to, if the above first version information is not lower than the above preset version information, determine the above first application configuration data as the target application configuration data, and acquire the above target application configuration data from the above local storage space.

[0109] In some feasible implementation manners, the above second acquisition module 12 further includes:

[0110] A first sending unit 124, further configured to, if the above first version information is lower than the above preset version information, send a data acquisition request to the above blockchain to determine a second smart contract corresponding to the above target application configuration data from the above blockchain;

[0111] The second acquisition unit 125 is further configured to execute the above-mentioned second smart contract to obtain the first application update data of the decentralized application from the above-mentioned blockchain, and update the above-mentioned first application configuration data according to the above-mentioned first application update data to obtain the above-mentioned target application configuration data.

[0112] In some possible implementation manners, the above-mentioned first processing module 14 includes:

[0113] A third determination unit 141, configured to determine whether there is a first application process for the above-mentioned decentralized application;

[0114] A first generation unit 142, configured to generate a target application window according to the above-mentioned first application process and the above-mentioned target application configuration data when there is the above-mentioned first application process for the above-mentioned decentralized application;

[0115] A second sending unit 143, configured to send a start request to the above-mentioned blockchain consensus node when there is no above-mentioned first application process for the above-mentioned decentralized application, so that the consensus node verifies whether the start request is a valid request;

[0116] A second generation unit 144, configured to create a second application process for the above-mentioned decentralized application when the above-mentioned start request is a valid request, and generate the above-mentioned target application window according to the above-mentioned second application process and the above-mentioned target application configuration data.

[0117] In some possible implementation manners, the above-mentioned device 1 further includes:

[0118] A fourth acquisition module 16 is further configured to acquire the user data generated by the above-mentioned client when accessing the above-mentioned decentralized application, and determine the time of each application window for the above-mentioned client to access the above-mentioned decentralized application according to the above-mentioned user data;

[0119] A determination module 17 is further configured to determine the application window with the longest access time as the default application window, and determine the third data hash of the above-mentioned second application configuration data corresponding to the above-mentioned default application window;

[0120] A first storage module 18 is further configured to store the above-mentioned second application configuration data in the above-mentioned local storage space, and store the above-mentioned third data hash in the above-mentioned blockchain, so as to display the above-mentioned default application window according to the above-mentioned second application configuration data and the above-mentioned third data hash when the above-mentioned client starts the above-mentioned decentralized application again.

[0121] In some possible implementation manners, the above-mentioned device 1 further includes:

[0122] The sending module 19 is further configured to, when detecting the application update request triggered by the client, send the application update request to the application update node of the blockchain, so that the application update node determines whether the client has the update permission for the decentralized application according to the user information and the application identifier carried in the application update request;

[0123] The update module 20 is further configured to, when the client has the update permission, determine the second application update data, and update the target application configuration data according to the second application update data to obtain the updated target application configuration data;

[0124] The second storage module 21 is further configured to determine the fourth data hash of the updated target application configuration data, and store the fourth data hash in the blockchain so that the application update node sends the transfer data volume to the client.

[0125] In some feasible embodiments, the device 1 further includes:

[0126] The third storage module 22 is further configured to store the updated target application configuration data in the local storage space;

[0127] The fourth storage module 23 is further configured to update the first smart contract according to the second application update data to obtain the third smart contract and store the third smart contract in the blockchain, so that when it is detected again that the client starts the decentralized application, the third smart contract is determined from the blockchain and the fourth data hash is obtained according to the third smart contract.

[0128] In specific implementation, the device 1 can execute the implementation manners provided in the above Figure 2 、 Figure 6 and / or Figure 7 through each built-in functional module. For the specific implementation manners provided in the above steps, reference can be made to the implementation manners provided in the above steps, which will not be elaborated here.

[0129] In the embodiment of the present application, when detecting the start instruction triggered by the client, the validity of the start instruction can be verified according to the public key and digital signature of the client, so as to avoid the mis-start of the decentralized application to a certain extent. Secondly, the data hash of the target application configuration data can be obtained from the blockchain, and the integrity of the target application configuration data stored in the local storage space can be verified according to the data hash, so as to realize the verification of the local application configuration data before starting the decentralized application, improve the security of the decentralized application, and have high applicability.

[0130] See Figure 9 , Figure 9 is the structural schematic diagram of the device provided in the embodiment of the present application. AsFigure 9 As shown in Figure 9 , the device 1000 in this embodiment may include: a processor 1001, a network interface 1004, and a memory 1005. In addition, the above device 1000 may further include: a user interface 1003 and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may include a display screen (Display) and a keyboard (Keyboard). Optionally, the user interface 1003 may further include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory. The memory 1005 may optionally be at least one storage device located far from the aforementioned processor 1001. As Figure 9 As shown in Figure 9 , the memory 1005, as a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0131] In Figure 9 In the device 1000 shown in Figure 9 , the network interface 1004 can provide network communication functions; while the user interface 1003 is mainly used to provide an input interface for users; and the processor 1001 can be used to call the device control application program stored in the memory 1005 to implement:

[0132] When detecting a startup instruction triggered by the user terminal, obtain the digital signature of the startup instruction carried by the above startup instruction and the application identifier of the decentralized application to be started by the above user terminal;

[0133] Obtain the public key of the above user terminal, and when it is determined that the above startup instruction is a valid instruction according to the above public key and the above digital signature, obtain the target application configuration data of the above decentralized application from the local storage space according to the above application identifier;

[0134] Determine the first smart contract corresponding to the above target application configuration data from the blockchain according to the above application identifier, and execute the above first smart contract to obtain the first data hash of the above target application configuration data from the blockchain;

[0135] Determine the second data hash of the above target application configuration data, and match the above first data hash with the above second data hash. When the above first data hash is consistent with the above second data hash, generate the target application window of the above decentralized application according to the above target application configuration data;

[0136] Establish a communication mechanism between the target application window and the blockchain according to the above-mentioned target application configuration data to display the target application window.

[0137] In some feasible embodiments, the above-mentioned processor 1001 is used for:

[0138] Obtain the first application configuration data marked by the above-mentioned application identifier from the local storage space;

[0139] Determine the first version information corresponding to the first application configuration data, and send the first version information to the consensus node in the blockchain, so that the consensus node verifies whether the first version information is lower than the preset version information of the decentralized application in the blockchain;

[0140] If the first version information is not lower than the preset version information, determine the first application configuration data as the target application configuration data, and obtain the target application configuration data from the local storage space.

[0141] In some feasible embodiments, the above-mentioned processor 1001 is further used for:

[0142] If the first version information is lower than the preset version information, send a data acquisition request to the blockchain to determine the second smart contract corresponding to the target application configuration data from the blockchain;

[0143] Execute the second smart contract to obtain the first application update data of the decentralized application from the blockchain, and update the first application configuration data according to the first application update data to obtain the target application configuration data.

[0144] In some feasible embodiments, the above-mentioned processor 1001 is used for:

[0145] Determine whether there is a first application process for the decentralized application;

[0146] When there is the first application process for the decentralized application, generate a target application window according to the first application process and the target application configuration data;

[0147] When there is no first application process for the decentralized application, send a start request to the blockchain consensus node so that the consensus node verifies whether the start request is a valid request;

[0148] When the start request is a valid request, create a second application process for the decentralized application, and generate the target application window according to the second application process and the target application configuration data.

[0149] In some feasible embodiments, the above-mentioned processor 1001 is further configured to:

[0150] Obtain the user data generated by the above-mentioned client when accessing the above-mentioned decentralized application, and determine the time of each application window for the above-mentioned client to access the above-mentioned decentralized application according to the above-mentioned user data;

[0151] Determine the application window with the longest access time as the default application window, and determine the third data hash of the second application configuration data corresponding to the above-mentioned default application window;

[0152] Store the above-mentioned second application configuration data in the above-mentioned local storage space, and store the above-mentioned third data hash in the above-mentioned blockchain, so as to display the above-mentioned default application window according to the above-mentioned second application configuration data and the above-mentioned third data hash when the above-mentioned client starts the above-mentioned decentralized application again.

[0153] In some feasible embodiments, the above-mentioned processor 1001 is further configured to:

[0154] When detecting an application update request triggered by the above-mentioned client, send the above-mentioned application update request to the application update node of the above-mentioned blockchain, so that the above-mentioned application update node determines whether the above-mentioned client has the update permission for the above-mentioned decentralized application according to the user information carried in the above-mentioned application update request and the above-mentioned application identifier;

[0155] When the above-mentioned client has the above-mentioned update permission, determine the second application update data, and update the above-mentioned target application configuration data according to the above-mentioned second application update data to obtain the updated target application configuration data;

[0156] Determine the fourth data hash of the above-mentioned updated target application configuration data, and store the above-mentioned fourth data hash in the above-mentioned blockchain so that the above-mentioned application update node sends the transfer data volume to the above-mentioned client.

[0157] In some feasible embodiments, the above-mentioned processor 1001 is further configured to:

[0158] Store the above-mentioned updated target application configuration data in the above-mentioned local storage space;

[0159] Update the above-mentioned first smart contract according to the above-mentioned second application update data to obtain a third smart contract and store the above-mentioned third smart contract in the above-mentioned blockchain, so that when it is detected again that the above-mentioned client starts the above-mentioned decentralized application, the above-mentioned third smart contract is determined from the above-mentioned blockchain and the above-mentioned fourth data hash is obtained according to the above-mentioned third smart contract.

[0160] It should be understood that in some feasible embodiments, the above-mentioned processor 1001 may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. A part of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0161] In a specific implementation, the above-mentioned device 1000 may execute the implementation manners provided in each of the above Figure 2 , Figure 6 and / or Figure 7 through its built-in functional modules. For specific details, refer to the implementation manners provided in each of the above steps, which will not be elaborated here.

[0162] In the embodiments of the present application, when a start instruction triggered by the user terminal is detected, the validity of the start instruction can be verified according to the public key and digital signature of the user terminal, so as to avoid the mis-start of the decentralized application to a certain extent. Secondly, the data hash of the target application configuration data can be obtained from the blockchain, and the integrity of the target application configuration data stored in the local storage space can be verified according to the data hash, so as to realize the verification of the local application configuration data before starting the decentralized application, improve the security of the decentralized application, and have high applicability.

[0163] The embodiments of the present application also provide a computer-readable storage medium storing a computer program, which is executed by a processor to implement the methods provided in each of Figure 2 , Figure 6 and / or Figure 7 above steps. For specific details, refer to the implementation manners provided in each of the above steps, which will not be elaborated here.

[0164] The above computer-readable storage medium may be an internal storage unit of the task processing device provided in any of the foregoing embodiments, such as the hard disk or memory of an electronic device. The computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device. The above computer-readable storage medium may further include magnetic disks, optical discs, read-only memory (ROM), or random access memory (RAM), etc. Further, the computer-readable storage medium may also include both the internal storage unit and the external storage device of the electronic device. The computer-readable storage medium is used to store the computer program and other programs and data required by the electronic device. The computer-readable storage medium may also be used to temporarily store the data that has been output or will be output.

[0165] The terms "first", "second", etc. in the claims, the description, and the drawings of this application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products, or devices. The mention of "embodiments" in this application means that specific features, structures, or characteristics described in connection with the embodiments may be included in at least one embodiment of this application. The display of this phrase at various positions in the description does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein may be combined with other embodiments. The term "and / or" used in the description and claims of this application refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0166] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in connection with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been generally described according to their functions in the above description. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0167] The above disclosure is only for the preferred embodiments of the present application. Of course, the scope of rights of the present application cannot be limited thereby. Therefore, equivalent changes made according to the claims of the present application still fall within the scope covered by the present application.

Claims

1. A method for starting a decentralized application, characterized in that, The method includes: When a startup instruction triggered by a client is detected, obtaining the digital signature of the startup instruction carried by the startup instruction and the application identifier of the decentralized application to be started by the client; Obtaining the public key of the client, and when it is determined that the startup instruction is a valid instruction based on the public key and the digital signature, obtaining the target application configuration data of the decentralized application from the local storage space according to the application identifier; Determining the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and executing the first smart contract to obtain the first data hash of the target application configuration data from the blockchain; Determining the second data hash of the target application configuration data, and matching the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generating a target application window of the decentralized application according to the target application configuration data; Establishing a communication mechanism between the target application window and the blockchain according to the target application configuration data to display the target application window.

2. The method according to claim 1, wherein The obtaining the target application configuration data of the decentralized application from the local storage space according to the application identifier includes: Obtaining the first application configuration data marked by the application identifier from the local storage space; Determining the first version information corresponding to the first application configuration data, and sending the first version information to the consensus nodes in the blockchain so that the consensus nodes verify whether the first version information is lower than the preset version information of the decentralized application in the blockchain; If the first version information is not lower than the preset version information, determining the first application configuration data as the target application configuration data, and obtaining the target application configuration data from the local storage space.

3. The method according to claim 2, wherein The method further includes: If the first version information is lower than the preset version information, sending a data acquisition request to the blockchain to determine the second smart contract corresponding to the target application configuration data from the blockchain; Executing the second smart contract to obtain the first application update data of the decentralized application from the blockchain, and updating the first application configuration data according to the first application update data to obtain the target application configuration data.

4. The method according to claim 1, characterized in that The generating the target application window of the decentralized application according to the target application configuration data includes: Determining whether there is a first application process for the decentralized application; When there is the first application process for the decentralized application, generating a target application window according to the first application process and the target application configuration data; When there is no first application process for the decentralized application, sending a startup request to the blockchain consensus nodes so that the consensus nodes verify whether the startup request is a valid request; When the startup request is a valid request, creating a second application process for the decentralized application, and generating the target application window according to the second application process and the target application configuration data.

5. The method according to claim 1, wherein The method further includes: Obtain the user data generated when the client accesses the decentralized application, and determine the time of each application window for the client to access the decentralized application according to the user data; Determine the application window with the longest access time as the default application window, and determine the third data hash of the second application configuration data corresponding to the default application window; Store the second application configuration data in the local storage space, and store the third data hash in the blockchain, so as to display the default application window according to the second application configuration data and the third data hash when the client starts the decentralized application again.

6. The method according to claim 1, wherein The method further includes: When detecting an application update request triggered by the client, send the application update request to the application update node of the blockchain, so that the application update node determines whether the client has the update permission for the decentralized application according to the user information and the application identifier carried in the application update request; When the client has the update permission, determine the second application update data, and update the target application configuration data according to the second application update data to obtain the updated target application configuration data; Determine the fourth data hash of the updated target application configuration data, and store the fourth data hash in the blockchain so that the application update node sends the transfer data volume to the client.

7. The method according to claim 6, characterized in that, The method further includes: Store the updated target application configuration data in the local storage space; Update the first smart contract according to the second application update data to obtain a third smart contract and store the third smart contract in the blockchain, so that when it is detected again that the client starts the decentralized application, determine the third smart contract from the blockchain and obtain the fourth data hash according to the third smart contract.

8. A starting device for a decentralized application, characterized in that, The device includes: A first acquisition module, configured to, when detecting a start instruction triggered by a client, acquire the digital signature of the start instruction carried in the start instruction and the application identifier of the decentralized application to be started by the client; A second acquisition module, configured to acquire the public key of the client, and when determining that the start instruction is a valid instruction according to the public key and the digital signature, acquire the target application configuration data of the decentralized application from the local storage space according to the application identifier; A third acquisition module, configured to determine the first smart contract corresponding to the target application configuration data from the blockchain according to the application identifier, and execute the first smart contract to obtain the first data hash of the target application configuration data from the blockchain; A first processing module, configured to determine the second data hash of the target application configuration data, and match the first data hash with the second data hash. When the first data hash is consistent with the second data hash, generate a target application window of the decentralized application according to the target application configuration data; A second processing module, configured to establish a communication mechanism between the target application window and the blockchain according to the target application configuration data to display the target application window.

9. A device, characterized in that, Comprising a processor and a memory, the processor and the memory are interconnected; The memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the method according to any one of claims 1 to 7.

Images