Decentralization-based front-end component updating method and updating device

Abstract

The invention provides a front-end component updating method and a front-end component updating device based on decentration. The method comprises the steps of establishing connection between a current block chain and a front-end application based on a component interface and an adaptation layer, and monitoring a real-time event of the current block chain by adopting an intelligent contract; after it is determined that the real-time event meets a preset front-end component updating condition, latest component information is sent to a front-end application through a smart contract, so that the front-end application is triggered to send an updating request carrying the latest component information; according to the updating request, obtaining a to-be-updated component file from the decentralized storage network, and sending the to-be-updated component file to the front-end application, so that the front-end application updates a front-end component according to the to-be-updated component file; and after it is determined that the front-end component is updated and a preset operation condition is met, the smart contract receives a record updating instruction carrying the current component operation version information so as to update the recorded component operation version information. According to the method and the device, the real-time performance and accuracy of front-end component updating are realized.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a decentralized front-end component updating method and updating device. Background Art

[0002] The front-end component is responsible for the presentation of the user interface and the interaction of data content. Timely updates of front-end components can ensure that the user interface always reflects the latest on-chain status and functional requirements, improve user experience, and enhance the interactivity and practicality of the application. Specifically, component updates usually include the latest security patches and vulnerability fixes. By updating components, the development team can ensure that the system has the latest security protection capabilities, thereby reducing the risk of being attacked. In addition, component updates often bring performance optimizations and code improvements, which can improve overall operating efficiency, reduce resource consumption, and provide a smoother user experience. Front-end component updates also involve functional expansion and improvement. New component versions usually include new functions and features that can enhance the functionality of the system and meet the changing needs of users.

[0003] In the prior art, the update of front-end components usually relies on two methods: centralized server push updates and client regular pull updates. The centralized server push update method usually adopts the notification mechanism of the central server. When a new component version is released, the server will send an update notification to the client. After receiving the notification, the client will download the latest component file from the server and update it. The advantage of this method is that it can push updates quickly, but there is also the risk of single point failure. If there is a problem with the central server, the update function of the entire system will be affected. In addition, the centralized server is the main target of attack. Once it is compromised, the update file may be tampered with, thereby threatening the security of the system.

[0004] Another common method is for the client to pull updates regularly. The client will periodically send requests to the server to check if there is a new component version available. If there is a new version, the client will download and install the update file. The advantage of regularly pulling updates is that the client can decide the frequency of updates independently, reducing excessive dependence on the central server. However, if the pull interval is long, the real-time nature of the update will be affected and it will not be possible to respond to change requirements in a timely manner.

[0005] However, although the existing technical methods can meet the update requirements of front-end components to a certain extent, under the background of the increasing popularity of blockchain technology, the existing component update solutions cannot fully utilize the decentralized and tamper-proof characteristics of blockchain to improve the security and reliability of the system. Therefore, a decentralized front-end component update method is urgently needed to solve the problem of poor real-time performance of front-end component updates in the existing technology. Summary of the invention

[0006] The present application provides a decentralized front-end component update method and update device to solve the technical problem of poor real-time performance of front-end component updates, realize the automation of front-end component updates, and improve the efficiency and accuracy of updates.

[0007] In a first aspect, the present application provides a decentralized front-end component update method, comprising:

[0008] Based on the preset component interface, a connection is established between the current blockchain and the front-end application through an adaptation layer that matches the current blockchain, and the deployed smart contract is used to monitor the real-time events of the current blockchain;

[0009] After determining that the real-time event meets the preset front-end component update condition, the latest component information is sent to the front-end application through the smart contract to trigger the front-end application to send an update request carrying the latest component information;

[0010] According to the update request, obtaining a component file to be updated corresponding to the latest component information from a preset decentralized storage network, and sending the component file to be updated to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated;

[0011] Monitor the update of the front-end component. After determining that the update of the front-end component is completed and meets the preset operating conditions, receive a record update instruction carrying the current component running version information through the smart contract, so that the smart contract can update the recorded component running version information to complete the update of the front-end component.

[0012] Optionally, the method as described above further comprises:

[0013] After determining that the front-end component update is complete and the preset operating conditions are not met, performing a version rollback operation according to a preset rollback strategy; or,

[0014] After determining that the front-end component has not been updated, a version rollback operation is performed according to a preset rollback strategy.

[0015] Optionally, in the method described above, establishing a connection between the current blockchain and the front-end application based on a preset component interface through an adaptation layer matching the current blockchain includes:

[0016] Loading the preset component interface definition to complete the component interface setting; wherein the component interface definition includes the input parameters, output results and data interaction rules of the front-end component;

[0017] Initialize the adaptation layer and load the preset protocol and data conversion rules in the adaptation layer to realize the data conversion between the front-end component and the current blockchain;

[0018] Read the configuration file or predefined parameters to load the connection parameters of the current blockchain; wherein the connection parameters include the node address and port number;

[0019] The component interface is called through the front-end application, and a connection with the current blockchain is established through the adaptation layer according to the connection parameters.

[0020] Optionally, in the method described above, the using of a deployed smart contract to monitor real-time events of the current blockchain includes:

[0021] Based on the smart contract deployed to the current blockchain, establish a connection between the smart contract and a log subscriber, and obtain the real-time log of the current blockchain through the log subscriber;

[0022] By using a preset event filter, according to the real-time log, event logs that meet the event filtering conditions are screened and obtained; wherein the event filtering conditions are set according to the event type, trigger and event parameters;

[0023] The smart contract is used to parse the event log to monitor the real-time events of the current blockchain.

[0024] Optionally, in the method described above, the determining that the real-time event meets a preset front-end component update condition includes:

[0025] According to the event to be analyzed in the event log, obtaining the event type of the event to be analyzed;

[0026] If the event type is a preset trigger update event type, determining that the real-time event meets a preset front-end component update condition;

[0027] After determining that the real-time event meets the preset front-end component update condition, the latest component information is sent to the front-end application through the smart contract, including:

[0028] Through the smart contract, the latest component information corresponding to the front-end application is obtained, and the latest component information is sent to the front-end application through on-chain transactions or off-chain push mechanisms; wherein the latest component information includes component name, component version number, component hash value and component release timestamp.

[0029] Optionally, the method as described above, constructing the decentralized storage network includes:

[0030] Acquire performance requirement information of the decentralized storage network; wherein the performance requirement information includes at least one of storage capacity, access speed, and security setting information;

[0031] Deploy multiple storage nodes according to the preset decentralized storage platform, and configure the storage capacity, bandwidth limit and access rights of each node according to the performance requirement information to complete the construction of the decentralized storage network;

[0032] According to the update request, a component file to be updated corresponding to the latest component information is obtained from a preset decentralized storage network, and the component file to be updated is sent to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated, including:

[0033] Receiving the update request through the decentralized storage network, and obtaining the component name, component version number, and component hash value by parsing the update request;

[0034] According to the component name, component version number and component hash value, search and obtain the component file to be updated, and send the component file to be updated to the front-end application;

[0035] The front-end application receives and decompresses the component file to be updated, and executes the update of the front-end component to complete the interface rendering of the front-end application.

[0036] Optionally, in the method described above, the monitoring of the update of the front-end component, after determining that the update of the front-end component is completed and meets the preset running conditions, receiving a record update instruction carrying the current component running version information through the smart contract, includes:

[0037] Monitoring the update status of the front-end component and recording update progress data through the front-end application;

[0038] According to the update progress data, after determining that the front-end component update is completed, according to the preset operation verification conditions, the current component is verified through the front-end application, and the verification result of the current component is obtained; wherein the operation verification conditions include loading verification, operation verification and performance compliance verification;

[0039] According to the verification result, the running version information of the current component is obtained; wherein the running version information includes the component version number, the component hash value and the component running status;

[0040] Through the front-end application, an update record instruction carrying the running version information is sent to the smart contract to update the component running version information recorded in the smart contract.

[0041] Optionally, in the method described above, performing a version rollback operation according to a preset rollback strategy includes:

[0042] Receiving a rollback request of the front-end application through the smart contract, and obtaining the previous component version information of the front-end application according to the rollback request;

[0043] According to the previous component version information, the component running version recorded in the smart contract is updated, and the previous component version information is sent to the front-end application through the smart contract, so that the front-end application can perform a component version rollback operation to complete the version rollback.

[0044] Optionally, the method as described above further comprises:

[0045] After it is determined that the front-end component update is completed, the update result is visually presented in the form of a pop-up window through the front-end application; wherein the update result includes an update status and an update timestamp.

[0046] In a second aspect, the present application provides a front-end component updating device, comprising:

[0047] An event monitoring module is used to establish a connection between the current blockchain and the front-end application based on a preset component interface through an adaptation layer that matches the current blockchain, and to monitor real-time events of the current blockchain using a deployed smart contract;

