HMM-Based Blockchain Visual Automatic Deployment System

Abstract

The traditional blockchain deployment process is too complicated and has high technical requirements for blockchain deployers. Deploying a blockchain requires building a complex software-dependent environment, being able to use Linux commands for cumbersome parameter configurations, as well as the need to consider whether the hardware meets the requirements for running a blockchain. To address these current challenges in blockchain deployment both domestically and internationally, a web-based automatic deployment system with an interactive front-end and back-end has been developed. This system streamlines the process by automatically configuring and deploying blockchains while providing deployers with a graphical interface to monitor the entire deployment procedure. Meanwhile, in order to improve the efficiency of blockchain deployment, a Hidden Markov Model has been designed for blockchain deployment, which can predict the best deployment method for blockchain deployment under the current software environment. As one of the excellent blockchain platforms in China, Chainmaker has the outstanding features of independent control, flexible assembly, software and hardware integration, open source, and openness. The system takes Chainmaker as an experimental object and after a lot of tests, it can easily build a blockchain network on the server.

1. Introduction

Blockchain is a decentralized shared ledger that combines blocks of data into a specific data structure in a chronological chain and is cryptographically guaranteed to be tamper-proof and unforgeable; in layman’s terms, blockchain is a distributed ledger [1].

Blockchain technology has achieved remarkable development results globally and has a wide range of application prospects in many fields, including digital economy [2], healthcare [3], Internet of Things (IoT) [4], etc. With the continuous development and improvement of technology, blockchain is expected to play a greater role in the future and promote the digitalization and intelligentization of the global economy [5].

In order to respond to the differentiated needs of blockchains in different application scenarios, it becomes critical to deploy a customizable blockchain [6]. There are differences in the customizable blockchain used in different industries, and it is impossible to achieve uniform deployment across industries, so it needs to be adjusted in real time according to the scenarios during deployment. Currently, in the actual deployment process of customizable blockchain represented by Chainmaker, there are many blockchain deployment processes and complex blockchain configuration parameters [7].

For instance, the deployment process in blockchain involves several steps such as preparing the deployment environment, downloading and compiling the source code, generating the configuration file, creating an installation package, initiating a node cluster, and deploying smart contracts. The parameters required for blockchain deployment encompass selecting the compilation method of the blockchain source code, choosing an appropriate transmission method for the compiled Executable and Linkable Format (ELF) file based on network conditions, determining the consensus algorithm to be employed in the blockchain system, opting for a specific type of encrypted hash function, configuring the number of nodes within a cluster, and specifying block size and height within the blockchain.

In the field of blockchain deployment tools and frameworks, there are some notable contributions. Zheng et al. [8] developed NutBaaS, a Blockchain-as-a-Service platform that provides various services such as network deployment, system monitoring, and smart contract analysis and testing. The approach aims to ensure the continuous deployment of containerized blockchain distributed applications. In terms of using smart contracts, Merlec et al. [9] proposed a block-based visual programming framework that enables non-expert programmers and learners to build syntactically correct smart contracts without writing code. Moreover, Górski et al.’s [10] proposed approach aims to ensure the continuous deployment of containerized blockchain distributed applications through the integration of delivery and deployment components using Git distributed version control.

In the specific area of automated blockchain deployment, Mathwale [11] proposed an automated blockchain deployment approach that involves integrating multiple scripts. Users are required to enter a small number of Linux commands in the system’s shell interface to complete the blockchain deployment. However, this approach has limitations as it still requires manual command entry and does not achieve complete automation of blockchain deployment. Furthermore, Zikos et al. [12] developed a system for automated blockchain deployment that lacks hardware detection, detection of dependent software, and automated installation of dependent software during blockchain deployment. Additionally, it is unable to deploy smart contracts through an automated system.

Currently, the industry’s research on automated deployment of blockchain is still in its early stages. In response to this, we have developed and implemented a web-based system for automating the deployment of blockchain visualization based on the Hidden Markov Model (HMM). This system allows users to predict the best deployment method for blockchain without needing to possess an in-depth understanding of complex technical details. Users can simply operate through the graphical interface of the system to complete deployment of the blockchain.

