A design method and system for a secure microserver for blockchain

Abstract

The present invention discloses a design method for a secure micro-server for blockchain, wherein node A obtains a local file and converts it into WebRTC stream data, and sends a request to node B to submit the file; node B extracts and circulates a local channel pool allocation table; and processes the request of node A. Node B receives or discards the data after a verification process, and if data is received, it is converted into a file and the integrity of the file is verified, and the file is saved after the verification passes. The present invention also proposes a system for a secure micro-server for blockchain, comprising a channel pool manager, a file manager, and an interface manager, thereby solving the problem that a mobile device cannot independently serve as a service node to become a blockchain node, and realizing the provision of server services on mobile devices.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a design method and system for a secure micro server for blockchain. Background Art

[0002] Blockchain is an important infrastructure in the future credit era. Most of people's work and life will be completed through blockchain, and people's participation in blockchain will be mainly through mobile devices. Due to the decentralized nature of blockchain, mobile terminals are required to directly participate in the network as a consensus node of blockchain. Under this background, providing point-to-point services on mobile devices will become an inevitable trend. However, mobile devices are not traditional servers. Traditional servers have a complete set of equipment such as firewalls, controllable gateways, load balancing, disk arrays and other equipment to ensure the safe operation of servers. In addition, the entire set of software used on servers cannot be run on mobile phones. In the traditional IT architecture design, it is almost unimaginable to provide server services on mobile devices such as mobile phones. However, the blockchain requires everyone to participate in becoming a consensus node, and mobile devices must provide corresponding capabilities to become consensus nodes. Otherwise, it will not be possible to achieve a truly decentralized consensus node, and it will be necessary to introduce the ability of third-party nodes to carry servers. If this problem cannot be effectively solved, then blockchain will not be able to become a truly credible blockchain, and the credit era will hardly come. So, how to provide server services on mobile devices without introducing a third party and ensure a certain level of security has become an urgent problem to be solved. Summary of the invention

[0003] The present invention aims to propose a design method and system for a secure micro-server for blockchain, and designs the concept of "micro-server". The core idea is to define two service channels on a blockchain network based on the WebRTC protocol. The file service mainly converts the file into a WebRTC data stream for transmission, and then restores it to a file at the target node. The data service is mainly used to provide structured data interaction. The combination of the two channels can realize the server services under most traditional IT architectures, thereby providing server services on mobile devices without introducing third-party nodes, while ensuring a certain security capability.

[0004] A design method for a secure microserver for blockchain, the method comprising:

[0005] S1. Node A converts the local file content into WebRTC stream data, obtains the service interface of node B and sends a request to submit the file;

[0006] S2, Node B extracts and circulates the local channel pool allocation table;

[0007] S3. Process the request of node A. Node A starts to send WebRTC stream data to node B. Node B receives the WebRTC stream data and determines the legality of the data. If the data is illegal, the data is discarded. If the data is legal, the WebRTC stream data reception is completed.

[0008] Furthermore, after the B node completes receiving the WebRTC stream data in step S3, the WebRTC stream data is converted into a file and the file integrity is verified. If the verification fails, the file is discarded; if the verification passes, the file is stored in a designated directory.

[0009] Further, the process of circulating the channel pool allocation table described in step S2 includes:

[0010] S21, extract the allocation target and determine whether it is node A;

[0011] S22. If it is not node A, determine whether the channel is sufficient. If not, create a new channel and put the A node request into the channel queue. If it is node A, obtain the channel and put the A node request into it.

[0012] The present invention further extends the design method of the secure micro server for blockchain and proposes a design system for the secure micro server for blockchain, the system comprising:

[0013] Channel Pool Manager: used to manage the current channel pool, open and close channels, and filter channel contents;

[0014] File manager: used to manage local files and draw the range of files that can be accessed externally. When these files are needed externally, they are extracted and converted into WebRTC data streams. It also provides file receiving services and restores data streams submitted by others into files.

[0015] Interface Manager: It is used to provide interface services for data interaction between two nodes and provide different services according to different instructions.

[0016] The system obtains the local file at node A through the file manager and converts the file content into WebRTC stream data. The interface manager sends a request to submit the file to node B. The channel pool manager extracts and circulates the local channel pool allocation table at node B. The interface manager processes the request of node A, receives the WebRTC stream data or discards the data after verification. If the reception is completed, the file manager converts the WebRTC stream data into a file and verifies the integrity of the file. After the verification is passed, it is saved. The channel pool manager, the file manager and the interface manager are cross-meshed and can access data from each other.

[0017] Furthermore, the channel pool manager includes:

[0018] Channel gate module: It is used as a checkpoint in the process of channel content data interaction to perform security checks on data. When a new security module is added, it will also be connected here to work together;