[0048] An update trigger module, for sending the latest component information to the front-end application through the smart contract after determining that the real-time event meets the preset front-end component update condition, so as to trigger the front-end application to send an update request carrying the latest component information;

[0049] An update file acquisition module, configured to acquire, according to the update request, a component file to be updated corresponding to the latest component information from a preset decentralized storage network, and send the component file to be updated to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated;

[0050] The update execution module is used to monitor the update of the front-end component. After determining that the update of the front-end component is completed and meets the preset operating conditions, the update execution module receives the record update instruction carrying the current component running version information through the smart contract, so that the smart contract can update the recorded component running version information to complete the update of the front-end component.

[0051] The decentralized front-end component update method and update device provided by the present application improve the automation and efficiency of the front-end component update. By establishing a connection between the front-end application and the current blockchain based on the preset component interface and the adaptation layer, a flexible connection with different blockchains is realized. The deployed smart contract is used to monitor the real-time events on the chain, and its automated execution capability ensures the monitoring of real-time events and the accurate judgment of the update conditions. After confirming that the real-time event meets the front-end component update conditions, the latest component information is sent to the front-end application through the smart contract, triggering the front-end application to send an update request, thereby realizing efficient and real-time update operations. Through the preset decentralized storage network, not only the security and reliability of data storage are improved, but also the dependence on centralized servers is reduced, avoiding single point failure problems. The front-end application directly obtains the component files to be updated from the decentralized storage network, ensuring the efficiency and accuracy of data transmission. The entire update process is managed and coordinated by the smart contract, which simplifies the update process, reduces manual intervention, and improves the level of automation. When the front-end component completes the update and passes the preset running conditions, the latest running version information is fed back to the smart contract to achieve synchronous recording of the update status, further ensuring the integrity and traceability of the update process. Through the above process, the real-time, accurate and controllable version updates of front-end components are achieved in a dynamic operating environment, which enhances the user experience and improves the operation and maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0053] Figure 1 A flowchart of a front-end component updating method provided in an embodiment of the present application;

[0054] Figure 2 A schematic diagram of a method flow for a front-end component update failure provided in an embodiment of the present application;

[0055] Figure 3 A schematic diagram of a method flow for performing version rollback provided in an embodiment of the present application;

[0056] Figure 4 A schematic diagram of a method flow for establishing a connection between the current blockchain and a front-end application provided in an embodiment of the present application;

[0057] Figure 5 A schematic diagram of a method flow for monitoring real-time events of the current blockchain provided in an embodiment of the present application;

[0058] Figure 6 A schematic flow chart of a method for determining that a real-time event satisfies a front-end component update condition provided in an embodiment of the present application;

[0059] Figure 7 A schematic diagram of a method for building a decentralized storage network provided in an embodiment of the present application;

[0060] Figure 8 A schematic diagram of a method flow for obtaining a component file to be updated provided in an embodiment of the present application;

[0061] Fig. 9 A flowchart of a method for updating a smart contract provided in an embodiment of the present application;

[0062] Fig.10 A schematic diagram of the structure of a front-end component updating device provided in an embodiment of the present application;

[0063] Fig.11 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0064] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0065] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0066] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0067] In the current Internet application architecture, front-end components are responsible for user interaction, data display and business logic execution. These front-end components usually rely on traditional centralized servers or cloud environments for development, deployment and management, forming a relatively mature and stable application model. However, with the development of blockchain technology and the gradual popularization of Web3.0, application systems are gradually transforming towards decentralization. In the prior art, the update of front-end components mainly relies on manually pulling new version component files or performing version control through a centralized version management platform. This method can meet basic needs in stable application scenarios with low update frequency, but it is difficult to achieve efficient and automated synchronization updates of front-end components in complex environments with frequent changes in smart contracts or real-time updates of on-chain data. In addition, the prior art still has deficiencies in cross-chain compatibility and automated updates of front-end components. The traditional component update mechanism lacks an adaptation layer for the interface differences of different blockchain platforms, which makes it difficult to upgrade and dynamically expand front-end components in a multi-chain environment. At the same time, the storage and distribution of component files still rely on centralized storage networks, which poses a single point of failure risk and cannot fully utilize the advantages of high availability and data immutability of decentralized storage.

[0068] Based on the above technical problems and requirements, this application proposes a decentralized front-end component update method, which realizes the connection between the front-end application and the blockchain through the preset component interface and the adaptation layer matching the current blockchain, and uses the deployed smart contract to monitor the chain events in real time. When an event that meets the preset update conditions is detected, the smart contract automatically sends the latest component information to the front-end application, triggering an automated component update request. The front-end application obtains the corresponding component file to be updated through the preset decentralized storage network, and performs front-end component updates and interface rendering. At the same time, the update process is monitored to ensure that the updated component meets the preset operating conditions, and the latest component operating version information is recorded through the smart contract to realize the trusted storage and synchronization of version information. This not only improves the real-time and automation of the front-end component update, but also enhances the decentralized management capabilities and multi-chain compatibility, and improves the user experience and the overall stability of the application.

[0069] This application is applicable to various application scenarios that require dynamic presentation and update of front-end components in a blockchain environment. For example, on a decentralized finance (DeFi) platform, the interaction and state changes of smart contracts require the front-end interface to reflect the latest transaction information and asset status in real time; in a digital asset trading platform, the front-end components need to dynamically display the prices, trading volumes, and position information of multi-chain assets to ensure that users obtain real-time and accurate market data; in cross-chain data interaction applications, the front-end components need to adapt to the data formats and interface specifications of different blockchain platforms to achieve unified display and operation of multi-chain data. In these scenarios, the method proposed in this application can effectively solve the problems of automated updates, decentralized management, and multi-chain compatibility in the prior art, and meet the requirements of decentralized applications for the real-time, stability, and user experience of front-end components.

[0070] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0071] Figure 1 The flowchart of the front-end component updating method provided in the embodiment of the present application is shown in FIG. Figure 1 As shown, the decentralized front-end component update method includes:

[0072] S11, based on the preset component interface, establishes the connection between the current blockchain and the front-end application through the adaptation layer matching the current blockchain, and uses the deployed smart contract to monitor the real-time events of the current blockchain.

[0073] In this embodiment, the preset component interface refers to a set of general interaction standards defined for the front-end application, for example, including data format, transmission protocol, and calling method. Such component interfaces unify the data structure and interaction process, so that there is no need to make a lot of changes to the front-end application when accessing different blockchains in the future. In this process, by standardizing the component parameters and calling methods with known data protocols, unified adaptation for multiple on-chain operations is achieved, laying the foundation for the operation of subsequent front-end applications. Next, in order to enable the front-end application to access a specific blockchain, an adaptation layer is required to complete basic communication and data parsing. The adaptation layer refers to a translation and transit module between the front-end application and the current blockchain. It adapts the blockchain node address, port number, and on-chain data format, and performs protocol conversion and data type mapping when necessary. In short, the adaptation layer is responsible for converting the front-end application's request into a format that meets the requirements of the blockchain, and converting the data on the blockchain into a format that the front-end application can understand and process. By loading the transmission protocol and data conversion standard in the adaptation layer, seamless access of the front-end application to the current blockchain is achieved, ensuring that the underlying data remains consistent and complete during transmission and reception.

[0074] After the connection between the front-end application and the blockchain is established, the deployed smart contract can respond immediately when the blockchain status changes by listening to the real-time events of the blockchain. This process relies on the predefined event mechanism in the smart contract. The smart contract obtains real-time event logs by listening to transaction records, contract execution status changes or other event trigger points in the blockchain. These real-time events can reflect the execution results of specific operations on the blockchain, such as token transfers, asset changes, transaction completion, etc. By listening to real-time events, the smart contract can not only ensure that the front-end application obtains the latest status of the blockchain in a timely manner, but also automatically trigger subsequent operations when the preset conditions are met, such as update requests for front-end components, component version updates and status verification. The ability of smart contracts to listen to real-time events enables the front-end application to update the interface information in time when the blockchain changes, keep it synchronized with the data on the chain, and reduce the low efficiency of manually pulling or polling data in the traditional way. In addition, the deployment and event listening mechanism of smart contracts ensure the credibility and immutability of data. Since smart contracts run on the blockchain, their execution process is transparent, automated, and cannot be tampered with. Therefore, the events and data received by the front-end application are all from a reliable blockchain network, reducing the risk of data tampering. In general, through the preset component interface, adaptation layer and smart contract, efficient and automated data interaction between the front-end application and the blockchain is achieved, and the event changes in the blockchain can be responded to in real time, providing support for the dynamic update and real-time rendering of the front-end components. This technical solution not only improves the overall response speed, but also enhances the synchronization and consistency between the blockchain and the front-end application, ensuring that the front-end components can reflect the latest on-chain data in a timely and accurate manner, improving the user experience and overall stability.

[0075] S12, after determining that the real-time event meets the preset front-end component update conditions, the latest component information is sent to the front-end application through the smart contract to trigger the front-end application to send an update request carrying the latest component information.