The client interface of this web-system is built on the Vue.js framework, a popular JavaScript framework for building user interfaces. On the other hand, the server side is based on Gin framework, a lightweight and efficient web framework for the Go programming language. The interaction between client and server involves sending and receiving json files [13]. Additionally, during the deployment process, more blockchain tools can be integrated into the web page, which sets it apart from traditional deployment methods.

The other contents of this paper are as follows: Section 1 presents the requirements analysis of the blockchain visualization automatic deployment system, encompassing both system requirements and functional requirements. Section 2 discusses the key technologies and principles of the blockchain automated deployment system. It primarily focuses on explaining the principles of HMM and multi-machine deployment, as well as various principles related to the front-end and back-end. Section 3 elaborates on the design of the blockchain automated deployment system, including the system’s workflow design and the design of interactions between the front-end and back-end. Section 4 demonstrates how to use the blockchain automated deployment system and showcases the process. Section 5 provides a conclusion, summarizing the paper and highlighting its limitations as well as discussing the key areas for future work.

2. Needs Analysis

2.1. System Requirements

• Visualization: The system must provide a visual deployment interface for blockchain deployers, replacing the previous command line process on the Linux server terminal. Users will now be able to complete the automatic deployment of blockchain through an intuitive visualization interface.
• System Performance: To enhance the maintainability and scalability of the system, it should be designed with front-end and back-end separation. The front-end should prioritize modularized development and optimal user experience, while the back-end should possess the capability to efficiently process Hypertext Transfer Protocol (HTTP) requests and offer well-defined Application Programming Interface (API) interfaces.

2.2. Functional Requirements

The HMM-based blockchain visual automatic deployment system mainly includes the following features:

(1) Node Management. Users can choose single or multi-computer deployment and fill in the node information of the blockchain to be deployed.

(2) Number of nodes selection. When performing a multi-computer deployment, the user can select the final number of nodes to be deployed.

(3) Hardware Scan. View hardware information for all nodes to be deployed.

(4) Fill in the deployment information. Configure the final generated blockchain.

(5) Software Scanning. View the software dependency environment information of all nodes to be deployed and, for those that do not comply, automatically resolve software dependency issues present in the deployed blockchain.

(6) Install the blockchain. Complete the installation of the blockchain.

After entering the web interface of the blockchain automated deployment system, the user can follow the page prompts to operate, fill in relevant information and test the deployment environment, and finally realize the deployment of blockchain. The functional design diagram of the blockchain visualization automation deployment system based on HMM is shown in Figure 1.

3. Key Technologies and Principles of Blockchain Automation Deployment System

3.1. Predicting the Optimal Deployment of Blockchain through HMM

The HMM is an extension of the Markov model that incorporates the concept of unobservable states, allowing the model to infer underlying state transfer processes from observable events. It is a statistical model used to study time series data and describes the relationship between two stochastic processes: one between unobservable states and the other between observations. The HMM is suitable for modeling stochastic processes in which the states are not visible but have corresponding observations [14].

The Chainmaker, as a representative of customizable blockchain, supports multiple deployment methods. By introducing the Hidden Markov Model, we are able to predict the best deployment method suitable for the current node based on its software dependency environment. This approach can significantly improve blockchain deployment efficiency and further optimize system performance.

In the actual deployment scenario of blockchain, the different software-dependent environments on the currently deployed node belong to the observed states, and the different deployment methods adopted are the hidden states. By combining the above hidden and observed states, a Hidden Markov Model is formed. The HMM in the blockchain deployment process is shown in Figure 2.

A Hidden Markov Model is a probabilistic model used to represent a doubly stochastic process [14]. In this context, Q represents the set of all deployment methods (i.e., hidden states), where $Q=q_1,q_2,q_3$, with $q_1$ denoting script-based deployment, $q_2$ denoting docker deployment, and $q_3$ denoting binary deployment.

