A sharding expansion method based on network protocol

Abstract

The present application discloses a sharding expansion method based on a network protocol, which relates to the field of blockchain technology and comprises the following steps: a blockchain node parses a first data packet to obtain a network access request transaction, and delivers the transaction to a contract virtual machine according to the type of the network access request transaction; the contract virtual machine calls a smart contract specified in the network access request transaction, and the smart contract calculates a number of node virtual addresses according to the network access request transaction, and delivers the node virtual addresses to a physical node; the physical node constructs a virtual node according to the node virtual address, and the number of virtual nodes and node virtual addresses is the same, and the virtual node is added to different shards according to the node virtual address, which has the beneficial effect that the physical node can work in multiple shards, the performance and computing power of the physical node can be fully utilized, and the waste of resources can be avoided. The number of shards can be dynamically adjusted, and the shards can be expanded or reduced more flexibly, and the computing resource utilization rate is high.

Description

Technical Field

[0001] The present application belongs to the field of blockchain technology. More specifically, the present application relates to a sharding expansion method based on a network protocol. Background Art

[0002] In the current mainstream sharded blockchain network, a physical machine can only belong to one physical shard. Generally, there is rotation of nodes in the shard. When the physical node is rotated out of the current shard, the computing power of the physical node is always idle before being rotated to other shards. Therefore, the current technical solution has the following defects:

[0003] First, physical nodes cannot work in multiple shards at the same time, and the performance and computing power of physical nodes are often not fully utilized, resulting in a waste of resources. Second, the overall expansion of physical shards is limited by the growth rate of the number of physical nodes, and the computing resource utilization rate is relatively low. Summary of the invention

[0004] The purpose of this application is to provide a shard expansion method based on a network protocol to solve the technical problem in the above-mentioned prior art that a physical node cannot work in multiple shards at the same time.

[0005] In order to achieve the above technical objectives, the technical solutions adopted in this application are as follows:

[0006] A sharding expansion method based on a network protocol comprises the following steps:

[0007] The node account starts the physical node and generates a network access request transaction, the physical node packages the network access request transaction to obtain a first data packet, and delivers the first data packet to the blockchain network;

[0008] The blockchain node parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction;

[0009] The contract virtual machine calls the smart contract specified in the network access request transaction, and the smart contract calculates a number of node virtual addresses according to the network access request transaction, and delivers the node virtual addresses to the physical node;

[0010] The physical node constructs a virtual node according to the node virtual address, the number of the virtual nodes is the same as the number of the node virtual addresses, and the virtual nodes are added to different shards according to the node virtual addresses.

[0011] Preferably, the method further comprises the steps of:

[0012] The node account starts the physical node and generates a registration request transaction, the physical node packages the registration request transaction to obtain a second data packet, and delivers the second data packet to the blockchain network;

[0013] The blockchain node parses the second data packet to obtain the registration request transaction, and delivers it to the contract virtual machine according to the type of the registration request transaction;

[0014] The contract virtual machine calls the smart contract specified in the registration request transaction, and the smart contract saves the node type declared in the registration request transaction.

[0015] Preferably, the contract virtual machine calls the smart contract specified in the registration request transaction, and the smart contract saves the node type reported in the registration request transaction, specifically including the following steps:

[0016] The registration request transaction includes the declared node type, smart contract calling interface and smart contract address;

[0017] The contract virtual machine calls the specified smart contract according to the smart contract address, and the contract virtual machine executes the smart contract calling interface on the smart contract and calculates the virtual role information of the node according to the declared node type;

[0018] The declared node type and the node's virtual role information are stored in the smart contract.

[0019] Preferably, the blockchain node parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction, specifically including the following steps:

[0020] The consensus node in the blockchain node receives the first data packet, and the consensus node verifies whether the node account delivering the first data packet is a registered node account;

[0021] If the verification result is that the node account is not a registered one, the node account is denied access to the network;

[0022] If the verification result is that it is a registered node account, the first data packet is parsed to obtain the network access request transaction, and delivered to the contract virtual machine according to the type of the network access request transaction.