[0076] In this embodiment, the smart contract continuously monitors real-time events on the current blockchain. These events may come from various on-chain operations, such as token transfers, contract calls, or node status changes. However, not all events have the conditions to trigger the front-end component update. In order to ensure the accuracy and efficiency of the update process, the front-end component update conditions are predefined, and only when the detection event meets the front-end component update condition event. Exemplary, the front-end component update conditions include specific event types, the identity of the event triggerer, event parameters, etc. For example, only when a specific event occurs, the smart contract will determine that the front-end component needs to be updated, or when certain data in the event reaches a preset threshold, the component update will be triggered. This mechanism effectively reduces the resource waste and performance burden caused by frequent triggering of update requests by non-related events. Once the smart contract determines that the real-time event meets the update conditions, the smart contract sends the latest component information (such as component name, version number, hash value, etc.) to the front-end application along the interaction channel established by the current blockchain. The latest component information is used to identify the front-end component version that needs to be updated and trigger the front-end application to initiate an update request. Controlling the triggering of front-end component updates through smart contracts not only ensures the accuracy of update operations, but also ensures the security and credibility of the update process through the decentralization of blockchain and the immutability of smart contracts. After receiving the latest component information from the smart contract, the front-end application will generate and send an update request containing the latest component information. This process does not require human intervention and relies on smart contracts and automation mechanisms to improve update efficiency and response speed. The introduction of decentralized storage networks ensures the availability and data integrity of component files. In general, through the monitoring and response of smart contracts to specific events, the automation, reliability and decentralized management of front-end component updates are achieved. It not only improves the adaptability and user experience of front-end applications in a changing blockchain environment, but also enhances overall security and stability.

[0077] S13, according to the update request, obtain the component file to be updated corresponding to the latest component information from the preset decentralized storage network, and send the component file to be updated to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated.

[0078] In this embodiment, when the update request is transmitted to the preset decentralized storage network, the decentralized storage network will retrieve the corresponding component files to be updated from the globally distributed node storage based on the hash value or other identification parameters contained in the latest component information. Such files are usually stored on multiple independent nodes in a decentralized manner, with a high degree of redundancy and tamper-proof characteristics, thereby reducing the risk of single point failure while maintaining data integrity. During the retrieval process, the decentralized storage network can perform link addressing and path optimization for the request according to the preset performance requirements and access control policies, so that the front-end application can obtain the component files to be updated within a reasonable access delay.

[0079] During the file transmission process, the data blocks of the component files to be updated are transmitted using a secure data transmission protocol. Encryption verification, redundant coding or differentiated transmission strategies can be selected as needed to ensure the reliability and verifiability of the file data during the transmission process. When the front-end application receives the component file to be updated, it can perform a data integrity check through the hash value in the latest component information obtained in advance without relying on the verification of the centralized server. After the integrity check passes, the front-end application can update the front-end component according to the actual content of the file to present the latest interface and functional features to the user. Exemplarily, this update process usually includes replacing the old version of the component file, updating the configuration file, and performing the corresponding resource loading operation. In short, the distribution of component files through a decentralized storage network and the seamless collaboration of smart contracts and front-end applications achieve the automation, reliability and security of component updates. Through decentralized storage, the single point failure problem of traditional centralized servers is reduced, and good scalability is maintained in a large-scale distributed environment. The version control, data verification and transmission encryption mechanisms used in the front-end component update process ensure the efficiency, accuracy and security of the entire update process.

[0080] S14, monitor the update of the front-end component. After determining that the update of the front-end component is completed and meets the preset operating conditions, receive the record update instruction carrying the current component running version information through the smart contract, so that the smart contract can update the recorded component running version information to complete the update of the front-end component.

[0081] In this embodiment, during the update process of monitoring the front-end component, the real-time analysis of the update status of the front-end component ensures that the front-end component completes the update under the condition of meeting the preset operating conditions. The front-end application continuously monitors the update progress of its components, and confirms whether the update is successfully completed as expected based on indicators such as operating status, loading time, and resource consumption. After the front-end component is updated and meets the preset operating conditions, the front-end application will send a record update instruction carrying the current component running version information to the smart contract. At this time, the front-end application will not only package the latest component version number, component hash value, and component running status information into an update record, but also attach the current component running verification result (such as whether the component runs smoothly in the user environment, whether it meets the performance standards, etc.) for further processing by the smart contract. After receiving the update instruction, the smart contract will parse and verify these data. First, the smart contract will check whether the transmitted component running version information is consistent with the version information already recorded on the chain to ensure that the update operation is not affected by tampering or erroneous operation. Secondly, the smart contract will also verify the running verification results submitted by the front-end application to confirm whether the function and performance of the front-end component meet the preset standards. For example, if the preset conditions require that the front-end component must be loaded within a preset time threshold and run with low latency, the smart contract will analyze the component operation based on the transmitted performance data.

[0082] Once these verifications are successful, the smart contract will update the component version record stored on the chain to ensure accurate reflection of the current component status and version information. This operation can synchronize the operation of the front-end components in real time, ensure that the data on the blockchain is consistent with the actual status of the front-end application, and support subsequent version management, fault tracking, rollback operations, etc. In addition, the smart contract can also trigger the corresponding subsequent process or state change according to the current update situation. For example, if the component update is completed and the verification is passed, the smart contract can further record the timestamp of this update and create a corresponding event log. This process ensures that the update of the front-end components is not only automated and standardized at the technical level, but also transparent and tamper-proof in the blockchain. The version information of the front-end components is accurately recorded, providing a reliable basis for future troubleshooting, version tracing and cross-platform data synchronization. At the same time, through the automated management of the front-end component update process by smart contracts, efficient monitoring and dynamic adjustment of the entire component life cycle are achieved, thereby improving the user experience and ensuring the stability and security of operation.

[0083] The embodiment of the present application improves the automation and efficiency of front-end component updates. By establishing a connection between the front-end application and the current blockchain based on the preset component interface and the adaptation layer, flexible connections with different blockchains are achieved. The deployed smart contract is used to monitor the real-time events on the chain, and its automated execution capability ensures the monitoring of real-time events and accurate judgment of update conditions. After confirming that the real-time event meets the front-end component update conditions, the latest component information is sent to the front-end application through the smart contract, triggering the front-end application to send an update request, thereby achieving efficient and real-time update operations. Through the preset decentralized storage network, not only the security and reliability of data storage are improved, but also the dependence on centralized servers is reduced, avoiding single point failure problems. The front-end application directly obtains the component files to be updated from the decentralized storage network, ensuring the efficiency and accuracy of data transmission. The entire update process is managed and coordinated by the smart contract, which simplifies the update process, reduces manual intervention, and improves the level of automation. When the front-end component completes the update and passes the preset operating conditions, the latest running version information is fed back to the smart contract to achieve synchronous recording of the update status, further ensuring the integrity and traceability of the update process. Through the above process, the real-time, accurate and controllable version updates of front-end components are achieved in a dynamic operating environment, which enhances the user experience and improves the operation and maintenance efficiency.

[0084] Figure 2 The following is a flow chart of a method for updating a front-end component that fails according to an embodiment of the present application. It is an explanation of other situations corresponding to the above step S14. Based on the above embodiment, Figure 2 As shown, including:

[0085] S21, after determining that the front-end component update is completed and the preset operating conditions are not met, performing a version rollback operation according to a preset rollback strategy;

[0086] S22: After determining that the front-end component has not been updated, perform a version rollback operation according to a preset rollback strategy.

[0087] In this embodiment, during the update of the front-end component, if it is detected that the component update fails to meet the preset operating conditions, or an abnormality occurs during the update process, the version rollback operation will be automatically performed according to the preset rollback strategy. This rollback strategy is to ensure that the stable version can be restored when a problem occurs, and to avoid functional abnormalities or decreased user experience in the front-end application due to component update failure. First, the front-end application will continuously monitor the status of the component during the update process. For example, by collecting the performance data and operation log of the component, it can be determined whether the component meets the preset operating conditions. These conditions may include indicators such as loading time, response speed, resource consumption, compatibility, etc., and further, they can cover the correctness of the business logic and the visual effects of the user interface. If it is detected that the component fails to meet these conditions after the update is completed, the rollback mechanism will be triggered immediately. The rollback mechanism will automatically restore to the stable version before the update based on the preset strategy to ensure that the user experience is not interrupted and the system is restored to an operational state. If it is found that the front-end component has not completed the update during the update of the front-end component, it may be due to network problems, storage problems, or damage to the file downloaded by the component, and the rollback strategy will also be activated. In this case, the update process will be stopped and restored to the previous version according to the rollback strategy. By presetting the rollback strategy, the front-end component version can be flexibly downgraded when the operating conditions are not met or the update fails, avoiding long-term interruption of application functions or deterioration of user experience due to update failure. This kind of rollback mechanism improves the reliability and sustainable operation of the front-end application, while ensuring that users can still obtain continuous operation experience and basic function support when encountering component update anomalies.