We assume that V is the set of software dependency environments (i.e., the set of observed states) that can be deployed by the blockchain on different devices. Specifically, the blockchain deployment requires three software dependencies: Gcc, Glibc, and Docker. Since each of these three dependencies can either be satisfied or not satisfied, the combination of their states results in $2^3=8$ possible observed states, denoted as $v_1$ to $v_8$. For example, $v_1$ could represent the state where all three dependencies (Gcc, Glibc, and Docker) are satisfied, $v_2$ could represent the state where only Gcc is satisfied while Glibc and Docker are not, and so on. These eight observed states capture all the possible software dependency configurations that the blockchain deployment may encounter. For a sequence of length T, I corresponds to a sequence of states and O corresponds to a sequence of observations, i.e., $I=i_1,i_2,\dots ,i_T,O=o_1,o_2,\dots ,o_T$; any hidden states $i_t\in Q$; and any observed states $o_t\in V$. The state transfer probability matrix A is

$$a_{ij}=P\left({\mathbf{i}}_{t+1}=q_j\right)$$

(1)

of which

$$a_{ij}=P\left(i_{t+1}=q_j|i_t=q_i\right),i=1,2,3;j=1,2,3$$

(2)

denotes the probability of transferring to the hidden state $q_j$ at moment $t+1$ given that the system is in the hidden state $q_i$ at moment t.

The observed states probability matrix B is

$$B=\left(b_j\left(k\right)\right)$$

(3)

Among them,

$$b_j\left(k\right)=P\left(o_t=v_k\mid i_t=q_j\right),k=1,\dots ,8;j=1,2,3$$

(4)

denotes the probability of generating an observed state $v_k$ given that the system is in the hidden state $q_j$ at moment t.

The initial probability matrix of the hidden states $\mathsf{\Pi }$ is

$$\mathsf{\Pi }=\left(\pi \right(\mathbf{i}\left)\right)$$

(5)

of which

$$\pi \left(\mathbf{i}\right)=P(i_1=q_i),i=1,2,3$$

(6)

denotes the probability of the initial state being $q_i$ at moment $t=i$ in the hidden states.

Thus, a Hidden Markov Model can have a ternary representation:

$$\lambda =(A,B,\prod )$$

(7)

The Baum–Welch algorithm is used to determine the specific parameters of the Hidden Markov Model on the basis of the blockchain deployment dataset. The essence of the algorithm is to use the principle of EM (Maximum Expectation Algorithm); when the trained model is closer to the parameter values of the actual model, the great log-likelihood value will be larger, and the method iterates the training until the parameter values of the HMM converge and the optimal parameters are obtained [15]. The specific parameter solving process is as follows:

(1) Parameter initialization. In order to enhance the efficiency of the EM algorithm, the initial state probability vector and the state transfer matrix A can be obtained by using the average value of the dataset, which is ${\lambda }_0$.

(2) EM step. E-step: calculate the expected values of the hidden variables based on the initial values of the parameters or the values of the parameters obtained in the previous iteration; M-step: reevaluate the model parameters from the expected values obtained in the E-step to obtain $\widehat{\lambda }$.

The initial probability matrix expression is

$${\widehat{\pi }}_{\mathrm{i}}=P(qt=i|O,\lambda )$$

(8)

This formula calculates the probability of the hidden state being $q_i$ at the initial moment t, given the observations O and the Hidden Markov Model parameters $\lambda$.

The transfer matrix probability expression is

$${\widehat{a}}_{ij}=\frac{\sum {t=1}^{T-1}P(q_t=i,q_{t+1}=j|O,\lambda )}{{\sum }_{t=1}^{T-1}P(q_t=i|O,\lambda )}$$

(9)

This formula computes the probability of transitioning from state $q_i$ to state $q_j$, given the observations O and the Hidden Markov Model parameters $\lambda$. It involves summing the conditional probabilities of being in state $q_i$ at time t and transitioning to state $q_j$ at time $t+1$, divided by the sum of the conditional probabilities of being in state $q_i$ at time t.