[0023] Preferably, the contract virtual machine calls the smart contract specified in the network access request transaction, and the smart contract calculates a number of virtual addresses according to the network access request transaction, specifically including the following steps:

[0024] The network access request transaction includes the declared node type, the node's virtual role information, the smart contract calling interface and the smart contract address;

[0025] The contract virtual machine calls the specified smart contract according to the smart contract address, and the contract virtual machine executes the smart contract calling interface on the smart contract. The smart contract selects the node account into the specified role shard and calculates the virtual address according to the virtual role information of the node.

[0026] Preferably, the smart contract selects the node account into a specified role shard and calculates the virtual address according to the virtual role information of the node, specifically comprising the following steps:

[0027] The smart contract selects the node account into a designated role shard according to the virtual role information of the node, wherein each virtual role information corresponds to a role shard, and each role shard has a fixed role shard virtual address;

[0028] The smart contract calculates the node virtual address of the node account according to the role shard virtual address and the number of nodes in the role shard;

[0029] The role shard virtual address and the node virtual address are stored in the smart contract.

[0030] Preferably, delivering the node virtual address to the physical node specifically includes the following steps:

[0031] The smart contract including at least the node virtual address is packaged and encapsulated in a block, and a block save event is triggered after the block is saved;

[0032] The broadcast captures the block by monitoring the block storage event, packages the captured block to obtain a third data packet, and broadcasts the third data packet in the entire network;

[0033] The physical node receives the third data packet through network-wide broadcast and performs pre-processing.

[0034] Preferably, the physical node receives the third data packet through network-wide broadcast and performs preprocessing, which specifically includes the following steps:

[0035] The physical node parses the third data packet to obtain the smart contract block including at least the node virtual address;

[0036] Traverse the data in the smart contract block to determine whether the smart contract contains the node account for starting the physical node. If so, read the node virtual address in the smart contract.

[0037] Preferably, the physical node constructs a virtual node according to the node virtual address, the number of the virtual nodes is the same as the number of the node virtual addresses, and the virtual nodes are added to different shards according to the node virtual addresses, specifically including the following steps:

[0038] The physical node constructs a virtual node according to each node virtual address, and specifies the node virtual address as the communication address of the virtual node;

[0039] Each node virtual address corresponds to a different role shard, and the virtual node is added to different shards according to the node virtual address, and all virtual nodes share the physical resources of the physical node.

[0040] A computer-readable storage medium, characterized in that computer instructions are stored on the computer-readable storage medium, and the steps of the above-mentioned method are implemented when the computer instructions are executed by a processor.

[0041] The beneficial effects provided by this application are:

[0042] 1. The smart contract of the present application calculates several node virtual addresses according to the network access request transaction, and delivers the node virtual addresses to the physical nodes. The physical nodes construct virtual nodes according to the node virtual addresses. The number of virtual nodes and node virtual addresses is the same. The virtual nodes are added to different shards according to the node virtual addresses. All virtual nodes share the physical resources of the same physical node. The physical nodes can work in multiple shards. The performance and computing power of the physical nodes can be fully utilized, avoiding waste of resources.

[0043] 2. The smart contract of the present application selects the node account into the designated role shard according to the virtual role information of the node, wherein each virtual role information corresponds to a role shard, and each role shard has a fixed role shard virtual address. The smart contract calculates the node virtual address of the node account according to the role shard virtual address and the number of nodes in the role shard, and saves the role shard virtual address and the node virtual address in the smart contract. Thus, the number of shards can be dynamically adjusted, and the shards can be expanded or reduced more flexibly, with high computing resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0045] Figure 1 It is a flow chart of the sharding expansion method based on the network protocol. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0047] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0048] Embodiment 1:

[0049] like Figure 1 As shown, this embodiment includes a sharding expansion method based on a network protocol, comprising the following steps: the node account starts a physical node and generates a network access request transaction, the physical node packages the network access request transaction to obtain a first data packet, and delivers the first data packet to the blockchain network;