[0088] In a specific embodiment, Figure 3 A schematic diagram of a method for version rollback provided in an embodiment of the present application. Figure 3 As shown, including:

[0089] S31, receiving a rollback request of the front-end application through a smart contract, and obtaining the previous component version information of the front-end application according to the rollback request;

[0090] S32, based on the previous component version information, updates the component running version recorded in the smart contract, and sends the previous component version information to the front-end application through the smart contract, so that the front-end application can perform the component version rollback operation and complete the version rollback.

[0091] In this embodiment, during the update process of the front-end component, due to various reasons, the new component version may not meet expectations, resulting in problems or performance degradation in the front-end application. At this time, it is necessary to perform a version rollback operation to restore to the previous stable version. To this end, the smart contract can promptly process and execute the rollback operation of the component version by receiving a rollback request from the front-end application, ensuring that the application can quickly recover to a reliable state. Specifically, when it is determined that there is a problem with the updated component, the front-end application will initiate a rollback request. The rollback request contains the status information of the current front-end application and the information of the previous component version requested for recovery. After the front-end application sends a rollback request through the smart contract, the smart contract will obtain the component information of the previous version according to the request content. This information usually includes the name, version number, hash value and other related metadata of the component, which enables the smart contract to identify the component version to be rolled back to. After receiving the rollback request, the smart contract will find and update the component running version information recorded on the blockchain. The records in the smart contract usually store the historical version of each component and the corresponding running status, so the smart contract can quickly update the current running version according to the previous version information in the rollback request. This update not only ensures that the data in the smart contract accurately reflects the component version currently used by the front-end application, but also ensures that all blockchain-related operations (such as data verification, event processing, etc.) are consistent with the restored component version.

[0092] Next, the smart contract sends the information of the previous component version to the front-end application through an on-chain or off-chain mechanism. This information includes the component name, version number, hash value, etc. of the previous version, ensuring that the front-end application can obtain the correct component version. After receiving this information, the front-end application will automatically trigger the rollback operation, that is, restore it to the specified previous version by downloading and replacing the current version of the component file. This process may involve obtaining the previous version of the component file from a decentralized storage network or other backup storage, and completing the recovery operation through steps such as decompression and installation. After the version rollback is completed, the front-end application will verify the rolled-back component to ensure that the component can be loaded correctly and run stably. In this process, the front-end application will perform a comprehensive check on the rolled-back component according to the preset operation verification conditions (such as loading verification, functional verification, and performance verification). If the component successfully passes the verification, the front-end application marks the operation as successful and notifies the user. The rollback of the front-end component version is performed through smart contracts. The operation of the rollback process is fully automated, avoiding the uncertainty and errors caused by manual intervention, and ensuring the efficiency of the recovery operation. Secondly, the rollback information is recorded on the blockchain, ensuring the transparency and traceability of the operation, and all rollback records can be queried and verified through smart contracts. In addition, smart contracts can flexibly respond to different rollback requests and support multiple rollbacks based on historical versions to adapt to different business scenarios.

[0093] In one embodiment, Figure 4 The following is a flow chart of the method for establishing a connection between the current blockchain and the front-end application provided in the embodiment of the present application. It is a further explanation of the implementation method in the above step S11. Based on the above embodiment, Figure 4 As shown, including:

[0094] S41, loading a preset component interface definition to complete component interface settings; wherein the component interface definition includes input parameters, output results, and data interaction rules of the front-end component;

[0095] S42, initializing the adaptation layer and loading the preset protocol and data conversion rules in the adaptation layer to realize the data conversion between the front-end component and the current blockchain;

[0096] S43, reading a configuration file or predefined parameters, and loading the connection parameters of the current blockchain; wherein the connection parameters include a node address and a port number;

[0097] S44, through the front-end application, calls the component interface, and through the adaptation layer, establishes a connection with the current blockchain according to the connection parameters.

[0098] In this embodiment, the preset component interface definition is loaded to ensure the effective interaction between the front-end component and the blockchain environment. The component interface definition includes multiple key parts: the input parameters, output results and data interaction rules of the front-end component. The input parameters usually include various data formats required when the front-end component interacts with the blockchain, such as transaction data requested by the user, parameters of the smart contract function, etc.; the output results involve the data format expected to be received by the front-end component, which may be the transaction status read from the blockchain, the smart contract execution results or the response data of the chain event, etc. The data interaction rules explain how the front-end component and the blockchain transmit information through appropriate protocols and data structures to ensure that the data will not be lost, damaged or inconsistent during the transmission process. After completing the component interface definition, the adaptation layer needs to be initialized next. The main function of the adaptation layer is to convert and adapt the differences between the requests of the front-end application and the requirements of the blockchain environment. By loading the protocols and data conversion rules in the adaptation layer, the conversion of different data formats and protocols can be effectively handled, ensuring that the requests sent by the front-end application can be correctly understood by the blockchain, and ensuring that the data returned by the blockchain can be parsed and displayed in the format required by the front-end application. By implementing a bidirectional mapping from request to response in the adaptation layer, the correctness and maintainability of data processing are improved, while ensuring the universality and scalability of the adaptation layer in multi-link access solutions.

[0099] Next, you need to read the configuration file or predefined parameters to load the connection parameters of the current blockchain. The connection parameters usually include information such as node address and port number. The node address is the unique identifier of the node in the blockchain network, and the port number indicates the port used by the communication protocol to ensure that the connection is established with the correct blockchain node. Reading these configuration files can ensure that the connection parameters with the current blockchain can be automatically identified at runtime, and the connection with the blockchain can be dynamically established based on this information, even if the front-end application can flexibly adjust the connection target without modifying the source code. After completing the above preparations, the front-end application can start calling the component interface. Through the adaptation layer, the front-end application can send a request to the blockchain and wait for a response. In this process, the adaptation layer automatically establishes a connection with the blockchain node according to the preset connection parameters. In this way, the front-end application can achieve seamless docking with the blockchain, ensuring smooth interaction between the front-end components and the blockchain. This not only improves the scalability and flexibility of the front-end application, but also enhances the application scenarios of blockchain in decentralized applications.

[0100] In a specific embodiment, taking the implementation of the front-end wallet connection component as an example, through integration with a Web3 wallet (such as MetaMask), users are allowed to connect their encrypted wallets in the front-end application and display their account balances and related transaction information in real time. The component is built based on the React framework and uses the Web3.js library to interact with the Ethereum blockchain. In this embodiment, the front-end application first loads the two hook functions "use State" and "use Effect" of React to manage the state of the component. The component defines three state variables through "use State": "web3" (for storing Web3 instances), "account" (storing the currently connected user account address) and "balance" (storing the user account balance). The functions of these state variables are: managing Web3 instances, obtaining the user's Ethereum account address, and displaying the ETH balance of the account.

[0101] When the front-end component is first rendered, the "use Effect" hook checks if Meta Mask is installed and enabled in the browser environment (i.e., if the "window.ethereum" object exists). If so, a new Web3 instance is initialized and the user is asked to authorize the connection of their wallet. Through the "window.ethereum.enable()" method, the application can request the user's authorization and obtain the user's Ethereum account list, and the first account in the list is selected as the currently connected account address by default. At this time, the component updates the "account" state through the "set Account" method and calls the "loadBalance" function to load and display the ETH balance of the account. The "load Balance" function obtains the account's balance (in Wei) through the "get Balance" method provided by Web3.js, then uses the "from Wei" method to convert the balance to ETH units, and updates the balance state in the component through the "set Balance" method. In this way, users can see the ETH balance in their wallets in real time. In the rendering part of the component, when the user has successfully connected the wallet and authorized the account, the component will display "Connected Account" and the ETH balance of the account; if the wallet is not connected, the user is prompted to connect the wallet. This interaction method ensures that users can clearly see their wallet connection status and account information in the front-end application. It can be seen that by simply and efficiently integrating the interaction function between the front-end and the Ethereum blockchain, users can view the real-time balance of their accounts without leaving the front-end interface, which enhances the user experience. In addition, the combination of the Web3.js library and Web3 wallets such as Meta Mask allows this component to be applied across multiple Ethereum-compatible blockchain platforms, with good scalability and compatibility.

[0102] It should be noted here that Meta Mask is a tool and platform. It acts as a bridge between users and the Ethereum blockchain, helping users manage cryptocurrency wallets, log in to blockchain applications securely, and conduct cryptocurrency transactions and token exchanges. Specifically: Meta Mask provides an interface so that users can manage their cryptocurrencies and applications that interact with the blockchain. Meta Mask provides some interfaces and APIs for other applications to call. For example, decentralized applications can interact with the user's Ethereum wallet through Meta Mask's interface to implement operations such as transaction signing and sending. And some functions of Meta Mask also act as an adaptation layer, which handles the communication between the user's browser and the Ethereum blockchain. This includes handling differences in different protocols and data formats, allowing users to easily conduct transactions and interact with the blockchain.