[0019] Channel concurrency module: used to manage established channels and schedule resource usage during the operation of these channels;

[0020] Channel startup module: used to start a new channel, generally used to cooperate with the work of the channel concurrent module;

[0021] Channel destruction module: used to destroy a running channel;

[0022] Session queuing module: used to manage resource contention issues between users using the same channel.

[0023] Furthermore, the file manager includes:

[0024] File directory module: used to manage the local file directory list and provide the corresponding directory list when other modules need it;

[0025] File conversion module: used to read files into binary and convert them into corresponding data streams according to the network protocol they are based on;

[0026] File restoration module: used to convert the received data stream into the corresponding file and put the file into the corresponding directory.

[0027] Further, the interface manager includes:

[0028] Interface permission module: used to manage the interfaces used when the current channel is exposed to the outside world, as well as the access permissions of these interfaces;

[0029] Data submission module: used to send data requests to other nodes as a client;

[0030] Interface service module: used as a server to provide services to other nodes, respond to commands sent by other nodes, and receive data sent by other nodes.

[0031] Compared with the prior art, the present invention has the following advantages:

[0032] (1) The present invention focuses on redefining a server service model on a blockchain network based on the WebRTC protocol, and adopting the WebRTC protocol means having the original basic security capabilities to a certain extent;

[0033] (2) The present invention defines two service channels, one for file service and the other for data service. The two channels can be combined to realize Web services under the WebRTC protocol and run on mobile devices. In addition to providing Web services, the present invention can also provide most server services under other traditional IT architectures, thereby providing server services on mobile devices without introducing third-party nodes.

[0034] (3) The certain security capabilities of the present invention are basic security capabilities without adding any other security components. If components such as virtual firewalls, virtual gateways, and virtual load balancing are added to the two channels, security and reliability can be further improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a flow chart of the design method of the secure micro server for blockchain mentioned in the present invention;

[0036] Figure 2 It is a flowchart of the conversion and integrity verification process of WebRTC stream data mentioned in the present invention;

[0037] Figure 3 It is a schematic flow chart of the circulation channel pool allocation table process mentioned in the present invention;

[0038] Figure 4 It is a schematic diagram of the composition of the system of the secure micro server for blockchain mentioned in the present invention;

[0039] Figure 5 It is a schematic diagram of the composition of the channel pool manager mentioned in the present invention;

[0040] Figure 6 It is a schematic diagram of the composition of the file manager mentioned in the present invention;

[0041] Figure 7 It is a schematic diagram of the composition of the interface manager mentioned in the present invention;

[0042] Among them: 100 channel pool manager; 200 file manager; 300 interface manager; 400 transaction manager; 101 channel gate module; 102 channel concurrency module; 103 channel startup module; 104 channel destruction module; 105 session queue module; 201 file directory module; 202 file transfer module; 203 file restoration module; 301 interface permission module; 302 data submission module; 303 interface service module DETAILED DESCRIPTION

[0043] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0044] Since the blockchain requires everyone to participate in becoming a consensus node, and most people participate in the blockchain through mobile devices, but mobile devices are not traditional servers and do not have a series of devices to ensure their safe operation. In addition, the entire set of software used on the server to run services cannot be run on mobile phones, which inevitably requires the introduction of third-party nodes to carry the server capabilities. However, the introduction of third parties will bring some problems. Therefore, in order to provide server services on mobile devices without introducing third parties while ensuring certain security capabilities, the present invention proposes a design method for a secure micro server for blockchain. In order to implement this method, the following technical steps are specifically included:

[0045] This method includes two main links. The first is that the sending end node A submits a file to the receiving end node B. Node A obtains the file and converts it into WebRTC stream data, and sends a request to node B to submit the file. The second is that the receiving end node B receives the file, and node B extracts and circulates the local channel pool allocation table. After agreeing to the request of node A, it receives the WebRTC stream data or discards the data, and converts the received data into a file. The specific process of the two links is shown in the following steps. Figure 1 As shown:

[0046] S1. Node A converts the local file content into WebRTC stream data, obtains the service interface of node B and sends a request to submit the file;

[0047] S2, Node B extracts and circulates the local channel pool allocation table;

[0048] S3. Process the request of node A. Node A starts to send WebRTC stream data to node B. Node B receives the WebRTC stream data and determines the legality of the data. If the data is illegal, the data is discarded. If the data is legal, the WebRTC stream data reception is completed.

[0049] It should be noted that the steps for node A to obtain a file from node B are similar. For ordinary service interactions, the steps are less than the file acquisition steps, so the steps for writing a file here can cover all the steps.

[0050] like Figure 2 As shown, in this embodiment, after the B node completes the reception of the WebRTC stream data in step S3, the WebRTC stream data is converted into a file and the file integrity is verified. If the verification fails, the file is discarded; if the verification passes, the file is stored in a specified directory.