The expression for the observation probability matrix is

$${\widehat{b}}_{\overline{y}}=\frac{to\left(t\right)-k,l\le t\le \mathbf{T}}{\sum {t=1}^{T-1}P(q_t=i|O,\lambda )}$$

(10)

This formula calculates the probability of observing the sequence of observations denoted by $\overline{y}$ given the Hidden Markov Model parameters $\lambda$. It involves dividing the occurrence count of the sequence $to\left(t\right)-k,l\le t\le \mathbf{T}$ by the sum of the conditional probabilities of being in state $q_i$ at time t.

(3) Loop. Repeat the previous step until convergence, at which point the EM algorithm ends after saving the model parameters.

After building the HMM, we can solve for the maximum probability of the different deployment methods corresponding to the observation environment that the current software relies on to be hidden, so as to ensure that the deployment method as the hidden state is globally optimal.

3.2. Blockchain Multi-Machine Deployment Principles

When it comes to blockchain deployment, single-machine deployment is the simplest way to go. It is usually used for small or personal projects where all nodes and blockchain data are stored on a single machine. Multi-machine deployment has multiple nodes on a chain; even if one of the nodes is down or attacked, it can ensure that the other nodes on the chain are able to operate normally and verify the transactions, and multi-machine deployment has the characteristics of increasing the security of the system and improving the system’s processing power and throughput [16]. The principle of multi-machine deployment of blockchain is shown in Figure 3.

As can be seen from Figure 3, the compilation node is in the middle of the most compilation node according to the user’s choice of configuration information; the compilation and generation of blockchain; the final generation of the blockchain binary file and the relevant certificate file to the other deployment nodes, where we can use scp, ftp, http, etc.; and, ultimately, generating the decentralized blockchain network structure, have been achieved. At this stage, the blockchain becomes capable of sending and verifying transactions.

3.3. Blockchain Multi-Machine Deployment Principles

P2P (Peer-to-Peer) ports and RPC (Remote Procedure Call) ports are both key communication interfaces in blockchain systems; therefore, they must also be set up during blockchain deployment. They provide an efficient and reliable communication mechanism for blockchain applications and offer users rich functionality and flexibility.

P2P ports are used to enable interconnections between blockchain nodes, including multiple nodes within an institution and nodes between different institutions. If other nodes are located outside the organization, the connection needs to listen to the public address or intranet and forward the network through a gateway that connects to the public network (e.g., nginx) [17].

RPC is a set of protocols and interfaces for interaction between clients and the blockchain system. Through the RPC interface, users can query blockchain-related information (e.g., block height, blocks, and node connections) and send transactions. RPC provides a convenient way to communicate and operate with the blockchain system, providing users with a flexible and customizable interface [18].

3.4. Vue Data-Driven Views

Vue.js is a popular JavaScript front-end framework for building interactive web interfaces. It is based on the MVVM (Model-View-ViewModel) architectural pattern, which provides a structured, scalable, and responsive way to develop user interfaces [19]. The schematic sketch of MVVM is shown in Figure 4.

In the above Figure 4, the View Model layer is responsible for observing the data changes in the Model layer and updating the content of the View layer in real time. At the same time, it also listens for Document Object Model (DOM) changes in the View layer and notifies the Model layer of the corresponding changes in the data [20]. The MVVM pattern has the features of separating the view layer and the data layer, reducing the coupling and suggesting reusability. Therefore, it can meet the design of the blockchain visualization automation deployment system.

3.5. Gin Framework Based on Go Language

Since Go language has high performance, concurrency, and supports cross-platform compilation, blockchain development at home and abroad uses Go language. In order to facilitate the subsequent practitioners to carry out secondary development on the blockchain deployment system according to the actual occasion, in this system, we use a high-performance web framework based on Go language. Gin framework is a Go language framework for building high-performance web applications. It is based on the concepts of HTTP routing and middleware, and provides an easy-to-use API and powerful performance. radix trees are used in the Gin framework, which makes it possible to efficiently handle a large number of concurrent http requests, and can be used in high-load environments [21].