[0103] In one embodiment, Figure 5 The following is a flow chart of a method for monitoring real-time events of the current blockchain provided in an embodiment of the present application. It is a specific description of an implementation method for monitoring real-time events in the above step S11. Based on the above embodiment, Figure 5 As shown, including:

[0104] S51, based on the smart contract deployed to the current blockchain, establish a connection between the smart contract and the log subscriber, and obtain the real-time log of the current blockchain through the log subscriber;

[0105] S52, filtering and obtaining event logs that meet event filtering conditions according to real-time logs through a preset event filter; wherein the event filtering conditions are set according to event type, trigger and event parameters;

[0106] S53, uses smart contracts to parse event logs to monitor real-time events of the current blockchain.

[0107] In this embodiment, based on the smart contract deployed to the current blockchain, it is first necessary to establish a connection between the smart contract and the log subscriber. As a set of self-executing protocols in the blockchain, the main function of the smart contract is to automatically execute operations according to the predefined rules in the contract. The log subscriber is a tool for monitoring and obtaining real-time logs of the blockchain, which can capture all events on the blockchain in real time, including changes in transaction status, execution of smart contracts, and operations related to specific accounts or addresses. By establishing a connection between the smart contract and the log subscriber, real-time monitoring and processing of events on the blockchain can be achieved. The log subscriber continuously monitors the real-time logs of the current blockchain. These logs record all important operations on the blockchain, including the execution of transactions, the call of smart contracts, the production of blocks, and other events on the chain. Due to the decentralized nature of the blockchain, these logs are open and transparent, and can be accessed through a public interface, and any node can obtain log information in real time. This provides an important real-time data source that can respond to various changes on the blockchain at any time.

[0108] After obtaining the real-time log of the current blockchain, the preset event filter filters these log data. Due to the diverse event types, complex triggering conditions and large data volume on the blockchain, the event filter can match conditions based on event type, trigger and event parameters, and only retain the target log data that meets the specified standards from many logs. By adopting event filters, the interference of irrelevant information on subsequent data processing is effectively reduced, the overall data processing efficiency is improved, the efficiency and accuracy of subsequent processing are guaranteed, and the rational use of on-chain resources and processing time is achieved. Among them, event types include transaction events, contract call events, on-chain asset transfer events, etc.; triggers usually refer to the account or address that initiates transactions or smart contract calls; event parameters are specific information related to the event, such as transaction amount, transfer address, operation status, etc. After filtering out event logs that meet the conditions, smart contracts are used to parse these event logs. Smart contracts parse the data in the event logs through predefined logical rules and take corresponding actions based on these data. For example, when a specific event is triggered, the smart contract will parse the event parameters to determine whether it is necessary to trigger component updates, execute transactions within the smart contract, or call other services. By parsing the event log through smart contracts, real-time events can be automatically identified and responded to on the blockchain, thereby achieving dynamic monitoring and management of the blockchain status. This event monitoring mechanism based on smart contracts and log subscribers provides automation capabilities, reduces the need for manual intervention and operation, and ensures the efficiency and consistency of blockchain applications in a frequently changing decentralized environment. In general, through the combination of smart contracts and log subscribers, and the use of event filters, real-time event monitoring and response to the current blockchain can be achieved. This not only improves the response speed, but also enhances the interactivity and flexibility between the blockchain and the front-end application.

[0109] Figure 6 The following is a flow chart of a method for determining that a real-time event satisfies a front-end component update condition provided in an embodiment of the present application. It is an explanation of the specific method in the above step S12. Figure 6 As shown, including:

[0110] S61, obtaining the event type of the event to be analyzed according to the event to be analyzed in the event log;

[0111] S62: If the event type is a preset trigger update event type, determine whether the real-time event meets a preset front-end component update condition.

[0112] In this embodiment, according to the event to be analyzed in the event log, the process of obtaining the event type of the event to be analyzed usually depends on the parsing of the structured fields in the event log. The event log contains a series of fields, such as event identifier, triggering account address, associated block height, and specific event parameters. In other words, each event has a clear identification and structure, usually including event type, related account or address, timestamp, transaction data, and specific status when the event occurs. After obtaining the data of the event to be analyzed, the "event type" of the event will be extracted. Exemplarily, the log records of the event to be analyzed are extracted and matched byte by byte or field by field through the defined data parsing rules and event type mapping table. Among them, the event type may include multiple types such as successful transaction, smart contract execution, data upload, account change, etc. Each event type has different meanings and purposes. According to the pre-set rules, it is judged whether the event meets the conditions to trigger the update of the front-end component.

[0113] If the event type of the event to be analyzed meets the preset trigger update event type, the event meets the conditions for the front-end component update. Among them, the trigger update event type is usually based on demand and pre-defined. For example, the state change of the smart contract, the data upload on the blockchain, the confirmation of a specific transaction, etc. are used as the conditions for triggering the update of the front-end component. By identifying the event type, it is possible to dynamically respond to changes on the blockchain and determine whether the front-end component needs to be updated based on these changes. It should be further explained here that after confirming that the event type meets the preset trigger update conditions, further judgment is required. For example, whether there is a new version available for update, whether the current state of the front-end component is stable, whether the user has the right to update, etc. These conditions are usually verified by the parameters and logic in the smart contract to ensure that the front-end component can be updated only when all necessary conditions are met. In short, by obtaining the event type according to the event to be analyzed in the event log, it is possible to determine whether the event is a preset trigger update event type, and then confirm whether the real-time event meets the conditions for the front-end component update. This event-driven update mechanism can respond to changes on the blockchain in real time and ensure that the front-end application can update the components in time when changes occur, maintaining the efficiency and consistency of the front-end components.

[0114] Further, based on the above embodiment, after determining that the real-time event meets the preset front-end component update condition, the latest component information is sent to the front-end application through the smart contract, including:

[0115] Through smart contracts, the latest component information corresponding to the front-end application is obtained, and the latest component information is sent to the front-end application through on-chain transactions or off-chain push mechanisms; among which, the latest component information includes component name, component version number, component hash value and component release timestamp.

[0116] In this embodiment, the latest component information corresponding to the front-end application can be obtained from the blockchain network through the smart contract. Smart contracts store and manage various types of data about front-end components, including metadata, version information, hash values, etc. of the components. The data stored in the smart contract has the characteristics of traceability and non-tamperability, which is conducive to the front-end application to maintain the transparency and credibility of component version management in the dynamically changing chain environment. When the smart contract monitors the event that triggers the update of the front-end component, it will be responsible for sending the latest relevant component information. Among them, the key content of the component information includes: component name, component version number, component hash value and component release timestamp. The component name is an identifier of the front-end component, usually defined by the developer to distinguish different component types. The component version number indicates the version status of the current component. The component hash value is a unique identifier obtained by encrypting the content of the component file, ensuring that each component obtained is a complete and untampered file. The component release timestamp records the time when the component is deployed to the blockchain, which is used to judge the validity and update timeliness of the component. By using smart contracts, the on-chain data is presented to the front-end application in a structured manner to ensure the reliability and efficiency of data access.

[0117] Next, this information is passed to the front-end application using blockchain transactions or off-chain push mechanisms. On-chain transactions ensure that the information is immutable and permanent by packaging component information into transaction records and writing them into the blockchain. Through transactions, the front-end application can query the latest component data through the blockchain node and obtain the corresponding update information. The off-chain push mechanism pushes component information to the front-end application in real time through external services (such as WebSocket, message queues, push servers, etc.) to ensure that the front-end can obtain the latest component update information as soon as possible. Choose the most suitable mechanism to deliver the latest component information to the front-end application according to actual needs. Whether through blockchain transactions or off-chain push mechanisms, the core goal is to ensure that the front-end application can quickly and accurately receive the latest component information, so as to execute subsequent update requests in the front-end application and display the latest functions and interfaces to users in a timely manner. This method based on smart contracts and blockchain technology ensures the transparency and security of component update information, and at the same time provides a more flexible and reliable update method for front-end applications through the dual mechanisms of on-chain and off-chain.

[0118] In a specific embodiment, this embodiment shows a smart contract implementation scheme for registering and managing front-end component version information, aiming to ensure that the version management process of front-end components is transparent, reliable and tamper-proof through blockchain technology. The smart contract is written in the Solidity programming language and deployed on the Ethereum blockchain, using a decentralized storage system (such as IPFS) to store component files to ensure high availability and security of component data.

[0119] A structure called Component is defined in the smart contract to store the core information of each front-end component. The structure contains three fields: name (component name), ipfsHash (hash value of component file on IPFS) and version (component version number). Name is used to uniquely identify each component, ipfsHash ensures the location and access of component files is safe and reliable, and version is used to track component updates and iterations.