[0051] It should be noted that Figure 1 and Figure 2 Two service channels are shown, one is data service and the other is file service. Figure 1 What is displayed is the data service, which is mainly used to provide structured data interaction, including responses to some specific instructions. One node provides data sending service, and the other provides data receiving service. The data can be some control instructions or some business data, which is equivalent to implementing HTTP POST, GET, PUT, and DELETE requests under the traditional IT architecture. Figure 2 What is displayed is the file service, which is mainly used to convert files into WebRTC data streams for transmission, and restore them to files at the target node. This is equivalent to implementing file transfer services such as FTP services and HTTP services under the traditional IT architecture. The receiving end is equipped with a reading and interpretation engine for specific files, which is equivalent to implementing a Web server and web browser under the traditional IT architecture.

[0052] like Figure 3 As shown, in this embodiment, the process of circulating the channel pool allocation table described in step S2 includes:

[0053] S21, extract the allocation target and determine whether it is node A;

[0054] S22. If it is not node A, determine whether the channel is sufficient. If not, create a new channel and put the A node request into the channel queue. If it is node A, obtain the channel and put the A node request into it.

[0055] like Figure 4 As shown, the present invention also proposes a system for a secure micro server for blockchain, and the components and functions of the system are as follows:

[0056] Channel pool manager 100: used to manage the current channel pool. Since each channel startup consumes a certain amount of memory and computing resources, the number of channels on a device will not be increased indefinitely, and a channel will not be allocated to each user. The design here is that multiple users reuse the same set of channels, and the number of channels is determined by the computing power of the device. When multiple users use the same session at the same time, they will be served in a queuing manner. As long as the acceptable waiting time for a single user is within the maximum concurrent carrying capacity of the device, the service can be effectively provided. Assuming that a service for a user takes 10ms and the user's waiting timeout is 5 minutes, then a channel can provide services to 30,000 people at the same time. If the device provides eight channels (8-core mobile phone), it can provide services to 240,000 people, which is equivalent to the service capacity of a large server. When the user waiting time is shortened to 15 seconds, it can still provide services to 12,000 people at the same time, which can cover most business scenario requirements. In the channel pool manager, the opening and destruction of channels and the filtering of channel content are also managed.

[0057] File manager 200: used to manage local files, draw the range of files that can be accessed externally, and extract the files and convert them into WebRTC data streams when the files are needed externally. When the present invention is implemented based on other protocols, it will be converted into different data streams. The type of data stream converted does not affect the implementation of the present invention. In the file server, a service for receiving files is also provided, and the data streams submitted by others are restored into files.

[0058] Interface manager 300: used to provide interface services for data interaction between two nodes. It can send data acquisition instructions to other nodes, receive instructions from other nodes, and provide different services according to different instructions. The specific services provided here are implemented by the upper-level application according to the specific business scenario. In the present invention, only the interface management function is provided here, and the developer can define his own data interaction interface here.

[0059] The specific workflow of the system includes:

[0060] The system obtains the local file at node A through the file manager 200 and converts the file content into WebRTC stream data. The interface manager 300 sends a request to submit the file to node B. The channel pool manager 100 extracts and circulates the local channel pool allocation table at node B. The interface manager 300 processes the request of node A, receives the WebRTC stream data or discards the data after verification. If the reception is completed, the file manager 200 converts the WebRTC stream data into a file and verifies the integrity of the file. After the verification is passed, it is saved. The channel pool manager 100, the file manager 200 and the interface manager 300 are cross-meshed and can access data from each other.

[0061] like Figure 5 As shown, preferably, the channel pool manager 100 includes:

[0062] Channel gate module 101: used as a checkpoint in the process of channel content data interaction, to perform security checks on data. When a new security module is added, it will also be connected here to work together;

[0063] Channel concurrency module 102: used to manage the established channels and schedule the resource usage of these channels during operation. When the maximum carrying capacity is overloaded, some channels will be notified to be destroyed. When the remaining resources are large enough, more channels can be added.

[0064] Channel startup module 103: used to start a new channel, generally used to cooperate with the work of the channel concurrent module;

[0065] Channel destruction module 104: used to destroy a running channel. During the destruction, the data in the channel will be gradually evacuated, and data requests using the channel will be stopped. After the data is evacuated, the channel will be destroyed and the resources used by the notification will be recovered.

[0066] The session queue module 105 is used to manage the resource contention problem among users using the same channel, and to queue up and use the channel in turn according to the principle of first come first served.

[0067] like Figure 6 As shown, preferably, the file manager 200 includes:

[0068] File directory module 201: used to manage the local file directory list and provide the corresponding directory list when other modules need it;