[0050] The blockchain node parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction; the contract virtual machine calls the smart contract specified in the network access request transaction, and the smart contract calculates several node virtual addresses according to the network access request transaction, and delivers the node virtual addresses to the physical node;

[0051] The physical node constructs a virtual node based on the node virtual address. The number of virtual nodes is the same as the number of node virtual addresses. The virtual nodes are added to different shards based on the node virtual address.

[0052] The steps further include: the node account starts the physical node and generates a registration request transaction, the physical node packages the registration request transaction to obtain a second data packet, and delivers the second data packet to the blockchain network;

[0053] The blockchain node parses the second data packet to obtain the registration request transaction, and delivers it to the contract virtual machine according to the type of the registration request transaction; the contract virtual machine calls the smart contract specified in the registration request transaction, and the smart contract saves the node type declared in the registration request transaction.

[0054] The node account starts the physical node and generates a registration request transaction. The physical node packages the registration request transaction to obtain a second data packet and delivers the second data packet to the blockchain network. Specifically, the following steps are included: the node program package generates a registration request transaction, and the registration request transaction includes the declared node type, the smart contract calling interface, and the smart contract address;

[0055] The node program package digitally signs the registration request transaction, packages the digitally signed registration request transaction to obtain a second data packet, and delivers the second data packet to the blockchain network. The registration request transaction is essentially a transaction that calls a smart contract, and the digital signature is used to prove that the registration request transaction is constructed by a specific node account.

[0056] As another implementation method, the node account starts the physical node and generates a registration request transaction, the physical node packages the registration request transaction to obtain a second data packet, and delivers the second data packet to the blockchain network, specifically including the following steps: the wallet generates a registration request transaction, the registration request transaction includes the declared node type, the smart contract call interface and the smart contract address;

[0057] The wallet digitally signs the registration request transaction, packages the digitally signed registration request transaction to obtain a second data packet, and delivers the second data packet to the blockchain network.

[0058] The registration request transaction includes a declared node type, and specifically includes the following steps: The declared node type is specified through a configuration file.

[0059] Specifically, taking JSON format as an example, declare a single node type {…, miner_type: "advance", ...}. Declare multiple node types {…, miner_type: "advance, validator", ...}. The delimiter between node type values ​​can be selected based on actual conditions, as long as the node type can be clearly distinguished.

[0060] The configuration file of this application includes but is not limited to JSON format. Other formats such as XML can be flexibly selected based on actual conditions.

[0061] As another implementation, the registration request transaction includes a declared node type, specifically including the following steps: the declared node type is specified via a command line parameter of a node package.

[0062] Specifically, declare a single node type topio-miner_type "advance". Declare multiple node types topio -miner_type "advance,validator". The delimiter between the node type values ​​can be selected based on the actual situation, as long as the node type can be clearly distinguished. The name of the command line parameter (-miner_type) is also freely selected based on the actual situation, as long as the program can correctly parse the input data.

[0063] The blockchain node parses the second data packet to obtain the registration request transaction, and delivers it to the contract virtual machine according to the type of the registration request transaction, specifically including the following steps:

[0064] The blockchain node receives and parses the second data packet to obtain a registration request transaction. The blockchain node is provided with a data packet dispatcher, and the data packet dispatcher dispatches the data packet to the smart contract call processing module according to the type of the registration request transaction.

[0065] The smart contract call processing module receives the registration request transaction, and the smart contract call processing module delivers the registration request transaction to the contract virtual machine.

[0066] The contract virtual machine calls the smart contract specified in the registration request transaction, and the smart contract saves the node type reported in the registration request transaction, which specifically includes the following steps: the registration request transaction includes the reported node type, the smart contract calling interface and the smart contract address;

[0067] The contract virtual machine calls the specified smart contract according to the smart contract address. The contract virtual machine executes the smart contract calling interface on the smart contract and calculates the virtual role information of the node according to the declared node type; the declared node type and the virtual role information of the node are saved in the smart contract.