4. Design of Automated Blockchain Deployment System

4.1. Process Design

In this section, the operation of completing blockchain deployment after the user opens the browser is designed. When the user starts the front-end and back-end locally, they open the browser and enter the local IP and port number to access the visualized blockchain deployment system.

The first interface that the user will see is the quick guide interface; the quick guide can help the user understand the process steps of using the system. After reading the quick guide, the user proceeds to the node management interface. Here, the user can choose whether to carry out single-computer deployment or multi-computer deployment, and fill in the corresponding node information. If the user selects to carry out single-computer deployment, the user will skip the node management interface and directly enter the hardware detection interface; if it is a multi-computer deployment, the user will first enter the node selection interface to choose the final deployment node and then enter the hardware detection interface after the selection is completed. Once the hardware meets the requirements of deploying blockchain based on the result of the hardware detection, the user will enter the interface for filling in the deployment information; if the hardware detection does not meet the requirements, the deployment process will be terminated. After filling in the deployment information, the user enters the software detection interface, and if the software does not meet the requirements for the blockchain deployment environment, the user can install the blockchain operating environment with just one click. Finally, the user comes to the blockchain deployment interface, where they complete the final deployment. The automated deployment flowchart is shown in Figure 5.

4.2. Front-End and Back-End Interaction Design

4.2.1. Interface Design

In the HMM-based blockchain visual automatic deployment system, a front-end and back-end separation architecture is utilized. This architecture offers significant advantages in terms of improving the system’s maintainability and scalability [22]. In this architecture, the front-end and back-end communicate through HTTP interfaces to facilitate data transfer and operational functionalities. To handle these requests, we have chosen the Axios tool.

Axios is a popular JavaScript library used for making HTTP requests in browsers and Node.js. It provides a clean and powerful API, simplifying data interaction in front-end applications. With Axios, developers can easily send HTTP requests, handle responses, manage errors, and more [23]. It supports multiple request methods, including GET and POST, and offers features such as interceptors, request cancellation, and automatic data conversion.

In our system, we utilize GET and POST requests based on different functions and scenarios. GET requests are primarily employed for fetching data and performing query operations, while POST requests are used for data submission and modification operations. The interface design table for the HMM-based blockchain visualization automation deployment system is shown in

Table 1. The interface design table for the HMM-based blockchain visualization automation deployment system.

Interface Address	Interface Type	Interface Description
http://localhost:8080/nodeDetail, accessed on 1 June 2024	POST	This interface is used to submit information about all nodes to be deployed
http://localhost:8080/nodeSelect, accessed on 1 June 2024	POST	This interface is used to submit the final selection of nodes for a multicomputer deployment
http://localhost:8080/hardwareScan, accessed on 1 June 2024	GET	This interface is used to obtain hardware information about the final deployed node
http://localhost:8080/softScan, accessed on 1 June 2024	GET	This interface is used to obtain software information about the final deployed node
http://localhost:8080/blockMessage, accessed on 1 June 2024	POST	This interface is used to submit configuration information for the blockchain to be generated
http://localhost:8080/logRealtime, accessed on 1 June 2024	GET	This interface is used to obtain real-time log information about the deployed blockchain

.

4.2.2. Front-End and Back-End Interaction Processes

In a system based on Hidden Markov Model front-end and back-end separation, the front-end and back-end interaction is one of the core processes of the project. In this system, the front-end collects user actions and inputs through the user interface, such as form submission, click events, etc. These actions trigger the front-end to send HTTP requests to the back-end server. After receiving the request from the front-end, the back-end server calls the corresponding back-end processing function or service according to the path and parameters of the request [24]. In the back-end processing function, data validation, processing, and logic execution can be performed.