[0120] In order to manage the information of different components, the smart contract creates a components mapping, which maps the component name (string type) to the corresponding Component structure. Through this mapping, the smart contract can efficiently store and retrieve detailed information of each component, and support version management and update operations of multiple components.

[0121] The smart contract also defines an event called Component Published, which is used to record relevant information when a component is published or updated. This event is triggered when component information changes, and contains the component name, IPFS hash value, and version number. Front-end applications or other blockchain listening services can subscribe to this event to automatically obtain the latest component information when the component is updated, thereby achieving dynamic update and synchronization of front-end components.

[0122] The publish Component function in the contract is used to publish and update component information. The function accepts two parameters: the component name _name and the IPFS hash value _ipfsHash of the component file. During the execution of the function, the version number of the current component is first obtained from the components map by the component name, and it is added by 1 to generate a new version number new Version. Then, a new Component instance is created and the information of the corresponding component in the components map is updated. Finally, the emit statement is called to trigger the Component Published event and broadcast the newly released component information. This process ensures that each component release or update has a clear version record and event notification, which facilitates timely response and update of front-end applications.

[0123] In addition, the smart contract provides a getComponent function to query the latest version information of a specific component. This function accepts the component name _name as a parameter and returns the IPFS hash value and version number of the component. By calling this function, the front-end application can easily obtain the latest component information and ensure that its display content is consistent with the version record on the blockchain.

[0124] During the specific implementation process, the publish Component function of the smart contract will be called to submit new component information. Once the smart contract successfully updates the component information and triggers the Component Published event, the front-end application will automatically obtain the latest component file from IPFS after receiving the notification through the event listener, and perform the corresponding update operation. After the update is completed, the front-end application will call the get Component function of the smart contract to confirm the running version information of the current component, and record this information on the blockchain to ensure the transparency and traceability of the version information.

[0125] Figure 7 A schematic diagram of a method for constructing a decentralized storage network provided in an embodiment of the present application. Figure 7 As shown, including:

[0126] S71, obtaining performance requirement information of a decentralized storage network; wherein the performance requirement information includes at least one of storage capacity, access speed, and security setting information;

[0127] S72, deploy multiple storage nodes according to the preset decentralized storage platform, and configure the storage capacity, bandwidth limit and access rights of each node according to the performance requirement information to complete the construction of the decentralized storage network.

[0128] In this embodiment, obtaining the performance requirement information of the decentralized storage network is a prerequisite for ensuring that it reaches the expected operating level during the data management and distribution process. Performance requirement information refers to a series of key parameters that need to be determined before building a decentralized storage network, which is used to measure the basic performance and operating environment of the network. The information includes at least one of storage capacity, access speed and security setting information. Among them, storage capacity refers to the network's requirements for data storage space, which can be set according to the expected data scale and distribution; access speed involves the timeliness of data query and transmission, and the transmission delay and data reading time between nodes need to be set; security setting information is related to data access control and encryption methods to ensure the integrity and credibility of data during transmission and storage. By clarifying these performance requirement information, a reference basis is provided for subsequent node deployment and parameter configuration.

[0129] After obtaining the performance requirement information, multiple storage nodes are deployed according to the preset decentralized storage platform. Different decentralized storage platforms may have different design architectures, protocols, and performance characteristics. Therefore, according to the differences in performance requirement information, the most suitable storage platform needs to be selected. For example, some platforms may focus on high access speeds, while others focus more on storage capacity and data redundancy backup capabilities. After determining the storage platform, the storage nodes in the network need to be configured according to the preset performance requirement information. Storage nodes are the basic units of decentralized storage networks. Each node can store part of the data and participate in the reading and writing of data. Therefore, the configuration of the node needs to be consistent with the performance goals of the platform. First, according to the storage capacity requirements, sufficient storage space is configured for each node. The storage capacity of the node is usually related to the performance of the hardware device, including the size and reading speed of the hard disk. In order to ensure stability and scalability, the storage capacity of the node needs to have a certain degree of redundancy to prevent problems when data is lost or the node is down.

[0130] Secondly, access speed is a factor that affects user experience, especially in high-concurrency, large-scale data access scenarios. In order to meet the access speed requirements, the bandwidth limit of the node needs to be set reasonably. The bandwidth configuration of each storage node determines the data transmission rate and its impact on the overall performance. The configuration of node bandwidth needs to consider not only the network conditions, but also needs to be set according to the access frequency of the data and the size of the traffic. For example, frequently accessed data may need to be load balanced among multiple nodes to ensure that the bandwidth load of each node does not exceed its processing capacity. Each node needs to be configured not only with storage capacity and bandwidth, but also with access control and encrypted transmission of data according to the preset security policy. The configuration of access rights is a measure to ensure data security. Each node can be configured with different access rights policies, and only authorized users or nodes can access specific data. At the same time, the node also needs to be equipped with an encryption algorithm to ensure that the data will not be tampered with or leaked during storage and transmission. In order to ensure the high availability of the network, the node can also configure a data backup mechanism to prevent data loss due to node failure. After completing the above configuration, the entire decentralized storage network can be operated. Under the configuration and optimization of storage nodes, it can provide efficient, secure and reliable data storage services and support high-performance data access for front-end applications. In this way, the decentralized storage network can not only realize the distributed storage of data, but also improve the overall performance while ensuring data security to meet the needs of different application scenarios.

[0131] then, Figure 8 The following is a flow chart of a method for obtaining component files to be updated provided in an embodiment of the present application. It is a specific description of the implementation method of obtaining component files to be updated in the above step S13. Figure 8As shown, including:

[0132] S81, receiving an update request through a decentralized storage network, and obtaining a component name, a component version number, and a component hash value by parsing the update request;

[0133] S82, searching and obtaining the component file to be updated according to the component name, component version number and component hash value, and sending the component file to be updated to the front-end application;

[0134] S83, receiving and decompressing the component file to be updated through the front-end application, and executing the update of the front-end component to complete the interface rendering of the front-end application.

[0135] In this embodiment, the decentralized storage network receives an update request, which is usually initiated by a front-end application and transmitted to the decentralized storage network through a blockchain smart contract or other communication protocol. After receiving the request, the decentralized storage network needs to parse the content of the update request. These requests contain key information required for the update, such as the name of the component, the version number, and the hash value of the component. The component name helps to determine the type or category of the component to be updated; the version number identifies the specific version of the component; the hash value is used as a unique identifier to confirm the integrity and consistency of the component file to avoid data tampering or loss. After determining the component name, version number, and hash value indicated by the request, the decentralized storage network retrieves the internal index structure based on these key information to locate the corresponding component file to be updated. The retrieval process can use hash mapping tables, multi-level index directories, and routing protocols between nodes to make the addressing of the component files to be updated not only efficient, but also to achieve dynamic redundant scheduling in the case of node failure or uneven load.

[0136] After finding the corresponding component file to be updated, the decentralized storage network will transfer the file from the storage node to the front-end application. This process can be completed through network protocols (such as HTTP, IPFS, etc.). Since data storage in a decentralized storage network is scattered across multiple nodes, file transmission usually involves multi-point transmission and multiple data streams. In order to ensure data consistency during transmission, decentralized storage networks generally use encrypted transmission, data integrity verification, and error correction mechanisms to ensure that data is not tampered with or lost during transmission. After finding the target file, the file is quickly sent from the network node to the front-end application through encrypted transmission or a trusted channel, reducing the occurrence of tampering or interception during data transmission.

[0137] Component files are usually transmitted in compressed or packaged formats. After receiving the component files to be updated, the front-end application needs to decompress the files. The decompression process extracts the various resources (such as JavaScript scripts, CSS styles, HTML templates, etc.) in the component files. After the decompression is completed, the front-end application will update the corresponding front-end components according to the content and structure of the file. Updating front-end components usually involves re-rendering of the interface or dynamic loading of functions. Depending on the specific content of the update, the front-end application will update the user interface through DOM operations, rendering engines, or component frameworks (such as React, Vue, etc.). At this time, the front-end component will perform interface rendering operations based on the new component files to reflect the latest functions or interface designs. For example, if the update involves modifications to the UI interface, the front-end application will re-render the interface to ensure that users can see the latest design; if the update contains new functions or fixes, the front-end application will reload the functional modules according to the updated component code and display the corresponding effects on the interface.

[0138] During the update process, the front-end application also needs to perform verification operations to ensure that the updated components can run normally and meet the preset operating conditions. Through this mechanism, the front-end application can obtain and apply the latest component updates in real time, ensuring that users can always experience the latest functions and interfaces. The distributed nature of the decentralized storage network ensures the high availability and fault tolerance of component updates, so that the update process can be completed smoothly even if some nodes fail. Through the above process, the decentralized storage network and the front-end application work together to complete the update operation of the front-end components. This not only ensures that the front-end components can be upgraded flexibly and reliably, but also provides higher security and scalability to meet the needs of modern blockchain applications.