[0069] The file-to-stream module 202 is used to read the file into binary and convert it into a corresponding data stream according to the network protocol on which it is based. In the present invention, it is converted into a WebRTC data stream.

[0070] File restoration module 203: used to convert the received data stream of others into corresponding files and put the files into corresponding directories.

[0071] like Figure 7 As shown, preferably, the interface manager 300 includes:

[0072] Interface permission module 301: used to manage the interfaces used when the current channel is exposed to the outside, as well as the access rights of these interfaces. The permissions here refer to permissions at the data level, such as whether to add, delete, and modify specified data. When an application needs to restrict permissions for specific services, it is specified and provided by the upper-layer application. For example, whether a chat record can be saved is a business-type data permission provided by the upper-layer application, but the use of a data table based on the chat record is a data permission, which is defined in the interface permission module;

[0073] Data submission module 302: used to send data requests to other nodes as a client. This data request can be a query command or a piece of its own data;

[0074] Interface service module 303: used to provide services to other nodes as a server, respond to commands sent by other nodes, and receive data sent by other nodes.

[0075] Compared with the existing way of mobile devices participating in the blockchain, the present invention designs the concept of "micro server". Without introducing third-party nodes, the blockchain network based on the WebRTC protocol redefines a set of server service models, thereby solving the problem that mobile devices cannot independently serve as service nodes and become blockchain nodes. It realizes the provision of server services on mobile devices and can also ensure a certain security capability.

[0076] The above description is only a preferred embodiment of the present invention and does not limit the technical scope of the present invention. Therefore, any changes or modifications made according to the claims and description of the present invention should fall within the scope of the patent of the present invention.

Claims

1. A design method for a secure microserver for blockchain, characterized in that: The method comprises: S1. Node A converts the local file content into WebRTC stream data, obtains the service interface of node B and sends a request to submit the file; S2, Node B extracts and circulates the local channel pool allocation table; The process of circulating the local channel pool allocation table described in step S2 includes: S21, extract the allocation target and determine whether it is node A; S22. If it is not node A, determine whether the channel is sufficient. If not, create a new channel and put the request of node A into the queue of the new channel. If it is node A, obtain the channel and put the request of node A into the queue of the new channel. S3, processing the request of node A, node A starts to send WebRTC stream data to node B, node B receives the WebRTC stream data and determines the legality of the data, if the data is illegal, the data is discarded, if the data is legal, the WebRTC stream data is received; The system for implementing the above method comprises: Channel Pool Manager: used to manage the current channel pool, open and close channels, and filter channel contents; File manager: used to manage local files and draw the range of files that can be accessed externally. When these files are needed externally, they are extracted and converted into WebRTC data streams. It also provides file receiving services and restores data streams submitted by others into files. Interface Manager: used to provide interface services for data interaction between two nodes, and provide different services according to different instructions; The channel pool manager includes: Channel gate module: It is used as a checkpoint in the process of channel content data interaction to perform security checks on data. When a new security module is added, it will also be connected here to work together; Channel concurrency module: used to manage established channels and schedule resource usage during the operation of these channels; Channel startup module: used to start a new channel, generally used to cooperate with the work of the channel concurrent module; Channel destruction module: used to destroy a running channel; Session queuing module: used to manage resource contention between users using the same channel; The system obtains the local file at node A through the file manager and converts the file content into WebRTC stream data. The interface manager sends a request to submit the file to node B. The channel pool manager extracts and circulates the local channel pool allocation table at node B. The interface manager processes the request of node A, receives the WebRTC stream data or discards the data after verification. If the reception is completed, the file manager converts the WebRTC stream data into a file and verifies the integrity of the file. After the verification is passed, it is saved. The channel pool manager, the file manager and the interface manager are cross-meshed and mutually access data.

2. According to claim 1, a design method for a secure micro server for blockchain, characterized in that: After node B completes receiving the WebRTC stream data in step S3, it converts the WebRTC stream data into a file and verifies the integrity of the file. If the verification fails, the file is discarded; if the verification passes, the file is stored in a specified directory.

3. A design method for a secure micro server for blockchain according to claim 1, characterized in that: The file manager comprises: File directory module: used to manage the local file directory list and provide the corresponding directory list when other modules need it; File conversion module: used to read files into binary and convert them into corresponding data streams according to the network protocol they are based on; File restoration module: used to convert the received data stream into the corresponding file and put the file into the corresponding directory.

4. The design method of a secure micro server for blockchain according to claim 1, characterized in that: The interface manager comprises: Interface permission module: used to manage the interfaces used when the current channel is exposed to the outside world, as well as the access permissions of these interfaces; Data submission module: used to send data requests to other nodes as a client; Interface service module: used as a server to provide services to other nodes, respond to commands sent by other nodes, and receive data sent by other nodes.

Images