[0068] The contract virtual machine executes the smart contract call interface on the smart contract and calculates the virtual role information of the node according to the declared node type, which specifically includes the following steps: according to the actual business scenario, determine whether the declared node type complies with the declaration rules. If it does, calculate the virtual role information of the node according to the declared node type; if it does not comply, reject the registration request transaction of the node account.

[0069] The actual business scenarios include only allowing a single node type to be received. In this business scenario, each node account can only be registered as one node type. The actual business scenarios also include allowing the reception of a combination of node types. In this business scenario, each node account can register only one node type at a time, or multiple node types at a time.

[0070] The actual business scenario includes a node type that can only generate one virtual role. In this business scenario, there is a many-to-one relationship between nodes and virtual roles, that is, a specified node type can only virtualize one role, but the corresponding virtual role can be generated by nodes of different types. The actual business scenario also includes a node type that can generate multiple virtual roles. In this business scenario, there is a many-to-many relationship between nodes and virtual roles.

[0071] Select the most flexible business scenario, that is, the actual business scenario includes node types that allow receiving combinations and a node type that can be split into multiple virtual roles. The node types declared in the registration request transaction include advance node type and validator node type. The contract virtual machine executes the smart contract call interface on the smart contract and calculates the virtual role information of the node based on the declared advance and validator node types. The audit virtual role information, storage virtual role information and validator virtual role information are calculated based on the advance node type, and the validator virtual role information is calculated based on the validator node type.

[0072] Select the most restricted business scenario, that is, the actual business scenario includes only allowing the reception of a single node type and a specified node type can only virtualize one role. In this business scenario, if multiple node types are specified during the declaration, the registration request transaction of the node account will be rejected.

[0073] The node type and the node's virtual role information are saved in the smart contract, which specifically includes the following steps: the node type declared in the registration request transaction is saved in the smart contract, and the node's virtual role information is saved in the contract attribute of the smart contract. Among them, the contract attribute is essentially the field that stores the smart contract data, that is, the node's virtual role information is written into the field of the database, and the reading and writing of the contract attribute is the reading and writing of the corresponding field in the database.

[0074] The blockchain node parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction, specifically including the following steps:

[0075] The consensus node in the blockchain node receives the first data packet, and the consensus node verifies whether the node account delivering the first data packet is a registered node account;

[0076] If the verification result is that the node account is not a registered node account, the node account is denied access to the network; if the verification result is that it is a registered node account, the first data packet is parsed to obtain the network access request transaction, and delivered to the contract virtual machine according to the type of the network access request transaction.

[0077] The contract virtual machine calls the smart contract specified in the network access request transaction. The smart contract calculates several virtual addresses based on the network access request transaction, which specifically includes the following steps:

[0078] The network access request transaction includes the declared node type, the node's virtual role information, the smart contract call interface and the smart contract address;

[0079] The contract virtual machine calls the specified smart contract according to the smart contract address. The contract virtual machine executes the smart contract calling interface on the smart contract. The smart contract selects the node account into the specified role shard and calculates the virtual address according to the node's virtual role information.

[0080] Among them, the network access request transaction is also a transaction that calls a smart contract like the registration request transaction. In this embodiment, the smart contract in the network access request transaction is defined as an election contract, and the election contract calling interface is defined as nodeJoin. The smart contract in the registration request transaction is defined as a registration contract (registrationContract), and the registration contract calling interface is defined as registerMiner. The consensus node obtains the data in the registration contract, determines whether the data in the registration contract contains the specified node account, and if the registration contract contains the specified node account, parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction. If the registration contract does not contain the specified node account, the network access request transaction is rejected.

[0081] As another implementation method, if the smart contract in the registration request transaction already saves the declared node type and the node's virtual role information, then the network access request transaction may not include the declared node type and the node's virtual role information. The network access request transaction can call the smart contract that already saves the declared node type and the node's virtual role information according to the smart contract address.

[0082] Parse the first data packet to obtain the network access request transaction, and deliver it to the contract virtual machine according to the type of the network access request transaction, specifically including the following steps:

[0083] Parse the first data packet verified by the consensus node to obtain the network access request transaction, and the data packet dispatcher dispatches it to the smart contract call processing module according to the type of the network access request transaction;