[0139] In one embodiment, Fig. 9 The following is a flow chart of a method for updating a smart contract provided in an embodiment of the present application. It is an explanation of an implementation method for updating smart contract information in the above step S14. Based on the above embodiment, Fig. 9 As shown, including:

[0140] S91, monitor the update status of the front-end component through the front-end application and record the update progress data;

[0141] S92, after determining that the front-end component is updated according to the update progress data, verify the current component through the front-end application according to the preset operation verification conditions, and obtain the verification result of the current component; wherein the operation verification conditions include loading verification, operation verification and performance compliance verification;

[0142] S93, according to the verification result, obtaining the running version information of the current component; wherein the running version information includes the component version number, the component hash value and the component running status;

[0143] S94, sending an update record instruction carrying the running version information to the smart contract through the front-end application to update the component running version information recorded in the smart contract.

[0144] In this embodiment, during the front-end component update process, it is necessary to monitor the update status of the component in real time and record the update progress data. The monitoring of the update status is usually performed through the built-in event monitoring mechanism of the application, which can capture the progress changes in each update step and reflect them on the interface. For example, the front-end application can show the user the completion of the current update through a progress bar or status prompt, and record various data during the update process, such as the number of files downloaded, the number of component modules completed, the timestamp of the current operation, etc. These update progress data provide accurate feedback for subsequent operations, ensuring that the entire update process can be carried out within a controllable range.

[0145] According to the recorded update progress data, the front-end application can perform further verification according to the preset operation verification conditions after detecting that the component update is completed. The operation verification conditions usually cover multiple aspects of testing to ensure that the updated component meets the application's usage requirements and can run in actual operations. The verification content includes but is not limited to loading verification, operation verification and performance compliance verification. Specifically, loading verification is the process of ensuring that the updated component can be correctly loaded and initialized smoothly. In this stage, the resource files of the component are usually checked to check the integrity, compatibility and correct loading of the files to ensure that there are no loading failures due to file loss or path errors. Loading verification helps to find possible resource errors or dependency issues as early as possible after the update. Operation verification focuses on checking whether the updated component can operate as expected. This includes verifying whether the component functions normally, whether the business logic is executed correctly, whether the data flow is smooth, and whether the interaction between the front-end and the back-end is effective. Operation verification usually involves comprehensive testing of the component's functions, simulating user operation scenarios, to confirm that the various functional modules of the component can still run smoothly according to the design requirements after the update. Performance compliance verification tests the performance indicators of components to ensure that the updated components meet the preset performance requirements in terms of resource consumption, response time, fluency, etc. These verification items are usually based on the application's usage scenarios and performance standards, and may include testing the component's loading speed, response time, memory usage, concurrent processing capabilities, etc.

[0146] When the verification work is completed, the front-end application will obtain the verification results of the current component. The verification results mainly include whether the verification is passed and the specific content of the verification. This information provides a basis for subsequent operations (such as record updates, rollback operations, etc.). The data of the verification results includes the component version number, component hash value and component running status. The version number and hash value are used to confirm the specific version of the component and ensure that there is no data damage or tampering during the update process; the running status reflects the performance of the component during the verification process, which may include normal operation, abnormal status or failure to pass a certain verification. According to the verification results, the front-end application will send an update record instruction carrying the current component running version information to the smart contract. This instruction will trigger the smart contract to update the running version information of the current component. In this way, the smart contract can ensure that the records on the blockchain are consistent with the actual running status of the front-end application, and ensure the transparency, traceability and consistency of the front-end component update. Overall, by monitoring the update status of the front-end component, performing comprehensive operation verification, obtaining accurate version information, and recording updates through smart contracts, not only the efficiency and security of the front-end component update are ensured, but also the complete component update process tracking and verification can be provided.

[0147] In one embodiment, based on the above embodiment, the present application further includes:

[0148] After confirming that the front-end component update is complete, the update result is visualized in the form of a pop-up window through the front-end application; the update result includes the update status and update timestamp.

[0149] In this embodiment, when the front-end application detects that the component update has been completed, the application will start a pop-up interface to promptly notify the user of the completion of the update. The pop-up window is a temporary information display window on the interface, which usually appears in a way of superimposing on the existing user interface to ensure that timely feedback is given to the user without destroying the original layout and functional structure. The pop-up window will display the updated status information in detail, including key states such as "update successful" or "update failed". In this way, the user can immediately know whether the update is successfully completed. If the update fails, the pop-up window can also provide corresponding error prompts or suggestions. In addition, the pop-up window will also display the update timestamp, indicating the exact time when the component update operation is completed. The display of the update timestamp can help users understand the latest status of the application, especially when it is necessary to track or trace back historical update records, time information becomes an important reference. Through accurate time stamps, users can clearly know the component version they are using, increase their trust in the front-end application and their ability to control changes.

[0150] To further enhance the visualization, the pop-up window can also include additional interactive elements, such as buttons such as "View Update Log", "Return to Previous Version", or "Retry Update", which allow users to perform further operations. For example, if the user has questions or encounters problems with the current update, the "View Update Log" button can be used to view detailed update content or history records to further confirm what has been updated. If the update is abnormal or the user wants to revert to the previous version, the "Return to Previous Version" button in the pop-up window can quickly trigger a rollback operation to restore to a stable component version. In summary, presenting the update results in the form of pop-ups through the front-end application can effectively enhance the user's right to know about the update process and the convenience of operation, and improve the user's trust and satisfaction. This approach not only ensures the transparency of the update, but also provides a convenient data basis for subsequent version management, troubleshooting, and user support.

[0151] On the basis of the above embodiments, a monitoring function can be added during the operation of Web3 applications to identify and solve potential performance problems, and optimize them according to changes in the blockchain environment and user needs, thereby ensuring that Web3 applications can run efficiently and stably in a complex blockchain environment.

[0152] First, a real-time monitoring mechanism is set up to monitor events on the blockchain, such as the execution of smart contracts, changes in transaction status, and the status of network nodes. For example, monitor whether transactions on the Ethereum blockchain are successful, whether the consumption of Gas fees is abnormal, or whether there are contract execution failures. If events such as transaction failures or abnormal Gas fees are detected, the development team is immediately notified through an alarm mechanism, or automated emergency measures are taken, such as automatic retry of transactions, adjustment of Gas fee parameters, etc. To this end, a blockchain event monitoring tool is integrated to capture and respond to various changes on the chain in real time through event monitoring and log analysis.

[0153] Secondly, performance monitoring tools (such as Lighthouse, New Relic, etc.) are used to monitor the loading time, response speed, memory usage and other indicators of the front-end components to ensure that the user interface can respond smoothly. In scenarios with intensive blockchain interactions, the front-end application needs to process a large amount of on-chain data interactions. Monitoring these performance indicators can help the development team to promptly discover and optimize possible performance problems. For example, if a front-end component takes a long time to load, the loading strategy will be automatically analyzed and optimized based on the monitoring data, such as adjusting the cache mechanism or optimizing the order of resource requests to reduce latency and improve user experience. In terms of monitoring blockchain nodes, the health of blockchain nodes also needs to be ensured. If a node is found to be faulty and cannot process transaction requests or data queries normally, it should be able to automatically switch to a backup node or perform other fault-tolerant processing to avoid service interruptions and ensure the high availability of the system. In addition, performance analysis of on-chain nodes is performed regularly to monitor their response speed and load to ensure continuous and efficient operation in high-concurrency scenarios.

[0154] To ensure that the blockchain network is constantly upgraded and changed, this embodiment also optimizes in a timely manner by real-time monitoring of changes in on-chain protocols and changes in market demand. For example, when the blockchain protocol is upgraded (such as Ethereum's hard fork) or the Layer 2 solution is launched, the code and configuration will be adjusted according to these changes. In order to achieve a rapid response to blockchain protocol upgrades or market changes, new versions and functional updates are launched in a timely manner to ensure that the application always maintains compatibility and competitiveness. In summary, this embodiment ensures that Web3 applications can run continuously and efficiently in a complex blockchain environment through a comprehensive monitoring and performance optimization mechanism. At the same time, it ensures that the application has a high degree of adaptability and flexibility in the face of a changing environment, and also reduces the need for manual intervention through automated monitoring and optimization processes, reduces operation and maintenance costs, and improves overall sustainable development capabilities.

[0155] Fig.10 This is a schematic diagram of the structure of the front-end component updating device provided in the embodiment of the present application. Fig.10 As shown, the updating device 10 comprises:

[0156] The event monitoring module 101 is used to establish a connection between the current blockchain and the front-end application based on a preset component interface through an adaptation layer that matches the current blockchain, and use a deployed smart contract to monitor real-time events of the current blockchain;

[0157] The update trigger module 102 is used to send the latest component information to the front-end application through the smart contract after determining that the real-time event meets the preset front-end component update condition, so as to trigger the front-end application to send an update request carrying the latest component information;

[0158] The update file acquisition module 103 is used to acquire the component file to be updated corresponding to the latest component information from the preset decentralized storage network according to the update request, and send the component file to be updated to the front-end application so that the front-end application updates the front-end component according to the component file to be updated;

[0159] The update execution module 104 is used to monitor the update of the front-end component. After determining that the front-end component update is completed and meets the preset operating conditions, it receives a record update instruction carrying the current component running version information through the smart contract, so that the smart contract can update the recorded component running version information to complete the update of the front-end component.

[0160] The updating device provided in this embodiment can execute the updating method of the above-mentioned embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0161] Fig.11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig.11 As shown, the electronic device 11 includes: at least one processor 111 and a memory 112. The electronic device 11 also includes a communication component 113. The processor 111, the memory 112 and the communication component 113 are connected via a bus 114.