When processing is complete, the results are encapsulated into an HTTP response that is returned to the front-end. The response usually contains a status code, header information, and a response body. The status code indicates the processing result of the request, the header information can contain some metadata, and the response body contains specific data or error messages. After receiving the response from the front-end, the front-end will process the response according to the status code and response body, for example, it can update the User Interface (UI) to display the response data or perform other operations. The interaction process between the front-end and the back-end in this system is shown in Figure 6.

From the above Figure 6, we can see the interaction principle between the client and the server of the blockchain visualization automation deployment system based on the HMM, and the general flow is as follows: the user first fills in the IP address of the node to be deployed, and the user name and the password on the client side; then, after filling in, they send the characters in json format through the Axios request to the corresponding POST interface on the server side; the server side then carries out the saving of the user’s information. Next, the user selects the node where the blockchain is actually deployed, and the same POST request is sent to the server. After that, the user clicks on “Hardware Scan” and “Software Scan” to check whether these nodes meet the requirements for deploying Chainmaker. In the software scanning interface, it can assist the user in installing the necessary dependencies for the blockchain with just one click.

After completing the above operation, the user will enter the interface to fill in the specific blockchain configuration information, where the user can choose the deployment method (script-based deployment, docker deployment, binary deployment), consensus type, identity mode, hash type, block height, block size, and other information. Finally, the user reaches the deployment page of the blockchain; after clicking Install Blockchain, the deployment information of the blockchain will be displayed on the page.

4.3. Page Design of the Visualization System

HMM-based blockchain visual automatic deployment system uses the Vue.js framework to build single page applications. In this system, Vue.js components are the basic building blocks for encapsulating reusable HTML elements and logic. Each module acts as an independent component responsible for managing its own view and behavior [25].

These components are nested and combined to form a complex page structure. The architectural diagram of the overall front-end is shown in Figure 7.

It can be seen in the above Figure 7 that as the entry point to the system and the file packaging entry point, main.js recursively traverses the dependency files and builds the dependency graph of the whole application. It transforms files, optimizes resources, etc. through loaders and plugins. It can be configured differently according to the needs of the development environment and production environment. In the development environment, Webpack provides a development server and hot update module to speed up development. In the production environment, Webpack can perform more stringent code optimization and compression to generate final files suitable for deployment.

In order to build a beautiful and easy-to-use interface, Element UI is chosen as a Vue-based UI component library. Element UI has a rich component library, simple and beautiful design, responsive layout, and is easy to use and customize. It can help you quickly build an aesthetically pleasing interface for displaying blockchain data and statistics, thus enhancing user experience and system usability. In addition, Element UI’s responsive layout ensures that the system can be displayed and interacted with well on different devices.

In this system, Vuex is also used as the official state management pattern and library of Vue.js. Vuex provides a predictable state management mechanism through the core concepts of State, Mutation, Action, Getter, and Module. It can centralize the management and sharing of data, simplify data transfer between components, improve development efficiency, and support complex application scenarios. In large-scale Vue applications, the use of Vuex can improve team collaboration and code maintenance convenience [26].

By combining Vue, Element UI, Vue Router, and Vuex, it is easy to create a powerful, beautiful, easy-to maintain, Hidden Markov Model-based blockchain visualization automation deployment system with predictable state management. Vue provides flexible componentized development, Element UI provides rich UI components and layout support, and Vuex makes state management more convenient. This combination can meet the needs of the system and provide users with a good experience.

5. Blockchain Automated Deployment System Realization Process

We utilize Chainmaker for the practical deployment of the blockchain. The specific reasons for choosing Chainmaker were explained earlier in the paper. The hardware configuration included an Intel i7-12700H CPU, 8G RAM, and Ubuntu 22.10 as the operating system.

After starting the client and server locally, when the user enters the IP address and port number in the browser, they will be directed to the quick guide interface of the blockchain automation deployment system, as shown in Figure 8.

5.1. Node Management