[0084] The smart contract call processing module receives the network access request transaction, and the smart contract call processing module delivers the network access request transaction to the contract virtual machine.

[0085] The smart contract selects the node account into the specified role shard and calculates the virtual address based on the node's virtual role information. The specific steps include:

[0086] The smart contract selects the node account into the specified role shard according to the node's virtual role information, where each virtual role information corresponds to a role shard, and each role shard has a fixed role shard virtual address;

[0087] The smart contract calculates the node virtual address of the node account according to the role shard virtual address and the number of nodes in the role shard; and saves the role shard virtual address and the node virtual address in the smart contract.

[0088] In this embodiment, the virtual role information of the node includes auditor virtual role information, verifier virtual role information, edge virtual role information and storage virtual role information. The role slices include auditor role slices, verifier role slices, edge role slices and storage role slices.

[0089] Among them, each virtual role information corresponds to a role shard, the audit virtual role information corresponds to the auditor role shard, the verifier virtual role information corresponds to the verifier role shard, the edge virtual role information corresponds to the edge role shard, and the storage virtual role information corresponds to the storage role shard. The smart contract selects the node account into the specified role shard according to the node's virtual role information, and each role shard has a fixed role shard virtual address.

[0090] Among them, the smart contract selects the node account into the designated role shard based on the node's virtual role information. The audit virtual role information can only be selected into the auditor role shard, the verifier virtual role information can only be selected into the verifier role shard, the edge virtual role information can only be selected into the edge role shard, and the storage virtual role information can only be selected into the storage role shard.

[0091] In this embodiment, the virtual address is defined as XIP, and the virtual address of the auditor role slice is defined as XIP_Auditor_Group. XIP_Auditor_Group is a variable name of XIP type. The content of the XIP_Auditor_Group variable only represents the virtual address of the auditor role slice, that is, XIP_Auditor_Group cannot represent the node virtual address of each node in the auditor role slice.

[0092] The node virtual address of the node in the auditor role shard is defined as XIP_Auditor_One. Because all nodes in each shard belong to this shard, XIP_Auditor_One indicates that the fields of the node are assigned based on XIP_Auditor_Group.

[0093] XIP is defined as a 32-bit integer, where every 8 bits represent a valid field. From high to low, the 32-bit integer can be divided into four fields. These four fields are defined as NetworkId, ZoneId, GroupId, and SlotId respectively. For XIP_Auditor_Group, NetworkId=128, ZoneId=128, GroupId=128 can be defined, and SlotId must be 255 (corresponding to hexadecimal 0xFF). For XIP_Auditor_One, NetworkId=128, ZoneId=128, GroupId=128, and SlotId=3 can be defined. In this embodiment, XIP_Auditor_One is equal to XIP_Auditor_One&XIP_Auditor_Group. Based on the implementation method of XIP, in this embodiment, the difference between the virtual address of the role slice and the node virtual address of the node in the role slice is mainly in the SlotID field. The implementation of virtual address also includes flat mode or other structured implementation.

[0094] The election contract allocates the SlotId field to obtain the node virtual address based on the virtual address of the auditor role shard and the number of nodes in the auditor role shard. The allocated node virtual address is assigned to the node account of each node in the auditor role shard. In this embodiment, the auditor role shard can be filled with up to 254 nodes, and 255 is dedicated to the auditor role shard virtual address. To meet XIP_Auditor_One==XIP_Auditor_One&XIP_Auditor_Group, it is used to facilitate the judgment of whether the virtual address of the role shard and the node virtual address of the node in the role shard are subordinate.

[0095] Delivering the node virtual address to the physical node specifically includes the following steps: packaging the smart contract including at least the node virtual address and encapsulating it in a block, and triggering a block save event after the block is saved;

[0096] The broadcast captures the block by monitoring the block storage event, packages the captured block to obtain the third data packet, and broadcasts the third data packet in the whole network; the physical node receives the third data packet through the whole network broadcast and performs pre-processing.