[0162] In a specific implementation process, at least one processor 111 executes the computer-executable instructions stored in the memory 112, so that at least one processor 111 executes the updating method executed by the electronic device side as above.

[0163] The specific implementation process of the processor 111 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0164] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0165] The memory may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk storage.

[0166] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0167] The above-mentioned functions implemented by the electronic device and the main control device introduce the scheme provided by the embodiment of the present invention. It can be understood that in order to implement the above-mentioned functions, the electronic device or the main control device includes a hardware structure and / or software module corresponding to the execution of each function. In combination with the units and algorithm steps of each example described in the embodiment disclosed in the embodiment of the present invention, the embodiment of the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art 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 the technical solution of the embodiment of the present invention.

[0168] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0169] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0170] The present application also provides a computer program product, which includes: a computer program, which is stored in a readable storage medium. At least one processor of an electronic device can read the computer program from the readable storage medium, and at least one processor executes the computer program so that the electronic device executes the solution provided by any of the above embodiments.

[0171] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0172] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-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 sub-steps or stages of other steps.

[0173] It should be understood that the above-mentioned device embodiments are only illustrative, and the device of the present application can also be implemented in other ways. For example, the division of units / modules in the above-mentioned embodiments is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0174] In addition, unless otherwise specified, each functional unit / module in each embodiment of the present application may be integrated into one unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of a software program module.

[0175] If the integrated unit / module is implemented in the form of hardware, the hardware may be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. If not specifically stated, the processor may be any appropriate hardware processor, such as a CPU, a GPU, an FPGA, a DSP, an ASIC, etc. If not specifically stated, the storage unit may be any appropriate magnetic storage medium or magneto-optical storage medium, such as a resistive random access memory RRAM (Resistive Random Access Memory), a dynamic random access memory DRAM (Dynamic Random Access Memory), a static random access memory SRAM (Static Random-Access Memory), an enhanced dynamic random access memory EDRAM (Enhanced Dynamic Random Access Memory), a high-bandwidth memory HBM (High-Bandwidth Memory), a hybrid memory cube HMC (Hybrid Memory Cube), etc.

[0176] If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, 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, which is stored in a memory and includes several instructions for 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 application. The aforementioned memory includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0177] In the above embodiments, the description of each embodiment has its own emphasis. For the part not described in detail in a certain embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0178] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0179] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A decentralized front-end component update method, characterized in that: include: Based on the preset component interface, a connection is established between the current blockchain and the front-end application through an adaptation layer that matches the current blockchain, and the deployed smart contract is used to monitor the real-time events of the current blockchain; After determining that the real-time event meets the preset front-end component update condition, the latest component information is sent to the front-end application through the smart contract to trigger the front-end application to send an update request carrying the latest component information; According to the update request, obtaining a component file to be updated corresponding to the latest component information from a preset decentralized storage network, and sending the component file to be updated to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated; Monitor the update of the front-end component. After determining that the update of the front-end component is completed and meets the preset operating conditions, receive a record update instruction carrying the current component running version information through the smart contract, so that the smart contract can update the recorded component running version information to complete the update of the front-end component.

2. The method according to claim 1, characterized in that The method further comprises: After determining that the front-end component update is complete and the preset operating conditions are not met, performing a version rollback operation according to a preset rollback strategy; or, After determining that the front-end component has not been updated, a version rollback operation is performed according to a preset rollback strategy.

3. The method according to claim 1, characterized in that The connection between the current blockchain and the front-end application is established based on the preset component interface through the adaptation layer matching the current blockchain, including: Loading the preset component interface definition to complete the component interface setting; wherein the component interface definition includes the input parameters, output results and data interaction rules of the front-end component; Initialize the adaptation layer and load the preset protocol and data conversion rules in the adaptation layer to realize the data conversion between the front-end component and the current blockchain; Read the configuration file or predefined parameters to load the connection parameters of the current blockchain; wherein the connection parameters include the node address and port number; The component interface is called through the front-end application, and a connection with the current blockchain is established through the adaptation layer according to the connection parameters.

4. The method according to claim 1, characterized in that: The deployed smart contract is used to monitor the real-time events of the current blockchain, including: Based on the smart contract deployed to the current blockchain, establish a connection between the smart contract and a log subscriber, and obtain the real-time log of the current blockchain through the log subscriber; By using a preset event filter, according to the real-time log, event logs that meet the event filtering conditions are screened and obtained; wherein the event filtering conditions are set according to the event type, trigger and event parameters; The smart contract is used to parse the event log to monitor the real-time events of the current blockchain.

5. The method according to claim 4, characterized in that The determining that the real-time event meets a preset front-end component update condition includes: According to the event to be analyzed in the event log, obtaining the event type of the event to be analyzed; If the event type is a preset trigger update event type, determining that the real-time event meets a preset front-end component update condition; After determining that the real-time event meets the preset front-end component update condition, the latest component information is sent to the front-end application through the smart contract, including: Through the smart contract, the latest component information corresponding to the front-end application is obtained, and the latest component information is sent to the front-end application through on-chain transactions or off-chain push mechanisms; wherein the latest component information includes component name, component version number, component hash value and component release timestamp.

6. The method according to claim 1, characterized in that Constructing the decentralized storage network includes: Acquire performance requirement information of the decentralized storage network; wherein the performance requirement information includes at least one of storage capacity, access speed, and security setting information; Deploy multiple storage nodes according to the preset decentralized storage platform, and configure the storage capacity, bandwidth limit and access rights of each node according to the performance requirement information to complete the construction of the decentralized storage network; According to the update request, a component file to be updated corresponding to the latest component information is obtained from a preset decentralized storage network, and the component file to be updated is sent to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated, including: Receiving the update request through the decentralized storage network, and obtaining the component name, component version number, and component hash value by parsing the update request; According to the component name, component version number and component hash value, search and obtain the component file to be updated, and send the component file to be updated to the front-end application; The front-end application receives and decompresses the component file to be updated, and executes the update of the front-end component to complete the interface rendering of the front-end application.

7. The method according to claim 1 or 2, characterized in that: The monitoring of the update of the front-end component, after determining that the update of the front-end component is completed and the preset running conditions are met, receiving a record update instruction carrying the current component running version information through the smart contract, includes: Monitoring the update status of the front-end component and recording update progress data through the front-end application; According to the update progress data, after determining that the front-end component update is completed, according to the preset operation verification conditions, the current component is verified through the front-end application, and the verification result of the current component is obtained; wherein the operation verification conditions include loading verification, operation verification and performance compliance verification; According to the verification result, the running version information of the current component is obtained; wherein the running version information includes the component version number, the component hash value and the component running status; Through the front-end application, an update record instruction carrying the running version information is sent to the smart contract to update the component running version information recorded in the smart contract.

8. The method according to claim 2, characterized in that: The version rollback operation is performed according to the preset rollback strategy, including: Receiving a rollback request of the front-end application through the smart contract, and obtaining the previous component version information of the front-end application according to the rollback request; According to the previous component version information, the component running version recorded in the smart contract is updated, and the previous component version information is sent to the front-end application through the smart contract, so that the front-end application can perform a component version rollback operation to complete the version rollback.

9. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: After it is determined that the front-end component update is completed, the update result is visually presented in the form of a pop-up window through the front-end application; wherein the update result includes an update status and an update timestamp.

10. A front-end component updating device, characterized in that: include: An event monitoring module is used to establish a connection between the current blockchain and the front-end application based on a preset component interface through an adaptation layer that matches the current blockchain, and to monitor real-time events of the current blockchain using a deployed smart contract; An update trigger module, for sending the latest component information to the front-end application through the smart contract after determining that the real-time event meets the preset front-end component update condition, so as to trigger the front-end application to send an update request carrying the latest component information; An update file acquisition module, configured to acquire, according to the update request, a component file to be updated corresponding to the latest component information from a preset decentralized storage network, and send the component file to be updated to the front-end application, so that the front-end application updates the front-end component according to the component file to be updated; The update execution module is used to monitor the update of the front-end component. After determining that the update of the front-end component is completed and meets the preset operating conditions, the update execution module receives the record update instruction carrying the current component running version information through the smart contract, so that the smart contract can update the recorded component running version information to complete the update of the front-end component.

Images