The node management interface is shown in Figure 9. In the first drop-down box, the user can choose whether to perform a standalone deployment or a multi-computer deployment. For a standalone deployment, the user only needs to fill in the information of a single node. In contrast, for a multi-computer deployment, the user needs to provide information for multiple nodes. The required information includes the IP address, username, password, P2P port, and RPC port number.

When the above Figure 9 is filled with each node’s information, you can choose to delete or copy the node information, and you can also re-add the node information, where the key code is as follows:

	// This is a JavaScript code snippet
	      handleDelete(item, index) {
		let data = {...item};
		this.model.multiInfo && this.model.multiInfo.splice(index,1)
	},
	handleCopy(item,index){
		let data = {...item};
		this.model.multiInfo && this.model.multiInfo.splice(index,0,data)
	},
	handleAdd(){
		let item = this.getFormItem();
		this.model.multiInfo &&  this.model.multiInfo.length && this.model.multiInfo.push(item)
	},

In the above code, handleDelete method means delete node, where multiInfo is the form information, which can directly change the array through the splice method, and triggers the view update. Accordingly, handleCopy and handleAdd correspond to copy and add nodes.

5.2. Node Selection

When the user is in the node management, after filling in all the information of the deployed nodes, he/she enters the node selection page in the following figure. The user clicks on the drop-down box, and the user can select the nodes that were filled in the node management, where the selection of the final deployment of the blockchain is carried out, as shown in Figure 10.

5.3. Environmental Testing

The hardware and software scanning results are shown in Figure 11. The system will analyze the scanned information to determine if it meets the deployment requirements of the blockchain. If the requirements are met, specific information will be displayed. However, if the requirements are not met, the system will highlight the information in red font. Additionally, after displaying the scan results, the system will inform the user whether the current software or hardware environment complies with the blockchain deployment requirements.

Furthermore, in the software scanning interface, there is a button available for updating software dependencies. This button can be used to automatically resolve any software dependency issues that may arise during the execution of the blockchain.

5.4. Filling in Deployment Information

The interface for filling in the deployment information is shown in Figure 12. Here, the user can choose the transmission method for multi-machine deployment of the blockchain, as well as the type of consensus contract and the type of hash encryption; they can also choose the information of the blockchain such as the number of blockchains, the height of the outgoing block, and the size of the outgoing block.

5.5. Deployment Results

The results of the blockchain deployment can be seen in the browser page, where the nodes can be seen starting up and the ports are checked to see if they are listening. After the previous preparations, we have implemented a four-node automated multi-computer deployment of the blockchain, as shown in Figure 13.

6. Conclusions

This paper describes in detail the construction process of an HMM-based blockchain visualization automatic deployment system. The system adopts the design of front-end and back-end separation; the front-end adopts the Vue.js framework, the back-end adopts the Gin framework, and the front-end and back-end adopt the HTTP protocol for communication. Furthermore, the paper also elaborates on the design principles and implementation process of the front-end and back-end components. In the deployment process, the paper explains the mathematical principles of the HMM that is constructed to recommend appropriate blockchain deployment methods for users, and the blockchain configuration process is completed with a visual graphical interface. In addition, the system automatically detects whether the hardware and software dependencies of the deployed nodes meet the requirements; if the software dependencies do not meet the requirements, it will automatically improve the environment required for the blockchain. Therefore, the system helps users quickly build blockchain networks through the visual graphical interface. Moreover, it is worth mentioning that the practical deployment of a four-node automated multi-computer blockchain using our system only took 6 min, While it took approximately 23 min for randomly selected individuals with some computer background but no prior experience in blockchain to manually deploy a four-node, multi-computer blockchain. Hence, the automated deployment system can save approximately four times the time required compared to manual deployment and contributes to the development of blockchain from the perspective of blockchain deployment.

One area that deserves further research in the system is enhancing its security measures. Specifically, when transmitting binary ELF files during the compilation process of the blockchain, it is possible to incorporate various secure transmission protocols. These aspects will be the focus of our future work.