[0097] In this embodiment, the election contract including at least the node virtual address is packaged, and the packaged data is consensused. After the consensus is passed, the data is encapsulated in the block. The broadcast module will monitor the blocks produced by the election contract. Whenever the data is packaged into the block and saved, the corresponding block save event will be triggered. The broadcast captures the block by monitoring the block save event, and the captured block is packaged to obtain a third data packet. The type of the third data packet is an election data packet, and the election data packet is broadcasted throughout the network.

[0098] The physical node receives the third data packet through the whole network broadcast and performs preprocessing, which specifically includes the following steps: the physical node parses the third data packet to obtain a smart contract block including at least the node virtual address;

[0099] Traverse the data in the smart contract block to determine whether the smart contract contains the node account that starts the physical node. If so, read the node virtual address in the smart contract.

[0100] The physical node parses the third data packet to obtain a smart contract block including at least the node virtual address, and further includes the steps of:

[0101] The data packet receiving module receives the third data packet and delivers the third data packet to the upper-level module. The upper-level module is provided with a data packet dispatcher. The data packet dispatcher dispatches the third data packet to the smart contract processing module according to the type of the third data packet. The smart contract processing module parses the third data packet to obtain a smart contract block that at least includes a node virtual address.

[0102] In this embodiment, the smart contract processing module traverses the data in the smart contract block to determine whether the smart contract contains a node account for starting a physical node. If so, the node virtual address in the smart contract is read, and the node virtual address is a valid node virtual address and is saved locally.

[0103] The physical node constructs a virtual node according to the node virtual address. The number of virtual nodes is the same as the number of node virtual addresses. The virtual node is added to different shards according to the node virtual address. Specifically, the following steps are included:

[0104] The physical node constructs a virtual node according to each node virtual address, and specifies the node virtual address as the communication address of the virtual node;

[0105] Each node virtual address corresponds to a different role shard. Virtual nodes are added to different shards according to the node virtual address, and all virtual nodes share the physical resources of the physical node.

[0106] In this embodiment, the smart contract processing module constructs a virtual node according to each valid node virtual address, and specifies the valid node virtual address as the communication address of the virtual node. In the process of constructing the virtual node, differentiated functional module initialization will be performed based on different role shards. After the functional module is initialized, the virtual node can communicate point-to-point through the node virtual address, and all virtual nodes share the physical resources of the same physical node.

[0107] Embodiment 2:

[0108] A computer-readable storage medium stores computer instructions, which implement the steps of the method in Example 1 when executed by a processor.

[0109] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0110] The present application is described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0111] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0112] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0113] It should be noted that:

[0114] The phrases "one embodiment" or "embodiment" mentioned in the specification mean that a particular feature, structure or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "one embodiment" or "embodiment" appearing in various places throughout the specification do not necessarily refer to the same embodiment.

[0115] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0116] In addition, it should be noted that the shapes and names of the parts and components of the specific embodiments described in this specification may be different. Any equivalent or simple changes made based on the structure, features and principles described in the patent concept of this application are included in the protection scope of the patent of this application. The technicians in the technical field of this application can make various modifications or supplements to the specific embodiments described or replace them in a similar way, as long as they do not deviate from the structure of this application or exceed the scope defined by the claims, they should all fall within the protection scope of this application.

Claims

1. A sharding expansion method based on a network protocol, characterized in that: The following steps are involved: The node account starts the physical node and generates a network access request transaction, the physical node packages the network access request transaction to obtain a first data packet, and delivers the first data packet to the blockchain network; The blockchain node parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction; The contract virtual machine calls the smart contract specified in the network access request transaction, and the smart contract calculates a number of node virtual addresses according to the network access request transaction, and delivers the node virtual addresses to the physical node; The physical node constructs a virtual node according to the node virtual address, the number of the virtual nodes is the same as the number of the node virtual addresses, and the virtual nodes are added to different shards according to the node virtual addresses; The contract virtual machine calls the smart contract specified in the network access request transaction, and the smart contract calculates a number of virtual addresses according to the network access request transaction, specifically including the following steps: The network access request transaction includes the declared node type, the node's virtual role information, the smart contract calling interface and the smart contract address; The contract virtual machine calls the specified smart contract according to the smart contract address, and the contract virtual machine executes the smart contract calling interface on the smart contract. The smart contract selects the node account into the specified role shard and calculates the virtual address according to the virtual role information of the node.

2. A sharding capacity expansion method based on a network protocol as claimed in claim 1, characterized in that: Also includes the steps: The node account starts the physical node and generates a registration request transaction, the physical node packages the registration request transaction to obtain a second data packet, and delivers the second data packet to the blockchain network; The blockchain node parses the second data packet to obtain the registration request transaction, and delivers it to the contract virtual machine according to the type of the registration request transaction; The contract virtual machine calls the smart contract specified in the registration request transaction, and the smart contract saves the node type declared in the registration request transaction.

3. A sharding capacity expansion method based on network protocol as claimed in claim 2, characterized in that: The contract virtual machine calls the smart contract specified in the registration request transaction, and the smart contract saves the node type reported in the registration request transaction, specifically including the following steps: The registration request transaction includes the declared node type, smart contract calling interface and smart contract address; The contract virtual machine calls the specified smart contract according to the smart contract address, and the contract virtual machine executes the smart contract calling interface on the smart contract and calculates the virtual role information of the node according to the declared node type; The declared node type and the node's virtual role information are stored in the smart contract.

4. A sharding capacity expansion method based on network protocol as claimed in claim 1, characterized in that: The blockchain node parses the first data packet to obtain the network access request transaction, and delivers it to the contract virtual machine according to the type of the network access request transaction, specifically including the following steps: The consensus node in the blockchain node receives the first data packet, and the consensus node verifies whether the node account delivering the first data packet is a registered node account; If the verification result is that the node account is not a registered one, the node account is denied access to the network; If the verification result is that it is a registered node account, the first data packet is parsed to obtain the network access request transaction, and delivered to the contract virtual machine according to the type of the network access request transaction.

5. A sharding capacity expansion method based on network protocol as claimed in claim 1, characterized in that: The smart contract selects the node account into the specified role shard and calculates the virtual address according to the virtual role information of the node, specifically including the following steps: The smart contract selects the node account into a designated role shard according to the virtual role information of the node, wherein each virtual role information corresponds to a role shard, and each role shard has a fixed role shard virtual address; The smart contract calculates the node virtual address of the node account according to the role shard virtual address and the number of nodes in the role shard; The role shard virtual address and the node virtual address are stored in the smart contract.

6. A sharding capacity expansion method based on network protocol as claimed in claim 1, characterized in that: Delivering the node virtual address to the physical node specifically includes the following steps: The smart contract including at least the node virtual address is packaged and encapsulated in a block, and a block save event is triggered after the block is saved; The broadcast captures the block by monitoring the block storage event, packages the captured block to obtain a third data packet, and broadcasts the third data packet in the entire network; The physical node receives the third data packet through network-wide broadcast and performs pre-processing.

7. A sharding capacity expansion method based on network protocol as claimed in claim 6, characterized in that: The physical node receives the third data packet through the whole network broadcast and performs preprocessing, which specifically includes the following steps: The physical node parses the third data packet to obtain the smart contract block including at least the node virtual address; Traverse the data in the smart contract block to determine whether the smart contract contains the node account for starting the physical node. If so, read the node virtual address in the smart contract.

8. A sharding capacity expansion method based on network protocol as claimed in claim 1, characterized in that: The physical node constructs a virtual node according to the node virtual address, the number of the virtual nodes is the same as the number of the node virtual addresses, and the virtual node is added to different shards according to the node virtual address, specifically including the following steps: The physical node constructs a virtual node according to each node virtual address, and specifies the node virtual address as the communication address of the virtual node; Each node virtual address corresponds to a different role shard, and the virtual node is added to different shards according to the node virtual address, and all virtual nodes share the physical resources of the physical node.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and when the computer instructions are executed by the processor, the steps of the sharding capacity expansion method based on the network protocol as described in any one of claims 1 to 8 are implemented.

Images