Block generation node selection method and apparatus

Abstract

A block generation node selection method and apparatus. The method is applied to a distributed ledger network. The method may be executed by a first node in the distributed ledger network. The first node generates, on the basis of a first task, a first result corresponding to the first task; and the first node sends the first result, wherein the first result is used for determining whether the first node is a block generation node, and the block generation node is used for generating a block for a distributed ledger on the basis of a transaction in a transaction pool. In addition, nodes in the distributed ledger network other than the block generation node do not need to package the block and perform computation corresponding to block generation, so that a block packaging process is unbound from a block generation node selection process, thereby helping to save computing resources of the entire distributed ledger network. The first node transmits the first result in the distributed ledger network to select a block generation node, without requiring multiple rounds of voting, thereby helping to save transmission resources of the entire distributed ledger network.

Description

A method and apparatus for selecting block-producing nodes

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510126692.2, filed on January 27, 2025, entitled "A Method and Apparatus for Selecting Block Nodes", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of wireless communication, and more particularly to a method and apparatus for selecting block-producing nodes. Background Technology

[0004] A distributed ledger network is essentially a decentralized database. Relying on cryptography and ingenious distributed algorithms, it enables participants to reach consensus on the internet, where trust relationships are often impossible, without the intervention of any third-party center. This solves the problem of reliable transfer of trust and value at extremely low cost. Furthermore, the core driving mechanism of a distributed ledger network includes the block-producing node selection mechanism. Traditional block-producing node selection mechanisms include: mechanisms based on practical byzantine fault tolerance (PBFT) and mechanisms based on proof-of-work (PoW), among others.

[0005] Due to the limited communication resources, diverse equipment types, and varied network topologies of wireless networks, traditional block-producing node selection mechanisms are no longer suitable for wireless network scenarios when distributed ledger technology is combined with wireless communication technology. For example, the PBFT-based block-producing node selection mechanism requires a large amount of communication bandwidth, which is scarce in wireless networks; another example is the PoW-based block-producing node selection mechanism, which requires each node to perform relatively complex hash calculations, while the computing resources of nodes (such as terminals) in wireless networks are limited.

[0006] In scenarios where distributed ledger technology and wireless communication technology are combined, how to select block-producing nodes is a problem that urgently needs to be solved. Summary of the Invention

[0007] This application provides a method and apparatus for selecting block-producing nodes, which is used to select block-producing nodes from multiple nodes in a distributed ledger network in a scenario combining distributed ledger technology and wireless communication technology, and helps to save computing resources and communication resources in wireless networks.

[0008] In a first aspect, this application provides a method for selecting block-producing nodes, which is applied in a distributed ledger network and can be executed by the first node in the distributed ledger network.

[0009] For example, the first node is a terminal (or a module in the terminal), an access network device (or a module in the access network device), a core network device (or a module in the core network device), or an independent server (or a module in the server) deployed in the access network or core network.

[0010] The method includes: a first node generating a first result corresponding to a first task; and the first node sending the first result. The first result is used to determine whether the first node is a block-producing node, which generates blocks for the distributed ledger based on transactions in the transaction pool.

[0011] In the above technical solution, nodes in the distributed ledger network select block-producing nodes based on tasks. These block-producing nodes generate blocks for the distributed ledger based on transactions in the transaction pool. That is, this application eliminates the need to determine block-producing nodes before performing block-related calculations during block packaging; instead, it determines them based on the task, decoupling the block packaging process from the block-producing node selection process. Consequently, nodes other than the block-producing nodes in the distributed ledger network do not need to package blocks and perform the corresponding block-producing calculations, thus saving computational resources for the entire distributed ledger network. Furthermore, by transmitting the task results of node processing within the distributed ledger network without requiring multiple rounds of voting, block-producing nodes can be selected, further saving transmission resources for the entire distributed ledger network.

[0012] In one possible implementation, if the first node is a block-producing node, it can also generate blocks based on transactions in the transaction pool. For example, the first node can package the transactions in the transaction pool into blocks; alternatively, the first node can retrieve transactions from the transaction pool, execute the transactions to obtain the corresponding transaction results, and then package the transaction results (transaction and transaction results) into blocks. Subsequently, the first node sends the blocks, that is, it publishes the blocks to the distributed ledger. However, if the first node is not a block-producing node, it does not need to generate blocks based on transactions in the transaction pool; instead, it receives blocks from other nodes that are determined to be block-producing nodes.

[0013] In the above technical solution, when the first node is the block-producing node, the first node packages the transactions in the transaction pool into blocks, which helps to save computing resources. That is, in this application, the block-producing node is determined, and then the block-producing node generates the block. This decouples the process of packaging the block from the process of determining the block-producing node, eliminating the need to determine the block-producing node before performing block-related calculations while packaging the block.

[0014] In one possible implementation, when the first node is a block-producing node, the first result is published in the distributed ledger. Thus, the node that published the task can obtain the result of the task from the distributed ledger. For example, the first node also publishes the first result to the distributed ledger. For instance, the first node puts the first result into its transaction pool, then packages the first result in its transaction pool into a block, and publishes the block to the distributed ledger.

[0015] For example, when determining that it is a block-producing node, the first node can do so in at least the following two ways:

[0016] In Method 1, after sending the first result, the first node can also receive the verification result from the second node in the distributed ledger network. The second node's verification result is obtained by verifying the first result. Based on the second node's verification result, the first node determines itself to be a block-producing node. In this technical solution, the first node determines itself to be a block-producing node based on the second node's verification result, eliminating the need for a dedicated node in the distributed ledger network for determining block-producing nodes, thus reducing the deployment complexity of the distributed ledger network.

[0017] Method 2: After sending the first result, the first node can also receive a second result from a third node in the distributed ledger network. The second result is determined by the third node based on the verification result of the second node in the distributed ledger network. The verification result of the second node is obtained by the second node from verifying the first result. Based on the second result, the first node determines that it is a block-producing node in the distributed ledger network. In the above technical solution, a node (i.e., the third node) is set up in the distributed ledger network specifically for determining the block-producing node. In this solution, each node is not forced to broadcast its own verification result. For example, each node can send its own verification result to the third node, which helps to increase the flexibility of communication in the distributed ledger network and save communication resources in the distributed ledger network.

[0018] In one possible implementation, the first task is either network management related to the operator's network or providing services to users. In the above technical solution, the processing flow that would otherwise require execution by the communication network (or distributed ledger network) (i.e., the flow for handling the first task) is used as the flow for selecting block-producing nodes in the distributed ledger network. This eliminates the need for a separate block-producing node selection process, simplifying the workflow and thus saving communication and computing resources in the distributed ledger network.

[0019] For example, the first task includes task data and task objective; the first result is the result of achieving the task objective based on the task data; and for another example, the first task includes task data, task objective, and task constraints; the first result is the result of achieving the task objective and satisfying the task constraints based on the task data.

[0020] For example, the first task is a task in the resource allocation type, cache optimization type, image data processing type, routing optimization type, or mobile edge computing type.

[0021] In one possible implementation, before generating the first result corresponding to the first task based on the first task, the first node can also obtain the first task from the task pool. For example, the first node obtains the first task from the task pool of the first node.

[0022] In the above technical solution, a task pool is set up to store tasks. The first node can obtain tasks from the task pool and then determine the block output node, which helps to simplify the process.

[0023] In one possible implementation, if no block-producing node is determined according to the first task, the first node determines the block-producing node according to a preset mechanism; wherein the preset mechanism includes one or more of the following: a mechanism for selecting nodes as block-producing nodes in turn, a mechanism for randomly selecting nodes as block-producing nodes, a mechanism for selecting fixed nodes as block-producing nodes, a mechanism for selecting block-producing nodes based on a proof-of-work algorithm, a mechanism for selecting block-producing nodes based on a proof-of-stake algorithm, a mechanism for selecting block-producing nodes based on a proof-of-authority algorithm, or a mechanism for selecting block-producing nodes based on a proof-of-cover algorithm.

[0024] In the above technical solution, if the block-producing node cannot be determined based on the first task, the first node adopts other block-producing mechanisms to select the block-producing node, ensuring that the block-producing node can be determined in a timely manner, so that the distributed ledger network can produce blocks on time and the distributed ledger network can operate normally.

[0025] In one possible implementation, before the first node generates the first result corresponding to the first task, it also determines whether a task exists in the task pool. Furthermore, if the first node determines that no task exists in the task pool, it determines a block-producing node according to a preset mechanism; wherein the preset mechanism includes one or more of the following: a mechanism for selecting nodes in turn as block-producing nodes, a mechanism for randomly selecting nodes as block-producing nodes, a mechanism for selecting fixed nodes as block-producing nodes, a mechanism for selecting block-producing nodes based on a proof-of-work algorithm, a mechanism for selecting block-producing nodes based on a proof-of-stake algorithm, a mechanism for selecting block-producing nodes based on a proof-of-authority algorithm, or a mechanism for selecting block-producing nodes based on a proof-of-cover algorithm.

[0026] In the above technical solution, the first node can first determine whether there is a task in the task pool. If there is a task, it obtains the task from the task pool; if there is no task, it determines the block producing node according to the preset mechanism. In this way, it can ensure that the block producing node can be determined in a timely manner, so that the distributed ledger network can produce blocks on time and the distributed ledger network can operate normally.

[0027] Secondly, this application provides a method for selecting block-producing nodes, which is applied in a distributed ledger network and can be executed by the first node in the distributed ledger network.

[0028] For example, the first node is a terminal (or a module in the terminal), an access network device (or a module in the access network device), a core network device (or a module in the core network device), or an independent server (or a module in the server) deployed in the access network or core network.

[0029] The method includes: the first node determines whether a task exists in the task pool;

[0030] Furthermore, if the first node determines that a task exists in the task pool, it obtains the task (i.e., the first task) from the task pool, generates the first result corresponding to the first task, and sends the first result. The first result is used to determine whether the first node is a block-producing node, which generates blocks for the distributed ledger based on the transactions in the transaction pool.

[0031] If the first node determines that there are no tasks in the task pool, it determines the block-producing node according to a preset mechanism. The preset mechanism includes one or more of the following: a mechanism of selecting nodes in turn as block-producing nodes, a mechanism of randomly selecting nodes as block-producing nodes, a mechanism of selecting fixed nodes as block-producing nodes, a mechanism of selecting block-producing nodes based on the proof-of-work algorithm, a mechanism of selecting block-producing nodes based on the proof-of-stake algorithm, a mechanism of selecting block-producing nodes based on the proof-of-authority algorithm, or a mechanism of selecting block-producing nodes based on the proof-of-cover algorithm.

[0032] In the above technical solution, the first node can first determine whether there is a task in the task pool. If there is a task, it obtains the task from the task pool and then determines the block producing node according to the task result. If there is no task, the block producing node is determined according to the preset mechanism. In this way, the block producing node can be determined in a timely manner, so that the distributed ledger network can produce blocks on time and the distributed ledger network can operate normally.

[0033] Thirdly, this application provides a method for selecting block-producing nodes, which is applied in a distributed ledger network and can be executed by a second node in the distributed ledger network.

[0034] For example, the second node is a terminal (or a module in the terminal), an access network device (or a module in the access network device), a core network device (or a module in the core network device), or an independent server (or a module in the server) deployed in the access network or core network.

[0035] The method includes: a second node receiving a first result, wherein the first result is generated by the first node based on a first task, and the first result is used to determine whether the first node is a block-producing node, and the block-producing node is used to generate blocks for the distributed ledger based on transactions in the transaction pool. The second node then determines its verification result based on the first result.

[0036] In one possible implementation, the first result is used to determine whether the first node is a block-producing node. Specifically, the first result can be used by the second node to determine its verification result, and the second node's verification result is used to determine whether the first node is a block-producing node. That is, the second node receives the first result, determines its verification result based on the first result, and the second node's verification result is used to determine whether the first node is a block-producing node.

[0037] In one possible implementation, when the second node determines its verification result based on the first result, specifically, the second node determines its verification result based on the first task and the first result. For example, before receiving the first result, the second node also obtains the first task from a task pool. For instance, the second node obtains the first task from its own task pool.

[0038] Based on the parameters included in the first task, the following are two examples of how the second node determines the verification result: Example 1: The first task includes task data and task objectives. Specifically, when the second node determines its verification result based on the first task and the first result, it can be that the second node determines the verification result as "verification passed" if it determines that the first result achieves the task objective based on the task data. Example 2: The first task includes task data, task objectives, and task constraints. Specifically, when the second node determines its verification result based on the first task and the first result, it can be that the second node determines the verification result as "verification passed" if it determines that the first result achieves the task objective based on the task data and satisfies the task constraints.

[0039] For example, when the second node determines that the first node is a block-producing node, it can do so in the following two ways:

[0040] In Method 1, the second node also determines whether the first node is a block-producing node in the distributed ledger network based on the verification result of the second node.

[0041] In the above technical solution, the second node determines the first node as the block-producing node based on its own verification results, eliminating the need to set up a dedicated node in the distributed ledger network for determining the block-producing node, which helps reduce the deployment complexity of the distributed ledger network.

[0042] In method 2, the second node also receives a second result from a third node in the distributed ledger network, where the second result is determined by the third node based on the verification result of the second node. Based on the second result, the second node determines that the first node is a block-producing node in the distributed ledger network.

[0043] In the above technical solution, a node (i.e., a third node) is set up in the distributed ledger network specifically for determining the block-producing node. In this way, each node can send its verification results to the third node, which helps to save communication resources in the distributed ledger network.

[0044] Fourthly, this application provides a method for selecting block-producing nodes, which is applied in a distributed ledger network and can be executed by a fourth node in the distributed ledger network.

[0045] For example, the fourth node is a terminal (or a module in a terminal), an access network device (or a module in an access network device), a core network device (or a module in a core network device), or an independent server (or a module in a server) deployed in the access network or core network.

[0046] The method includes: the fourth node generating a first task; the fourth node sending the first task, which is used to determine the block-producing nodes of the distributed ledger network, and the block-producing nodes are used to generate blocks of the distributed ledger based on the transactions in the transaction pool.

[0047] In one possible implementation, the first task is used by a first node in the distributed ledger network to generate a first result, which is used to determine whether the first node is a block-producing node. For example, the first task is received and processed by the first node.

[0048] In one possible implementation, when the fourth node generates the first task, specifically, the fourth node generates the first task according to the parameter format corresponding to the task type of the first task.

[0049] The above technical solution helps the first node to accurately parse and process the first task.

[0050] In one possible implementation, the fourth node also obtains configuration information before generating the first task. The configuration information includes parameter formats corresponding to multiple types, including the task type of the first task.

[0051] In the above technical solution, the fourth node can generate different types of tasks, thereby adapting to different task requirements in the communication network, and can determine block nodes from the distributed ledger network based on different types of tasks.

[0052] In one possible implementation, if the first node is a block-producing node, the first result is published in the distributed ledger. Correspondingly, the fourth node can also obtain the first result from the distributed ledger.

[0053] In the above technical solution, the block-producing node can publish the task results obtained from processing the first task in the distributed ledger, so that the fourth node can obtain the first result from the distributed ledger and perform corresponding operations based on the first result. In this way, while ensuring the normal selection of block-producing nodes by the distributed ledger network, the fourth node can also perform tasks related to the communication network.

[0054] Fifthly, this application provides a method for selecting block-producing nodes, which is applied in a distributed ledger network and can be executed by a third node in the distributed ledger network.

[0055] For example, the third node is a terminal (or a module in a terminal), an access network device (or a module in an access network device), a core network device (or a module in a core network device), or an independent server (or a module in a server) deployed in the access network or core network.

[0056] The method includes: a third node receiving the verification result from a second node in the distributed ledger network, determining a second result based on the second node's verification result, and sending the second result in the distributed ledger network. The second result is used to determine whether the first node is a block-producing node in the distributed ledger network. The second node's verification result is generated by the second node based on the first result, and the first result is generated by the first node based on the first task.

[0057] For example, a third node sends a second result to the first and second nodes in a distributed ledger network.

[0058] Sixthly, embodiments of this application provide a device for selecting block-producing nodes.

[0059] The device has the function of implementing the first node in any possible implementation of the first aspect, and the device can be the aforementioned first node. Alternatively, the device has the function of implementing the first node in any possible implementation of the second aspect, and the device can be the aforementioned first node. Alternatively, the device has the function of implementing the second node in any possible implementation of the third aspect, and the device can be the aforementioned second node. Alternatively, the device has the function of implementing the fourth node in any possible implementation of the fourth aspect, and the device can be the aforementioned fourth node. Alternatively, the device has the function of implementing the third node in any possible implementation of the fifth aspect, and the device can be the aforementioned third node.

[0060] The function of the above-mentioned block selection device can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules, units or means corresponding to the above functions.

[0061] In one possible implementation, the device includes a processing module and a transceiver module. The processing module is configured to support the device in performing the functions corresponding to the first node in the first aspect or any implementation of the first aspect, or performing the functions corresponding to the first node in the second aspect or any implementation of the second aspect, or performing the functions corresponding to the second node in the third aspect or any implementation of the third aspect, or performing the functions corresponding to the fourth node in the fourth aspect or any implementation of the fourth aspect, or performing the functions corresponding to the third node in the fifth aspect or any implementation of the fifth aspect.

[0062] The transceiver module supports communication between the device and other nodes; for example, when the device is the first node, it can send the first result. The block-producing node selection device may also include a storage module coupled to the processing module, which stores the necessary program instructions and data for the device. As an example, the processing module can be a processor, the communication module can be a transceiver, and the storage module can be a memory. The memory can be integrated with the processor or separated from it.

[0063] In another possible implementation, the device includes a processor and may also include a memory. The processor is coupled to the memory and can be used to execute computer program instructions stored in the memory to cause the device to perform the method in the first aspect or any possible implementation thereof, or to perform the method in the second aspect or any possible implementation thereof, or to perform the method in the third aspect or any possible implementation thereof, or to perform the method in the fourth aspect or any possible implementation thereof, or to perform the method in the fifth aspect or any possible implementation thereof.

[0064] Optionally, the device also includes a communication interface, to which the processor is coupled.

[0065] When the device is a terminal, access network equipment, core network equipment, or server, the communication interface can be a transceiver or an input / output interface; when the device is a chip contained in a terminal, access network equipment, core network equipment, or server, the communication interface can be the chip's input / output interface. Optionally, the transceiver can be a transceiver circuit, and the input / output interface can be an input / output circuit.

[0066] Seventhly, embodiments of this application provide a chip system, including:

[0067] The processor and memory are coupled together. The memory is used to store programs or instructions. When the program or instructions are executed by the processor, the chip system implements the method of the first aspect or any possible implementation of the first aspect, or implements the method of the second aspect or any possible implementation of the second aspect, or implements the method of the third aspect or any possible implementation of the third aspect, or implements the method of the fourth aspect or any possible implementation of the fourth aspect, or implements the method of the fifth aspect or any possible implementation of the fifth aspect.

[0068] Optionally, the chip system also includes an interface circuit for exchanging code instructions with the processor.

[0069] Optionally, the chip system may include one or more processors, which can be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor that reads software code stored in memory.

[0070] Optionally, the chip system may contain one or more memories. These memories may be integrated with the processor or disposed separately. For example, the memory may be a non-transitory processor, such as read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on separate chips.

[0071] Eighthly, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed by a block-producing node selection device, cause the block-producing node selection device to perform the method in the first aspect or any possible implementation thereof, or perform the method in the second aspect or any possible implementation thereof, or perform the method in the third aspect or any possible implementation thereof, or perform the method in the fourth aspect or any possible implementation thereof, or perform the method in the fifth aspect or any possible implementation thereof.

[0072] Ninthly, this application provides a computer program product comprising a computer program or instructions that, when executed by a block selection device, implement the method in the first aspect or any possible implementation of the first aspect, or implement the method in the second aspect or any possible implementation of the second aspect, or implement the method in the third aspect or any possible implementation of the third aspect, or implement the method in the fourth aspect or any possible implementation of the fourth aspect, or implement the method in the fifth aspect or any possible implementation of the fifth aspect.

[0073] In a tenth aspect, this application provides a communication system including one or more of a first node, a second node, a third node, and a fourth node. The first node is configured to execute the method in the first aspect or any possible implementation thereof, or to execute the method in the second aspect or any possible implementation thereof; the second node is configured to execute the method in the third aspect or any possible implementation thereof; the fourth node is configured to execute the method in the fourth aspect or any possible implementation thereof; and the third node is configured to execute the method in the fifth aspect or any possible implementation thereof.

[0074] The technical features described in aspects one through ten above can be referenced interchangeably. The technical effects achievable in any of aspects two through ten above can also be described with reference to the beneficial effects described in aspect one above. Further details will not be repeated here. Attached Figure Description

[0075] Figure 1 is a schematic diagram of a communication system architecture provided in this application;

[0076] Figure 2 is a flowchart illustrating the first method for selecting block-producing nodes provided in this application;

[0077] Figure 3 is a flowchart illustrating the second method for selecting block-producing nodes provided in this application;

[0078] Figure 4 is a flowchart illustrating the third method for selecting block-producing nodes provided in this application;

[0079] Figure 5 is a flowchart illustrating the fourth method for selecting block-producing nodes provided in this application;

[0080] Figure 6 is an interaction flowchart of a module within a first node provided in this application;

[0081] Figure 7 is an interaction flowchart of a module within a second node provided in this application;

[0082] Figure 8 is an interaction flowchart of a module within the fourth node provided in this application;

[0083] Figure 9 is a schematic diagram of the structure of a block selection device provided in this application;

[0084] Figure 10 is a structural schematic diagram of another block selection device provided in this application. Detailed Implementation

[0085] The relevant technical features involved in the embodiments of this application will be explained below. It should be noted that these explanations are for the purpose of making the embodiments of this application easier to understand, and should not be regarded as a limitation on the scope of protection claimed by this application.

[0086] I. Distributed Ledger: A distributed ledger is a database maintained by multiple nodes to record transactions between network participants, ensuring data consistency and security. Unlike traditional centralized databases, distributed ledgers do not have a social authority managing the data. Instead, they rely on each node in the network to jointly verify, store, and update the data, thus improving data transparency, security, and immutability.

[0087] II. Distributed Ledger Network: A network comprised of devices that participate in maintaining and / or querying a distributed ledger. Devices participating in a distributed ledger network (such as network functions (NFs), radio access network (RAN) nodes, servers, etc.) may directly maintain and query the distributed ledger (i.e., possess one or more of the following permissions: consensus, querying, or writing to the distributed ledger), or they may participate in maintaining and querying the distributed ledger through other devices (i.e., they themselves do not possess consensus, querying, or writing permissions to the distributed ledger, but can perform the above operations through other devices, such as terminals, etc.).

[0088] III. Smart Contracts: These are contracts that execute automatically, based on distributed ledger technology. When the execution conditions are met, a smart contract can be automatically triggered. A smart contract includes code and a data set, and it can be deployed and run on a distributed ledger network. A smart contract is more like a program; for example, when the distributed ledger network is Ethereum, smart contracts are executed through the Ethereum Virtual Machine.

[0089] IV. Wireless Network Computing

[0090] Wireless network computing refers to a series of complex computing tasks performed by devices in a wireless network environment, such as resource optimization, content distribution, and edge computing. These tasks aim to improve network performance, reduce latency, and enhance the efficiency and reliability of data processing.

[0091] Wireless network computing has the following characteristics:

[0092] ① Node heterogeneity: There are many types of devices in wireless networks, such as Internet of Things (IoT) devices and edge servers, which have different computing capabilities, storage capabilities and energy resources;

[0093] ② Resource efficiency: Under normal circumstances, the resources of devices in a wireless network are highly matched with their needs, ensuring the best utilization of computing resources;

[0094] ③ Dynamic network topology: Due to the mobility of devices in wireless networks and the instability of wireless signals, the topology of wireless networks often changes, which places higher demands on computing task scheduling, data transmission, and other aspects.

[0095] V. Content Delivery Network (CDN)

[0096] Caching optimization focuses on how to store and manage frequently accessed data on network nodes. A well-designed caching strategy can reduce data transmission, lower latency, improve system responsiveness, enhance the user experience for mobile users, and reduce network traffic load.

[0097] VI. Image Data Processing Technology

[0098] Image data analysis and processing mainly includes operations such as image enhancement, filtering, segmentation, feature extraction, and pattern recognition. In wireless networks, it is commonly used in scenarios requiring rapid identification, analysis, and decision-making, such as real-time monitoring, smart cities, intelligent transportation systems, and drone navigation.

[0099] VII. Network Routing Path Optimization

[0100] By selecting the optimal data transmission path, latency and packet loss during data transmission are effectively reduced, improving data transmission efficiency and stability. Simultaneously, it can cope with dynamic changes in network conditions, such as node movement and signal fluctuations, ensuring efficient utilization of network resources and improved user experience.

[0101] 8. Mobile Edge Computing (MEC): A technology that provides services and cloud computing capabilities to users at the edge of a wireless access network. For example, an MEC server is associated with a base station to handle urgent and high-volume processing tasks that need to be processed within the base station. Taking autonomous driving as an example, an autonomous vehicle captures video signals through cameras and sends them to a base station. The base station then sends the video signals to the MEC server. The MEC server processes the video signals and adjusts driving conditions according to rules, while a remote server can perform tasks such as remote driving and rule updates.

[0102] In addition, the MEC architecture can also be used in scenarios such as augmented reality (AR), virtual reality (VR), high-definition live streaming, video surveillance, and drones to improve processing speed.

[0103] Figure 1 is an architecture diagram of a communication system provided in an embodiment of this application.

[0104] As shown in Figure 1, the communication system includes: a terminal, access network (AN) equipment, and core network (CN) equipment. The terminal can access the data network (DN) through the access network equipment and the core network equipment.

[0105] It is understandable that terminals and access network devices are located in the access network.

[0106] In the embodiments of this application, a terminal may also be referred to as user equipment (UE), access terminal, subscriber unit, user station, mobile station, mobile station (MS), remote station, remote terminal, mobile device, user terminal, terminal equipment, wireless communication equipment, user agent, or user device.

[0107] A terminal can be a device that provides wireless communication capabilities, such as a handheld device or an in-vehicle device with wireless connectivity. Currently, examples of terminals include: mobile phones, satellite mobile terminals, cellular phones, smartphones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), in-vehicle equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, VR devices, AR devices, smart point-of-sale (POS) machines, customer-premises equipment (CPE), wireless terminals in industrial control, wireless terminals in self-driving cars, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes (such as refrigerators, televisions, air conditioners, electricity meters, etc.), smart robots, robotic arms, cellular phones, cordless phones, and session initiation protocols. The embodiments of this application are not limited to the following: SIP (Search Engine Protocol) telephones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, flying devices (e.g., intelligent robots, hot air balloons, drones, airplanes), terminals in the 5th generation (5G) network, or terminals in future evolved public land mobile networks (PLMNs). As an example and not a limitation, in the embodiments of this application, the terminal can also be a mobile termination (MT) in an integrated access and backhaul (IAB) node. When an IAB node faces its parent node, it can be regarded as a terminal; in this case, the IAB node acts as an MT.

[0108] In this application, an access network device is a device that provides wireless communication functionality to a terminal. As a node in a wireless access network, the access network device can also be referred to as a base station, RAN node (or device), or access point (AP). The access network device helps the terminal achieve wireless access. A communication system may include multiple access network devices, which can be nodes of the same type or different types. In some scenarios, the roles of the access network device and the terminal are relative. For example, network element #A can be a helicopter or drone, which can be configured as a mobile base station and access the RAN through network element #B. For terminals accessing the RAN through network element #A, network element #A is a base station; but for network element #B, network element #A is a terminal. Access network devices and terminals are sometimes referred to as block output node selection devices. In one possible scenario, access network equipment can be a base station, an evolved NodeB (eNodeB), a transmitting and receiving point (TRP), a transmitting point (TP), a next-generation NodeB (gNB), a base station in a future mobile communication system, a satellite, or an access point (AP) in a wireless fidelity (WiFi) system, an IAB node, or an access network device in a mobile switching center non-terrestrial network (NTN) communication system; that is, it can be deployed on high-altitude platforms or satellites. Access network equipment can be a macro base station, a micro base station or indoor station, a relay node or donor node, or a radio controller in a cloud RAN (CRAN) scenario. Access network equipment can also function as a base station in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, or machine-to-machine (M2M) communication. Optionally, access network equipment can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU).

[0109] Access network devices and terminals can be fixed in location or mobile. They can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can be deployed in the air on aircraft, balloons, and artificial satellites. The embodiments of this application do not limit the application scenarios of the access network devices and terminals.

[0110] In this application, core network equipment refers to network elements included in the core network portion of a mobile communication system. For example, core network equipment includes network elements (NFs) and user plane functions (UPFs) within the core network portion. Core network equipment enables terminals to access different data networks and performs services such as billing, mobility management, session management, and user plane forwarding. Currently, some examples of NFs include: unified data management (UDM), unified data repository (UDR), network exposure function (NEF), application function (AF), policy control function (PCF), access and mobility management function (AMF), session management function (SMF), and network repository function (NRF).

[0111] In the embodiments of this application, the form of the terminal device is not limited. The device used to implement the functions of the terminal can be the terminal itself, or it can be any device that supports the terminal in implementing the functions of the terminal, such as a chip system. This device can be installed in the terminal or used in conjunction with the terminal. The form of the access network device is not limited. The device used to implement the functions of the access network device can be the access network device itself, or it can be any device that supports the access network device in implementing the functions of the access network device, such as a chip system. This device can be installed in the access network device or used in conjunction with the access network device. The form of the core network device is not limited. The device used to implement the functions of the core network device can be the core network device itself, or it can be any device that supports the core network device in implementing the functions of the core network device, such as a chip system. This device can be installed in the core network device or used in conjunction with the core network device. The chip system can be composed of chips or can include chips and other discrete components.

[0112] To introduce a distributed ledger network, the communication system may also include a ledger anchor function (LAF). Optionally, the communication system may also include at least one of the following: an enabler and a client.

[0113] A Logical Application (LAF) is the anchor point for the overall management and association of distributed ledger technology. It can perform management functions, creation, access control, registration management of enabled modules, and activation of enabled modules. For example, an LAF can be deployed in the core network in the form of a Network Function (NF). Another example is that an LAF can have a hierarchical structure; for instance, some LAFs are deployed in the core network, and others are deployed in the access network; that is, some LAFs are core network devices or modules within core network devices, and others are access network devices or modules within access network devices.

[0114] The enabling module, which can be configured and managed by LAF, differentiates the permissions of different nodes based on their capabilities. For example, the enabling module has one or more of the following functions: deploying and executing smart contracts, consensus, block synchronization, block storage, etc. The enabling module can reside in nodes within the communication system, for example, in one or more terminals, access network devices, or NFs. All nodes with distributed ledger capabilities can deploy the enabling module. Optionally, in the core network, the enabling module can also function as an independent NF, providing proxy capabilities to other NFs. Optionally, in the access network, the enabling module can also function as an independent node, providing proxy capabilities to other access network devices.

[0115] The client, which can be configured and managed by the LAF, performs transaction generation and transmission functions. The client can reside in nodes of the communication system, such as terminals, access network devices, or one or more NFs. All nodes with distributed ledger capabilities can deploy clients. Optionally, in the core network, the client can also function as an independent NF, providing transaction generation capabilities to other NFs. Optionally, in the access network, the client can also function as an independent node, providing transaction generation capabilities to other access network devices.

[0116] It is understood that the aforementioned network element or function can be either a network component in a hardware device or a logical function. As one possible implementation method, the aforementioned network element or function can be implemented by one device, or by multiple devices working together, or it can be a functional module within a device. This application embodiment does not specifically limit this.

[0117] It should be noted that the communication system shown in Figure 1 does not constitute a limitation on the communication systems to which the embodiments of this application can be applied. Therefore, the communication method provided in the embodiments of this application can also be applied to various communication systems, such as: Long Term Evolution (LTE) communication systems, 5G communication systems and future communication systems, V2X, LTE-vehicle (LTE-V), vehicle-to-vehicle (V2V), vehicle-to-everything (V2V), machine-type communications (MTC), internet of things (IoT), LTE-machine-to-machine (LTE-M), machine-to-machine (M2M), IoT, NTN systems, etc. Furthermore, it should be noted that the embodiments of this application do not limit the names of the network elements in the communication system. For example, in different communication systems, each network element may have other names; and for example, when multiple network elements are integrated into the same physical device, the physical device may also have other names. Those skilled in the art will understand that, with the evolution of network architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems. When applying the technical solutions of the embodiments of this application to other communication systems, the devices, components, modules, etc. in the embodiments can be replaced with corresponding devices, components, modules in other communication systems without limitation.

[0118] This application provides a method for selecting block-producing nodes, which is used to select block-producing nodes from multiple nodes in a distributed ledger network in a scenario combining distributed ledger technology and wireless communication technology, and helps to save computing resources and communication resources in wireless networks.

[0119] Figure 2 is a flowchart illustrating the first method for selecting block-producing nodes provided by this application.

[0120] This process can be applied to distributed ledger networks, or understood as the method by which nodes in a distributed ledger network select block-producing nodes. Optionally, nodes in a distributed ledger network can execute a round of block-producing node selection every first preset time interval. This first preset time interval is determined based on the block production interval of the distributed ledger network; for example, the first preset time interval is equal to one or more of these interval intervals. For another example, if the block production interval of the distributed ledger network is 5 seconds, meaning a new block is submitted to the distributed ledger every 5 seconds, then nodes in the distributed ledger network can execute a round of block-producing node selection every 5 seconds.

[0121] A distributed ledger network may include a first node, which can be used to obtain tasks from a task pool, execute tasks, etc. Optionally, the first node may also obtain transactions from a transaction pool, execute transactions, package transactions or transaction results into blocks, send blocks, etc. The first node may be a terminal (or a module in a terminal) shown in Figure 1, an access network device (or a module in an access network device), or a core network device (or a module in a core network device). In addition, the first node may also be an independent server (or a module in a server) in the access network or core network shown in Figure 1.

[0122] Step 201: The first node generates the task result corresponding to the first task (denoted as the first result) based on the first task.

[0123] For example, the first task is a network management task related to the operator's network. For example, the network management task further includes one or more of the following: network computing tasks, network operation and maintenance tasks, and network configuration tasks. Correspondingly, the first result can be network computing results, network operation and maintenance policies, and network configuration information / parameters. Among these, network computing tasks include, for example, mobile edge computing tasks, and network configuration tasks include, for example, routing optimization tasks, cache optimization tasks, and resource (such as radio resources and / or computing resources) allocation tasks.

[0124] For example, the first task is a task that provides services to the user; that is, the first task is a task that the user submits to the network, hoping that the network will assist in the computation. Examples of tasks that provide services to the user include image data / optimization processing tasks and model computation tasks.

[0125] Alternatively, the first task can be understood as a task within the resource allocation type, cache optimization type, image data processing type, routing optimization type, model calculation type, or mobile edge computing type.

[0126] The following explanation, based on the parameters included in the first task, details the first result corresponding to the first task:

[0127] Example 1: The first task includes task data, and the first result is the result calculated based on the task data.

[0128] For example, the first task is a task in the mobile edge computing type. The task data includes, but is not limited to, one or more of the following: data size, computational intensity (e.g., the size of the central processing unit (CPU) required per byte), edge computing type, and input data; the first result is the task result determined by the first node.

[0129] Example 2: The first task includes task data and task objectives, and the first result is the result of achieving the task objectives based on the task data.

[0130] For example, the first task is a cache optimization task, such as optimizing the caching of data stored in the CDN network. Task data includes, but is not limited to, one or more of the following: the size of data that each device in the network (or each layer of cache within a device, such as L1 and L2 caches) can cache, the size of each piece of data, the calling relationships between the pieces of data, and the frequency with which each piece of data is accessed by users; task objectives include, but are not limited to, one or more of the following: cache hit rate, and the average access latency when multiple pieces of data are accessed. The first result is the caching strategy determined by the first node when caching multiple pieces of data.

[0131] For example, the first task is a task in the image data processing type. The task data includes, but is not limited to, one or more of the following: the size of the image to be processed, the number of channels of the image to be processed, and the processing requirements; the task objectives include, but are not limited to, one or more of the following: the processing time requirements, the processing accuracy requirements, and the required memory overhead requirements when processing the image to be processed; the first result is the image processing algorithm determined by the first node.

[0132] Example 3: The first task includes task data, task objectives, and task constraints; the first result is the result that achieves the task objectives and satisfies the task constraints based on the task data.

[0133] For example, the first task is a task in the route optimization type. The task data includes, but is not limited to, one or more of the following: the network topology that needs to transmit data, the originating node of the data, and the destination node of the data; the task constraints include, but are not limited to, routing constraints; the task objective includes average routing delay; and the first result is the routing strategy determined by the first node.

[0134] For example, when the first node generates the first result corresponding to the first task, it can follow these steps: ① Select a computation algorithm: The first node selects a suitable computation algorithm based on its own configuration to solve the first task; ② Initialize parameters: The first node initializes the necessary parameters according to the requirements of the first task; ③ Execute task solving: The first node uses its own computing power to perform calculations and obtain a task result that meets the task objective (satisfies the task objective and task constraints) as quickly as possible. It can be understood that during the processing, the first node continuously evaluates intermediate results.

[0135] Optionally, prior to step 201, the method further includes:

[0136] Step 200: The first node obtains the first task from the task pool.

[0137] The task pool can be considered as a cache for the first node, and the executors in the first node can obtain the first task from the cache. For example, the task pool can be managed by a task pool management contract deployed in the first node. The executors in the first node send a task retrieval request to the task pool management contract, and the task pool management contract responds to the request by returning the first task to the executors. For ease of description, the following explanation will use the example of the first node obtaining the first task from the task pool.

[0138] For example, the task pool may include multiple tasks, which are ordered according to their submission time. The first node can obtain the first submitted task (i.e., the first task) from the task pool. Furthermore, the first node can obtain tasks from the task pool based on a first preset time interval. For example, the first node obtains one task from the task pool every first preset time interval.

[0139] For example, multiple tasks in the task pool can correspond to multiple task types. The first node can select the task that corresponds to its node type and is submitted first (i.e., the first task) from the multiple tasks, based on its own node type and the types of the multiple tasks. For example, if the first node is an edge server, the task type it selects from the task pool could be a cache optimization type; if the first node is an access network device, the task type it selects from the task pool could be a resource allocation type; if the first node is a routing server, the task type it selects from the task pool could be a routing optimization type.

[0140] It is understandable that each node in a distributed ledger network can have its own task pool, and each node's task pool can be managed by a task pool management contract deployed on that node. Based on the synchronization mechanism of the distributed ledger network, when a new task is submitted to a node's task pool, the new task will be broadcast to the task pools of other nodes by that node's task pool management contract. That is, the tasks in the task pools of any two nodes in the distributed ledger network are the same. In this application, the node's operation on the task pool specifically refers to the node's operation on its own task pool (or the task pool of that node in the distributed ledger network).

[0141] Similarly, each node in a distributed ledger network can have its own transaction pool. A node's transaction pool can be considered as a cache for that node. The operation of a node on the transaction pool specifically refers to the operation of the node on its own transaction pool (or the transaction pool of that node in the distributed ledger network).

[0142] Optionally, the distributed ledger network also includes a fourth node, which can be a task submission node in the distributed ledger network. The fourth node can submit tasks to the distributed ledger network. The fourth node can be a terminal (or a module in a terminal) shown in Figure 1, an access network device (or a module in an access network device), or a core network device (or a module in a core network device). In addition, the fourth node can also be an independent server (or a module in a server) in the access network or core network shown in Figure 1. For example, the client in Figure 1 exists in the fourth node.

[0143] Optionally, prior to step 200, the following steps are also included:

[0144] Step A: The fourth node generates the first task.

[0145] For example, when generating the first task, the fourth node may specifically generate the first task based on the parameter format corresponding to the task type of the first task. For instance, if the task type of the first task is image data processing, the fourth node may encapsulate the size of the image to be processed, the number of channels of the image to be processed, the processing requirements, the processing time requirements, the processing accuracy requirements, and the required memory overhead requirements into the first task based on the parameter format corresponding to the image data processing type.

[0146] For example, before generating the first task, the fourth node can first obtain configuration information, which includes parameter formats corresponding to multiple types, including the task type of the first task. Further, the fourth node first determines the parameter format corresponding to the task type of the first task from the configuration information based on the task type of the first task.

[0147] For example, the fourth node includes a task pool management contract and an executor. The task pool management contract of the fourth node includes configuration information, which the executor can obtain. The executor then determines the parameter format corresponding to the task type of the first task based on the configuration information and the task type of the first task, and then generates the first task.

[0148] Step B: The fourth node sends the first task.

[0149] Accordingly, all nodes in the distributed ledger network except the fourth node (including the first node) receive the first task.

[0150] In one possible approach, the fourth node also deploys a task submission contract. This contract receives the first task sent by the fourth node's executor and submits it to the fourth node's task pool. Further, the fourth node's task pool management contract sends the first task within the distributed ledger network. For example, after receiving the first task, the fourth node's task submission contract can also validate its format. If the validation passes, the contract submits the first task to the fourth node's task pool. If the validation fails, the contract can return an error code to the fourth node's executor.

[0151] Specifically, the task pool management contract of the fourth node sends the first task in the distributed ledger network. This can be done by broadcasting the first task in the distributed ledger network, and correspondingly, other nodes in the distributed ledger network (including the first node) other than the fourth node receive the first task; or, the task pool management contract of the fourth node sends the first task to each of the other nodes in the distributed ledger network according to the identifier of the other nodes in the distributed ledger network.

[0152] Taking the first node receiving and processing the first task as an example, in one example, the first node receives the first task and places it in the cache. For example, the task pool management module of the first node receives the first task and places it in the task pool of the first node. When the executor of the first node needs to process the first task, it can request the first task from the task pool management module of the first node. In another example, after receiving the first task, the first node does not place the first task in the cache, but processes the first task directly. For example, the executor of the first node receives and processes the first task.

[0153] Here, the sending of the first task by the task pool management contract of the fourth node is considered a specific implementation of the sending of the first task by the fourth node. For ease of description, the following explanation will use the sending of the first task by the fourth node as an example.

[0154] Optionally, the distributed ledger network also includes a second node, which can verify the task execution results of the first node. Furthermore, the second node can obtain tasks from a task pool and execute them. There can be one or more second nodes. The second node can be a terminal (or a module within a terminal) as shown in Figure 1, an access network device (or a module within an access network device), or a core network device (or a module within a core network device). Additionally, the second node can also be an independent server (or a module within a server) in the access network or core network as shown in Figure 1.

[0155] Step 202: The first node sends the first result, and correspondingly, the second node receives the first result. The first result is used to determine whether the first node is a block-producing node, which generates blocks for the distributed ledger based on transactions in the transaction pool.

[0156] For example, a result submission contract is deployed in the first node, and a task verification contract is deployed in the second node. The first node sends the first result in the distributed ledger network; specifically, the result submission contract of the first node sends the first result in the distributed ledger network, and correspondingly, the task verification contract of the second node receives the first result. The receiving of the first result by the task verification contract of the second node is considered a specific implementation of the second node receiving the first result. For ease of description, the following explanation uses the second node receiving the first result as an example.

[0157] Specifically, the first node's result submission contract sends the first result in the distributed ledger network. This can be achieved by either broadcasting the first result in the distributed ledger network or by sending the first result to multiple nodes (including the second node) in the distributed ledger network according to their identifiers. Here, the sending of the first result by the first node's result submission contract is considered a specific implementation of the first node sending the first result; the following explanations will use the first node sending the first result as an example.

[0158] The following flowcharts, in conjunction with Figures 3 and 4, explain how the first result is used to determine whether the first node is a block-producing node. Figure 3 shows the determination of whether the first node is a block-producing node by the first node and / or the second node; Figure 4 shows the determination of whether the first node is a block-producing node by the third node. The third node, within the block production execution mechanism, can statistically analyze whether the task execution result of the first node has been verified by other nodes, thereby determining whether the first node is a block-producing node (i.e., a node with accounting rights). The third node can be a terminal (or a module within a terminal) shown in Figure 1, an access network device (or a module within an access network device), or a core network device (or a module within a core network device). Furthermore, the third node can also be an independent server (or a module within a server) in the access network or core network shown in Figure 1.

[0159] Figure 3 is a flowchart illustrating the second method for selecting block-producing nodes provided by this application:

[0160] Step 301: The second node determines the verification result of the second node based on the first result.

[0161] For example, the second node determines its verification result based on the first task and the first result. The first task is received by the second node in step B above. In a specific implementation, the second node's task verification contract determines its verification result based on the first task and the first result. For ease of description, the following explanation uses the example of the second node determining its own verification result.

[0162] The following describes the verification results for determining the second node, based on the parameters included in the first task and the first result:

[0163] In the first example, the first task includes task data and task objective; the second node determines that the verification result of the second node is successful if the first result achieves the task objective based on the task data.

[0164] For example, the first task is to solve an algorithm optimization problem, where the task objective is the optimization goal, the first result is the optimization method determined by the first node, and the second node determines whether the optimization method satisfies the optimization goal. Another example is a path planning task, where the task objective is a preset path rule, the first result is the path planned by the first node, and the second node verifies whether the planned path conforms to the preset path rule. Yet another example is a sorting task, where the task objective is a correct sorting result, the first result is the sorting algorithm determined by the first node that achieves the task objective, and the second node verifies whether the sorting result obtained based on the sorting algorithm is a correct sorting result.

[0165] Here, the second node can be considered as a result condition verification, which determines the verification result based on the task objective.

[0166] In the second example, the first task includes task data, task objectives, and task constraints. The second node determines that its verification result is successful if the first result achieves the task objective and satisfies the task constraints based on the task data. That is, building upon the example above, the second node can further determine whether the first result satisfies the task constraints. For example, if the task constraint is a specified range, the second node can also determine whether the first result falls within that specified range.

[0167] Here, the second node can be considered as a result constraint verification, which further determines the verification result based on the task objective.

[0168] For example, before performing result condition verification (or result condition verification and result constraint verification) on the first result, the second node may also perform integrity verification on the first result. For example, before sending the first result, the first node calculates the hash of the first result and sends the first result and its hash together; correspondingly, the second node may first verify the integrity of the first result based on its hash, and after determining that the first result has passed the integrity verification, then perform result condition verification (or result condition verification and result constraint verification) on the first result.

[0169] For example, before performing result condition verification (or result condition verification and result constraint verification) on the first result, the second node may also perform signature verification on the first result to ensure that the first result was generated by the first node. For example, before sending the first result, the first node signs the first result using its private key and sends the first result and its signature together; correspondingly, the second node may first verify that the first result was generated by the first node based on the signature of the first result and the public key of the first node, and after determining that the first result has passed the signature verification, then perform result condition verification (or result condition verification and result constraint verification) on the first result.

[0170] As another example, before performing result condition verification (or result condition verification and result constraint verification) on the first result, the second node may also perform integrity verification and signature verification on the first result. For instance, after the second node determines that the first result has passed signature verification, it performs integrity verification on the first result; and after determining that the first result has passed integrity verification, it performs result condition verification (or result condition verification and result constraint verification) on the first result. The integrity verification and signature verification can be referred to the description in the example above.

[0171] For example, the second node includes a task verification contract. The task verification contract of the second node receives the first result sent by the first node, verifies the first result, and generates a verification result. That is, step 301 can be specifically executed by the task verification contract of the second node.

[0172] Step 302: The second node sends its verification result. Correspondingly, the third node receives the verification result from the second node.

[0173] For example, a result submission contract is deployed in the second node. The second node sends its verification result in the distributed ledger network. Specifically, the result submission contract of the second node sends its verification result in the distributed ledger network. Here, the sending of the verification result by the second node's result submission contract is considered a specific implementation of the second node sending its own verification result. For ease of description, the following explanation will use the example of the second node sending its own verification result.

[0174] For example, the second node sends its verification result in the distributed ledger network. Specifically, the second node broadcasts its verification result in the distributed ledger network, and correspondingly, other nodes in the distributed ledger network (such as the third node) receive the verification result of the second node. Alternatively, the second node can send its verification result to the third node based on the identifier of the third node, and correspondingly, the third node receives the verification result of the second node.

[0175] Step 303: The third node determines the second result based on the verification result of the second node.

[0176] For example, the second result is used to indicate that the first node is a block-producing node. Alternatively, it can be understood that the second result is generated when the third node determines that the first node is a block-producing node based on the verification result of the second node.

[0177] It should be noted that the second node is a node in the distributed ledger network that verifies the first result and sends the verification result. There can be multiple second nodes. For example, the third node can receive the verification results from multiple second nodes and determine the first node as the block-producing node in the distributed ledger network based on the verification results from multiple second nodes.

[0178] For example, when the third node determines that the percentage of verified results exceeds a preset percentage, it designates the first node as the block-producing node. The preset percentage is, for example, 2 / 3. For instance, multiple second nodes are denoted as second node 1, second node 2, second node 3, and second node 4. Second node 1's verification result is verified, second node 2's verification result is verified, second node 3's verification result is verified, and second node 4's verification result is verified. After determining that the percentage of verified results exceeds the preset percentage of 2 / 3, the third node designates the first node as the block-producing node.

[0179] In addition, there may be a situation where a second node determines the task result corresponding to the first task earlier than the first node determines the first result. The second node can send the task result it determines in the distributed ledger network, and other second nodes and the first node will verify the task result. However, the percentage of the task result that passes verification does not exceed the preset percentage.

[0180] Based on the above example, the second node 4 determines the task result corresponding to the first task (denoted as task result 4). The second node 4 sends task result 4 in the distributed ledger network. The first node, second node 1, second node 2, and second node 3 verify task result 4 respectively and send their respective verification results to the third node. Among them, the verification result of the first node is verification failure, the verification result of the second node 1 is verification success, the verification result of the second node 2 is verification failure, and the verification result of the second node 3 is verification failure. After determining that the percentage of verification success does not exceed a preset percentage of 2 / 3, the third node determines that the second node 4 is not a block producing node.

[0181] It should also be added that the verification result can be not only verification passed or failed, but also an evaluation metric for the task result, or include both verification pass / fail and evaluation metrics. This means that in step B above, the first task can be received by multiple nodes in the distributed ledger network, and each of these nodes can process the first task individually. For example, the multiple nodes include a first node, a second node 1, a second node 2, and a second node 3, and each of these nodes processes the first task individually.

[0182] In one possible example, during the block production node selection process, the first node determines the first result corresponding to the first task, while the second nodes 1, 2, and 3 have not determined the task result corresponding to the first task. The first node sends the first result, and then the second nodes 1, 2, and 3 verify the first result and obtain their respective verification results (e.g., verification passed or failed). Based on the respective verification results of the second nodes 1, 2, and 3, the third node determines the first node as the block production node.

[0183] In another possible example, during the block production node selection process, the first node determines the first result corresponding to the first task and sends the first result. The second node 1 determines the task result corresponding to the first task (denoted as task result 1) and sends task result 1. When the second nodes 1, 2, and 3 verify the first result, the verification results they obtain include not only whether the verification passed or failed, but also the evaluation metrics of the task result. Similarly, when the first node, 2, and 3 verify task result 1, the verification results they obtain may also include the evaluation metrics of the task result. Therefore, the third node can select the first node as the block production node from the first and second nodes 1 based on the verification results of the first result by the second nodes 1, 2, and 3, and the verification results of task result 1 by the first, second, and second nodes 2 and 3. For example, the third node determines that the task result with a pass rate greater than a preset rate and a good evaluation metric is the first result, and thus selects the first node as the block production node. The evaluation metrics include, for example, the degree to which the task result achieves the task objective, the time used by the node to calculate the task result, and the computing resources consumed.

[0184] In a block-producing node selection process, the block-producing node can be the node whose task result is first verified by the distributed ledger network; or it can be the node whose task result is verified by the distributed ledger network and has the best evaluation index. Here, the task result being verified by the distributed ledger network means that the task result is verified by a predetermined proportion of nodes in the distributed ledger network.

[0185] For ease of description, the following examples will use the example of each node determining whether the task results of other nodes have passed verification.

[0186] In step 304, the third node sends the second result. Correspondingly, the first and second nodes receive the second result.

[0187] Step 305: Based on the second result, the first node determines itself as a block-producing node in the distributed ledger network. The second node, based on the second result, also determines itself as a block-producing node in the distributed ledger network.

[0188] For example, when a second node receives a second result, it may be processing the first task or verifying the result of a first task sent by another second node. In this case, the second node can stop processing the above operations and obtain a new task in the next round of block-producing node selection. For example, the second node can delete the first task from the task pool.

[0189] Alternatively, in step 304 above, the third node broadcasts the second result in the distributed ledger network, and all other nodes in the distributed ledger network besides the third node can receive the second result. In step 305 above, all other nodes in the distributed ledger network besides the third node can determine the first node as the block-producing node in the distributed ledger network based on the second result.

[0190] Step 306: The first node generates a block based on the transactions in the transaction pool.

[0191] For example, the first node obtains a transaction from the transaction pool and packages the transaction into a block, where the transaction is, for example, writing a piece of data into the distributed ledger; as another example, the first node obtains a transaction from the transaction pool, executes the transaction, obtains the transaction result, and then packages the transaction result (or the transaction and the transaction result) into a block, for example, the transaction is account A transferring 100 to account B, the transaction result is account A losing 100 and account B gaining 100.

[0192] The transaction pool can be considered as a cache for the first node. The executor in the first node can obtain transactions from the cache and then generate blocks based on the transactions. The number of transactions here can be a preset number.

[0193] Step 307: The first node sends the block. Correspondingly, all other nodes in the distributed ledger network besides the first node can receive the block and submit it to their respective distributed ledgers.

[0194] Figure 4 is a flowchart illustrating the third method for selecting block-producing nodes provided by this application:

[0195] It should be noted that, for ease of description, Figure 4 exemplarily illustrates two second nodes (denoted as second node 1 and second node 2), and explains this embodiment through the interaction between the first node, second node 1, and second node 2. However, the number of second nodes in a distributed ledger network is not limited. The distributed ledger network in the related embodiment of Figure 3 also includes multiple second nodes.

[0196] Step 401: Based on the first result, second node 1 determines verification result 1. Based on the first result, second node 2 determines verification result 2. For details, please refer to the description in step 301.

[0197] Step 402: Second node 1 sends verification result 1. Correspondingly, first node and second node 2 receive verification result 1. Second node 2 sends verification result 2. Correspondingly, first node and second node 1 receive verification result 2.

[0198] Taking the second node 1 as an example, the second node 1 deploys a result submission contract and sends verification result 1 in the distributed ledger network. Specifically, the second node 1's result submission contract sends verification result 1 in the distributed ledger network. For ease of description, the following explanation uses the second node 1 sending verification result 1 as an example. For instance, the second node 1 broadcasts verification result 1 in the distributed ledger network, and correspondingly, the first node and the second node 2 in the distributed ledger network receive verification result 1. Alternatively, the second node 1 sends verification result 1 in the distributed ledger network based on the identifiers of the first node and the second node 2, and correspondingly, the first node and the second node 2 receive verification result 1. The second node 2 is similar to the second node 1.

[0199] Step 403: Based on verification result 1 and verification result 2, the first node determines itself as the block-producing node. The second node 1, based on verification result 1 and verification result 2, also determines itself as the block-producing node. It can be understood that the results determined by the first node, the second node 1, and the second node 2 are the same.

[0200] For example, when second node 1 determines that first node is the block-producing node based on verification result 1 and verification result 2, second node 1 may still be processing the first task or verifying the result corresponding to the first task sent by second node 2. In this case, second node 1 can stop processing the above operations and obtain a new task in the next round of block-producing node selection. For example, second node 1 can delete the first task from its task pool. Similarly, second node 2 can also delete the first task from its task pool.

[0201] The method by which the first node, second node 1, and second node 2 determine that the first node is a block-producing node can also be found in the description of step 303 above. For example, the first node, second node 1, and second node 2 can also determine that the second node 2 is not a block-producing node based on task result 2 generated by the second node 2. For example, the first node, second node 1, and second node 2 can also determine that the second node 1 is not a block-producing node based on task result 1 generated by the second node 1.

[0202] Furthermore, when the first node is a block-producing node, continue to execute steps 404 and 405 below.

[0203] Step 404: The first node generates a block based on the transactions in the transaction pool.

[0204] For a detailed implementation, please refer to the description in step 306.

[0205] Step 405: The first node sends a block.

[0206] For a detailed implementation, please refer to the description in step 307.

[0207] Optionally, if the first node is a block-producing node, the first result is published in the distributed ledger. For example, the first node may also publish the first result to the distributed ledger; or, in other words, the first node may submit the first result as a transaction to its transaction pool, and then the first node may package the first result as a transaction in the transaction pool into a block, and then publish the block in the distributed ledger. For example, the fourth node may also obtain the first result from the distributed ledger. For example, the fourth node may execute the first result.

[0208] It is understandable that, since the first node is the block-producing node, the first result generated by the first node can be used as the final result of the first task, which is then executed by the fourth result. For example, when the first task is a task of the cache optimization type and the first result is a caching strategy, the fourth node can cache the corresponding data according to the caching strategy; for example, when the first task is a task of the image data processing type and the first result is an image processing algorithm, the fourth node can process the image to be processed according to the image processing algorithm, etc.

[0209] The embodiments of this application are further described below:

[0210] Explanation 1:

[0211] In the relevant embodiments of Figure 3 above, the example of the third node determining the first node as the block producing node is used for illustration. Of course, the third node may also determine that the first node is not the block producing node, and determine that a certain second node is the block producing node.

[0212] For example, the third node determines that the first node is not a block-producing node when the percentage of successful verifications does not exceed a preset percentage, based on the verification results of multiple second nodes on the first result. For instance, the preset percentage is, for example, 2 / 3. For example, the multiple second nodes are denoted as second node 1, second node 2, second node 3, and second node 4. The verification results of second node 1, second node 2, and second node 3 are all unsuccessful, while the verification result of second node 4 is successful. After determining that the percentage of successful verifications does not exceed the preset percentage of 2 / 3, the third node determines that the first node is not a block-producing node.

[0213] For example, the third node determines that the first node is not a block-producing node based on the verification results (e.g., evaluation metrics) of the first result by multiple second nodes. For instance, the first node determines the first result corresponding to the first task, and second node 1 determines the task result corresponding to the first task (denoted as task result 1). When second nodes 1, 2, and 3 verify the first result, their verification results include the evaluation metrics of the first result. Similarly, when first nodes 1, 2, and 3 verify task result 1, their verification results include the evaluation metrics of task result 1. The third node can determine that the task result with the better evaluation metrics is task result 1 based on the evaluation metrics of second nodes 1, 2, and 3 for the first result, and the evaluation metrics of first nodes 2, 2, and 3 for task result 1, and thus determine second node 2 as the block-producing node.

[0214] Similarly, in the relevant embodiments of Figure 4 above, the first node or each of the second nodes determines the first node as the block producing node as an example. Of course, the first node or each of the second nodes may also determine that the first node is not the block producing node, and determine that a certain second node is the block producing node.

[0215] Explanation 2:

[0216] In a round of block-producing node selection process, if a node in the distributed ledger network (such as the first node and the second node) fails to determine the block-producing node (for example, if the block-producing node is not determined according to the first task), it can still determine the block-producing node according to a preset mechanism.

[0217] For example, in a distributed ledger network, if a node fails to determine a block-producing node based on the first task, one or more of the following possibilities may exist:

[0218] (1) Within the second preset time period, all candidate nodes in the distributed ledger network are unable to generate the corresponding task result based on the first task;

[0219] (2) Within the second preset time period, although some or all of the candidate nodes in the distributed ledger network generate the corresponding task results according to the first task, the task results of each candidate node fail to pass the verification of the distributed ledger network.

[0220] (3) Before the first preset time, all candidate nodes in the distributed ledger network are unable to generate the corresponding task result based on the first task;

[0221] (4) Before the first preset time, although some or all of the candidate nodes in the distributed ledger network generate the corresponding task results according to the first task, the task results of each candidate node fail to pass the verification of the distributed ledger network.

[0222] For example, the second preset duration is determined based on the block production interval of the distributed ledger network. For instance, the second preset duration may be less than or equal to the first preset duration. For instance, the first preset time is determined by the distributed ledger network based on the time of the next block production. For instance, the first preset time is the time of the next block production minus the third preset duration.

[0223] For example, a candidate node is a node in a distributed ledger network that has the ability to produce blocks. In this embodiment of the application, a node is selected as the block-producing node from among the multiple candidate nodes. For example, the first node and multiple second nodes are both candidate nodes. For example, the first node is a candidate node, and some of the second nodes are candidate nodes, while the remaining second nodes (which may be called verification nodes) are used to participate in the verification of task results and do not compete for the block-producing node (that is, they do not process the first task).

[0224] For example, the preset mechanism includes one or more of the following:

[0225] (1) A mechanism for taking turns selecting nodes as block-producing nodes, for example, the first node selects block-producing nodes in a preset order;

[0226] (2) A mechanism for randomly selecting nodes as block-producing nodes. For example, the first node determines the hash value of the previous block published to the distributed ledger and determines the block-producing node based on the hash value of that block.

[0227] (3) Mechanism for selecting fixed nodes as block producing nodes;

[0228] (4) Mechanism for selecting block-producing nodes based on the proof of work (PoW) algorithm;

[0229] (5) Mechanism for selecting block-producing nodes based on the proof of stake (PoS) algorithm;

[0230] (6) A mechanism for selecting block-producing nodes based on the proof of authority (PoA) algorithm; or,

[0231] (7) Mechanism for selecting block nodes based on proof of coverage (PoC) algorithm.

[0232] Thus, in a round of block-producing node selection process, if a node in the distributed ledger network (such as the first node and the second node) fails to determine the block-producing node, it can still determine the block-producing node based on a preset mechanism, which helps to ensure the normal operation of the entire system.

[0233] Furthermore, if a node in the distributed ledger network (e.g., the first node, the second node) fails to determine a block-producing node, it could also be that the node determines there are no tasks in its task pool. For example, a node in the distributed ledger network determines that there are no tasks in its task pool within a fourth preset time period, and / or, a node in the distributed ledger network determines that there are no tasks in its task pool before a second preset time period. For example, the fourth preset time period is determined based on the block production interval of the distributed ledger network; for example, the fourth preset time period can be less than or equal to the first preset time period. For example, the second preset time period is determined by the distributed ledger network based on the time of the next block production; for example, the second preset time period is the time of the next block production minus a fifth preset time period.

[0234] Furthermore, in the next round of block production node selection process, if a node in the distributed ledger network determines that there is a task in the task pool, it will continue to determine the block production node based on the tasks in the task pool, instead of using the preset mechanism to determine the block production node.

[0235] Explanation 3:

[0236] The method for selecting block-producing nodes provided in this application can also be considered as follows: the distributed ledger network includes multiple candidate nodes. Each candidate node can generate a task result corresponding to itself based on the first task, and then send out the task result corresponding to itself.

[0237] In one example, each candidate node can receive the task results from other candidate nodes, verify these results, obtain verification results, and then send them out. That is, each candidate node can not only verify the task results of a candidate node (denoted as candidate node A) itself, but also obtain verification results from other candidate nodes verifying the task results of candidate node A. Based on all the obtained verification results, it can then determine whether candidate node A has passed the verification of the distributed ledger network. It can be understood that each candidate node in the distributed ledger network executes the above process, thereby determining the same block-producing node.

[0238] In another example, each candidate node can receive the task results from other candidate nodes, verify those results, obtain the verification results, and send them out. The third node can obtain the verification results obtained by all candidate nodes verifying the task results of candidate node A, and then determine whether candidate node A has passed the verification of the distributed ledger network based on all the verification results.

[0239] That is, although this application embodiment uses the first node and the second node as examples for illustration, each candidate node in the distributed ledger network can perform the above steps and determine whether each candidate node is a block-producing node. For example, in step 200, each candidate node can obtain a first task from its respective task pool; for another example, each candidate node can determine whether there is a task in its respective task pool. If it is determined that there is a task in its respective task pool, it obtains the task (that is, the first task) from its respective task pool; if it is determined that there is no task in its respective task pool, it determines the block-producing node according to a preset mechanism.

[0240] In addition to candidate nodes, distributed ledger networks may also include verification nodes. Verification nodes participate in the verification of task results but do not compete for block-producing nodes (i.e., they do not process the first task). For example, verification nodes do not need to determine whether there are tasks in the task pool.

[0241] Of course, in other possible examples, the distributed ledger network may also include a fifth node, which may or may not be the third node; or, the fifth node may be one of multiple candidate nodes. The fifth node determines whether there is a task in its task pool. If it determines that there is a task in its task pool (since the task pools of each node in the distributed ledger network are synchronized, this is equivalent to determining that there is a task in the task pools of each candidate node), it notifies the candidate nodes to obtain the task (i.e., the first task) from their respective task pools; if it determines that there is no task in its task pool, it notifies the candidate nodes to determine the block-producing node according to a preset mechanism; or, the fifth node determines the block-producing node itself according to the preset mechanism and sends the identifier of the block-producing node in the distributed ledger network.

[0242] Figure 5 is a flowchart illustrating the fourth method for selecting block-producing nodes provided in this application. This flowchart can be executed by either the first node or the second node in the distributed ledger network. The following explanation uses the first node as an example.

[0243] Step 501: The first node determines whether a task exists in the task pool. If the first node determines that a task exists in the task pool, it executes steps 502 and 503 below. If the first node determines that no task exists in the task pool, it executes step 504 below.

[0244] For details on the implementation, please refer to Explanation 2 following step 405.

[0245] Step 502: The first node obtains the first task from the task pool.

[0246] For a detailed implementation, please refer to the description in step 200.

[0247] Step 503: The first node determines itself as the block-producing node based on the first task.

[0248] Implementation method 1 involves the third node determining the first node as the block-producing node, which may include the following steps:

[0249] Step (1): The first node generates the first result corresponding to the first task based on the first task.

[0250] For a detailed implementation, please refer to the description in step 201.

[0251] In step (2), the first node sends the first result, and the second node receives the first result accordingly.

[0252] For a detailed implementation, please refer to the description in step 202.

[0253] Step (3): The second node determines the verification result of the second node based on the first result.

[0254] For a detailed implementation, please refer to the description in step 301.

[0255] In step (4), the second node sends its verification result. Correspondingly, the third node receives the verification result from the second node.

[0256] For a detailed implementation, please refer to the description in step 302.

[0257] In step (5), the third node determines the second result based on the verification result of the second node.

[0258] For a detailed implementation, please refer to the description in step 303.

[0259] In step (6), the third node sends the second result. Correspondingly, the first and second nodes receive the second result.

[0260] For a detailed implementation, please refer to the description in step 304.

[0261] In step (7), the first node determines itself as a block-producing node in the distributed ledger network based on the second result. The second node also determines itself as a block-producing node in the distributed ledger network based on the second result.

[0262] For a detailed implementation, please refer to the description in step 305.

[0263] Implementation method 2 involves determining the first node as the block-producing node based on the first node / second node, which may include the following steps:

[0264] Step (1): The first node generates the first result corresponding to the first task based on the first task.

[0265] For a detailed implementation, please refer to the description in step 201.

[0266] In step (2), the first node sends the first result, and the second node receives the first result accordingly.

[0267] For a detailed implementation, please refer to the description in step 202.

[0268] Step (3): The second node determines the verification result of the second node based on the first result.

[0269] For example, there are multiple second nodes. Taking second node 1 and second node 2 as examples, second node 1 determines verification result 1 based on the first result. Second node 2 determines verification result 2 based on the first result.

[0270] For a detailed implementation, please refer to the description in step 401.

[0271] In step (4), the second node sends its verification result. Correspondingly, the first node receives the verification result from the second node.

[0272] Referring to the example in step (3), the second node 1 sends verification result 1. Correspondingly, the first node and the second node 2 receive verification result 1. The second node 2 sends verification result 2. Correspondingly, the first node and the second node 1 receive verification result 2.

[0273] For a detailed implementation, please refer to the description in step 402.

[0274] In step (5), the first node determines itself as a block-producing node in the distributed ledger network based on the verification result of the second node. The second node determines itself as a block-producing node in the distributed ledger network based on the verification result of the second node.

[0275] Combining the examples in steps (3) and (4), the first node determines itself as the block-producing node based on verification result 1 and verification result 2. The second node 1 determines itself as the block-producing node based on verification result 1 and verification result 2. The second node 2 determines itself as the block-producing node based on verification result 1 and verification result 2. The results determined by the first node, the second node 1, and the second node 2 are the same.

[0276] For a detailed implementation, please refer to the description in step 403.

[0277] Step 504: The first node determines itself as the block producing node according to the preset block producing mechanism.

[0278] It is understandable that the second node in a distributed ledger network performs similar actions to the first node.

[0279] For a detailed implementation, please refer to the description in Note 2.

[0280] Step 505: The first node generates a block based on the transactions in the transaction pool. See step 306 for a more detailed description of the implementation.

[0281] Step 506: The first node sends a block. See step 307 for a further description of the implementation.

[0282] Referring to the flowcharts in Figures 2 to 5 above, the following example illustrates the interaction actions within a node, focusing on the modules within that node. For instance, a module within a node can be a software module, such as software program code. Interaction between two modules can be, for example, a function call between two code segments.

[0283] Figure 6 is an example of an interaction flowchart of a module within a first node provided in this application:

[0284] The first node includes an executor, a result submission contract, and a task pool management contract.

[0285] Step 601: The executor of the first node sends a task acquisition request to the task pool management contract, whereby the task acquisition request is used to request tasks from the task pool. Correspondingly, the task pool management contract receives the task acquisition request.

[0286] Step 602: The task pool management contract of the first node sends the first task to the executor of the first node. Correspondingly, the executor of the first node receives the first task. For example, the task pool management contract sends the first task from the task pool to the executor of the first node.

[0287] Step 603: The executor of the first node generates the first result corresponding to the first task based on the first task.

[0288] For a detailed implementation, please refer to the description in step 201.

[0289] Step 604: The executor of the first node signs the first result based on the private key of the first node.

[0290] For a detailed implementation, please refer to the description in step 301.

[0291] In step 605, the executor of the first node sends the first result and signature to the result submission contract of the first node. Correspondingly, the result submission contract of the first node receives the first result and signature.

[0292] In step 606, the result submission contract of the first node sends the first result and signature in the distributed ledger network. Correspondingly, the task verification contract in the second node receives the first result.

[0293] For example, the result submission contract of the first node broadcasts the first result and signature in the distributed ledger network; and for another example, the result submission contract of the first node sends the first result and signature to the second node in the distributed ledger network based on the identifier of the second node.

[0294] In other possible examples, a transaction pool management contract is also deployed in the first node. The first node's result submission contract writes the first result and signature as a transaction into the first node's transaction pool, and the first node's transaction pool management contract sends the first result and signature across the distributed ledger network. Correspondingly, the second node's transaction pool management contract receives the first result and signature, writes the first result and signature into the second node's transaction pool, and also sends the first result and signature to the second node's task verification contract.

[0295] For example, the transaction pool management contract of the first node broadcasts the first result and signature in the distributed ledger network; for another example, the transaction pool management contract of the first node sends the first result and signature to the second node in the distributed ledger network according to the identifier of the second node.

[0296] Figure 7 is an example of an interaction flowchart of a module within a second node provided in this application:

[0297] The second node includes a task verification contract and a result submission contract.

[0298] Step 701: The task verification contract of the second node determines the verification result of the second node based on the first result and the signature.

[0299] For a detailed implementation, please refer to the description in step 301.

[0300] Step 702: The task verification contract of the second node sends the verification result of the second node to the result submission contract of the second node.

[0301] In step 703, the second node's result submission contract sends its verification result to the distributed ledger network. Correspondingly, the third node receives the second node's verification result.

[0302] For example, the result submission contract of the first node broadcasts the verification result of the second node in the distributed ledger network; and for another example, the result submission contract of the first node sends the verification result of the second node to the third node in the distributed ledger network based on the identifier of the third node.

[0303] In other possible examples, a transaction pool management contract is also deployed in the second node. The result submission contract of the second node writes the verification result of the second node as a transaction into the transaction pool of the second node, and the transaction pool management contract of the second node sends the verification result of the second node in the distributed ledger network. Correspondingly, the third node receives the verification result of the second node.

[0304] For example, the transaction pool management contract of the first node broadcasts the verification result of the second node in the distributed ledger network; for another example, the transaction pool management contract of the first node sends the verification result of the second node to the third node in the distributed ledger network based on the identifier of the third node.

[0305] Figure 8 is an example of an interaction flowchart of a module within a fourth node provided in this application:

[0306] The fourth node includes an executor, a task pool management contract, and a task submission contract.

[0307] Step 801: The executor of the fourth node sends a configuration information retrieval request to the task pool management contract of the fourth node. The configuration information retrieval request is used to request configuration information. Correspondingly, the task pool management contract of the fourth node receives the configuration information retrieval request.

[0308] In step 802, the task pool management contract of the fourth node sends configuration information to the executor of the fourth node. Correspondingly, the executor of the fourth node receives the configuration information. For a description of the configuration information, please refer to step A.

[0309] Step 803: The executor of the fourth node generates the first task based on the type and configuration information of the first task.

[0310] For a detailed implementation, please refer to the description in step A.

[0311] Step 804: The executor of the fourth node sends the first task to the task submission contract of the fourth node.

[0312] Step 805: The fourth node's task submission contract verifies the validity of the first task.

[0313] For a detailed implementation, please refer to the description in step B.

[0314] Step 806: After the fourth node's task submission contract passes the validity verification, it submits the first task to the fourth node's task pool.

[0315] Step 807: The task pool management contract of the fourth node sends the first task in the distributed ledger network.

[0316] For a detailed implementation, please refer to the description in step B.

[0317] It should be noted that the step numbers in each flowchart are merely an example of the execution flow and do not constitute a restriction on the order of step execution. In this embodiment, there is no strict execution order between steps that do not have temporal dependencies. Not all steps shown in each flowchart are mandatory. Some steps can be deleted from each flowchart as needed, or other possible steps can be added to each flowchart as needed.

[0318] The above description focuses on the differences between the various embodiments. Apart from the differences, the various embodiments can be referred to each other. In addition, different implementations or different examples in the same embodiment can also be referred to each other.

[0319] Based on the above content and the same concept, Figures 9 and 10 are schematic diagrams of the possible block selection devices provided in this application. These block selection devices can be used to implement the functions of the first node, the second node, or the fourth node in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0320] In this application, the device for selecting the block output node can be a terminal (or a module in the terminal) as shown in Figure 1, an access network device (or a module in the access network device), a core network device (or a module in the core network device), or an independent server (or a module in the server) deployed in the access network or core network.

[0321] As shown in Figure 9, the block selection device 900 includes a processing module 901 and a transceiver module 902.

[0322] When the block selection device 900 is used to implement the function of the first node in any of the method embodiments shown in Figures 2 to 5:

[0323] Processing module 901 is used to generate a first result corresponding to the first task based on the first task;

[0324] The transceiver module 902 is used to send a first result, wherein the first result is used to determine whether the first node is a block-producing node, and the block-producing node is used to generate blocks of the distributed ledger based on the transactions in the transaction pool.

[0325] In one possible implementation, if the first node is a block-producing node, the processing module 901 is also used to generate blocks based on the transactions in the transaction pool; the sending and receiving module 902 is also used to send blocks.

[0326] In one possible implementation, if the first node is a block-producing node, the first result is published in the distributed ledger.

[0327] In one possible implementation, after sending the first result, the transceiver module 902 is also used to receive the verification result of the second node in the distributed ledger network. The verification result of the second node is obtained by the second node from verifying the first result. The processing module 901 is also used to determine that the first node is a block producing node based on the verification result of the second node.

[0328] In one possible implementation, after sending the first result, the transceiver module 902 is further configured to receive the second result from the third node in the distributed ledger network. The second result is determined by the third node based on the verification result of the second node in the distributed ledger network. The verification result of the second node is obtained by the second node from verifying the first result. The processing module 901 is further configured to determine, based on the second result, that the first node is a block-producing node in the distributed ledger network.

[0329] In one possible implementation, the first task is a network management task related to the operator's network, or a task that provides services to users. For example, the first task includes task data and a task objective; the first result is the outcome of achieving the task objective based on the task data; or, the first task includes task data, a task objective, and task constraints; the first result is the outcome of achieving the task objective and satisfying the task constraints based on the task data. In one possible implementation, the first task is a task of the resource allocation type, cache optimization type, image data processing type, routing optimization type, or mobile edge computing type.

[0330] In one possible implementation, before generating the first result corresponding to the first task based on the first task, the processing module 901 is also used to obtain the first task from the task pool.

[0331] In one possible implementation, if the block-producing node is not determined according to the first task, the processing module 901 is also used to determine the block-producing node according to a preset mechanism.

[0332] In one possible implementation, before generating the first result corresponding to the first task based on the first task, the processing module 901 is further configured to determine whether a task exists in the task pool. In another possible implementation, the processing module 901 is further configured to determine the block-producing node according to a preset mechanism if it is determined that no task exists in the task pool.

[0333] The preset mechanisms include one or more of the following: a mechanism for selecting nodes as block-producing nodes in turn, a mechanism for randomly selecting nodes as block-producing nodes, a mechanism for selecting fixed nodes as block-producing nodes, a mechanism for selecting block-producing nodes based on the proof-of-work algorithm, a mechanism for selecting block-producing nodes based on the proof-of-stake algorithm, a mechanism for selecting block-producing nodes based on the proof-of-authority algorithm, or a mechanism for selecting block-producing nodes based on the proof-of-cover algorithm.

[0334] For example, processing module 901 is equivalent to the executor in the relevant embodiment of FIG6, and transceiver module 902 is equivalent to the task pool management contract and result submission contract in the relevant embodiment of FIG6. Of course, the steps implemented by processing module 901 and transceiver module 902 can also be specified as needed. Processing module 901 and transceiver module 902 can respectively implement different steps in the method embodiments shown in any of FIG2 to FIG6 to realize all the functions of block node selection device 900.

[0335] When the block selection device 900 is used to implement the function of the second node in any of the method embodiments shown in Figures 2 to 5:

[0336] The transceiver module 902 is used to receive the first result, which is generated by the first node according to the first task. The first result is used to determine whether the first node is a block-producing node. The block-producing node is used to generate blocks of the distributed ledger according to the transactions in the transaction pool.

[0337] Processing module 901 is used to determine the verification result of the second node based on the first result.

[0338] In one possible implementation, when the processing module 901 determines the verification result of the second node based on the first result, it is specifically used to determine the verification result of the second node based on the first task and the first result.

[0339] In one possible implementation, the first task includes task data and task objectives. When the processing module 901 determines the verification result of the second node based on the first task and the first result, it is specifically used to determine that the verification result of the second node is successful if it is determined that the first result achieves the task objective based on the task data.

[0340] In one possible implementation, the first task includes task data, task objectives, and task constraints. When the processing module 901 determines the verification result of the second node based on the first task and the first result, it is specifically used to determine that the verification result of the second node is successful if it is determined that the first result achieves the task objective and satisfies the task constraints based on the task data.

[0341] In one possible implementation, the transceiver module 902 is further configured to receive a second result from a third node in the distributed ledger network, the second result being determined by the third node based on the verification result of the second node; and the processing module 901 is further configured to determine, based on the second result, that the first node is a block-producing node in the distributed ledger network.

[0342] In one possible implementation, the processing module 901 is further configured to determine, based on the verification result of the second node, that the first node is a block-producing node in the distributed ledger network.

[0343] For example, processing module 901 is equivalent to the task verification contract in the relevant embodiment of Figure 7, and sending and receiving module 902 is equivalent to the result submission contract in the relevant embodiment of Figure 7. Of course, the steps implemented by processing module 901 and sending and receiving module 902 can also be specified as needed. Processing module 901 and sending and receiving module 902 can respectively implement different steps in any of the method embodiments shown in Figures 2 to 5 and Figure 7 to realize all the functions of the block selection device 900.

[0344] When the block selection device 900 is used to implement the function of the fourth node in the above method embodiment:

[0345] Processing module 901 is used to generate the first task;

[0346] The transceiver module 902 is used to send the first task. The first task is used for the first node to generate the first result. The first result is used to determine whether the first node is a block-producing node. The block-producing node is used to generate blocks for the distributed ledger based on the transactions in the transaction pool.

[0347] In one possible implementation, when generating the first task, the processing module 901 is specifically used to generate the first task according to the parameter format corresponding to the task type of the first task.

[0348] In one possible implementation, before generating the first task, the processing module 901 is also used to obtain configuration information, which includes parameter formats corresponding to multiple types, including the task type of the first task.

[0349] In one possible implementation, if the first node is a block-producing node, the first result is published in the distributed ledger, and the processing module 901 is also used to obtain the first result from the distributed ledger.

[0350] For example, processing module 901 is equivalent to the executor and task submission contract in the relevant embodiment of Figure 8, and sending and receiving module 902 is equivalent to the task pool management contract in the relevant embodiment of Figure 8. Of course, the steps implemented by processing module 901 and sending and receiving module 902 can also be specified as needed. Processing module 901 and sending and receiving module 902 can respectively implement different steps in any of the method embodiments shown in Figures 2 to 5 and Figure 8 to realize all the functions of block node selection device 900.

[0351] Figure 10 shows a device 1000 provided in an embodiment of this application. The device shown in Figure 10 can be a hardware circuit implementation of the device shown in Figure 9. This device can be applied to the flowcharts shown above to perform the functions of the first node, the second node, or the fourth node in the above method embodiments. For ease of explanation, Figure 10 only shows the main components of the device.

[0352] The device 1000 shown in Figure 10 includes a communication interface 1010, a processor 1020, and a memory 1030, wherein the memory 1030 is used to store program instructions and / or data. The processor 1020 may operate in conjunction with the memory 1030. The processor 1020 may execute the program instructions stored in the memory 1030. When the instructions or program stored in the memory 1030 are executed, the processor 1020 is used to perform the operations performed by the processing module 901 in the above embodiments, and the communication interface 1010 is used to perform the operations performed by the transceiver module 902 in the above embodiments.

[0353] The memory 1030 and the processor 1020 are coupled. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. At least one of the memories 1030 may be included in the processor 1020.

[0354] In this embodiment, the communication interface can be a transceiver, circuit, bus, module, or other type of communication interface. In this embodiment, when the communication interface is a transceiver, the transceiver can include an independent receiver, an independent transmitter, or a transceiver integrating transceiver functions, or simply a communication interface.

[0355] Device 1000 may also include a communication line 1040. The communication interface 1010, processor 1020, and memory 1030 can be interconnected via the communication line 1040. The communication line 1040 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication line 1040 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in Figure 10, but this does not indicate that there is only one bus or one type of bus.

[0356] Based on the above content and the same concept, this application provides a computer-readable storage medium storing a computer program or instructions. When the computer program or instructions are executed by a block selection device, the device can realize the functions of the first node, the second node, the third node, or the fourth node in the above method embodiments.

[0357] Based on the above content and the same concept, this application provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by the block selection device, they implement the functions of the first node, the second node, the third node, or the fourth node in the above method embodiments.

[0358] Based on the above content and the same concept, this application provides a communication system, including one or more of the first node, second node, third node and fourth node in the above method embodiments.

[0359] In this application embodiment, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0360] In the embodiments of this application, "when," "if," and "if" all refer to the device taking corresponding actions under certain objective circumstances, and are not time-limited, nor do they require the device to perform a judgment action, nor do they imply any other limitations. Unless otherwise specified, "if" and "if" can be substituted, and "when" and "in the case of" can be substituted. "When" and "if" / "if" can be substituted.

[0361] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0362] In this application, the ordinal numbers such as "first" and "second" are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, priority, or importance of the multiple objects. For example, "first instruction information" and "second instruction information" refer to two different instruction information, and do not indicate a difference in priority or importance between the two instruction information.

[0363] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic. Obviously, those skilled in the art can make various modifications and variations to this application without departing from the protection scope of this application. Therefore, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method for selecting block-producing nodes, characterized in that, include: The first node generates the first result corresponding to the first task based on the first task; The first node sends the first result, which is used to determine whether the first node is a block-producing node. The block-producing node is used to generate blocks for the distributed ledger based on the transactions in the transaction pool.

2. The method as described in claim 1, characterized in that, If the first node is the block-producing node, the method further includes: The first node generates a block based on the transactions in the transaction pool; The first node sends the block.

3. The method as described in claim 1 or 2, characterized in that, If the first node is the block-producing node, the first result is published in the distributed ledger.

4. The method according to any one of claims 1-3, characterized in that, After the first node sends the first result, the process further includes: The first node receives the verification result from the second node, and the verification result from the second node is obtained by the second node through verification of the first result; Based on the verification result of the second node, the first node determines that the first node is the block producing node.

5. The method according to any one of claims 1-3, characterized in that, After the first node sends the first result, the process further includes: The first node receives a second result from the third node, the second result being determined by the third node based on the verification result of the second node, and the verification result of the second node being obtained by the second node through verification of the first result; Based on the second result, the first node determines that it is the block-producing node.

6. The method according to any one of claims 1-5, characterized in that, The first task is a network management task related to the operator's network, or the first task is a task of providing services to users.

7. The method according to any one of claims 1-6, characterized in that, The first task includes task data and task objectives; the first result is the outcome of achieving the task objectives based on the task data; or, The first task includes task data, task objectives, and task constraints; the first result is the result of achieving the task objectives and satisfying the task constraints based on the task data.

8. The method according to any one of claims 1-7, characterized in that, Before the first node generates the first result corresponding to the first task based on the first task, it also includes: The first node obtains the first task from the task pool.

9. The method according to any one of claims 1-8, characterized in that, Also includes: If the block-producing node is not determined according to the first task, the first node determines the block-producing node according to a preset mechanism; The preset mechanism includes one or more of the following: Mechanisms for selecting block-producing nodes include: taking turns selecting nodes as block-producing nodes; randomly selecting nodes as block-producing nodes; selecting fixed nodes as block-producing nodes; selecting block-producing nodes based on the proof-of-work algorithm; selecting block-producing nodes based on the proof-of-stake algorithm; selecting block-producing nodes based on the proof-of-authority algorithm; and selecting block-producing nodes based on the proof-of-cover algorithm.

10. The method according to any one of claims 1-9, characterized in that, Before the first node generates the first result corresponding to the first task based on the first task, it also includes: Confirm that there are tasks in the task pool.

11. The method as described in claim 10, characterized in that, Also includes: If it is determined that there are no tasks in the task pool, the first node determines the block-producing node according to a preset mechanism; The preset mechanism includes one or more of the following: Mechanisms for selecting block-producing nodes include: taking turns selecting nodes as block-producing nodes; randomly selecting nodes as block-producing nodes; selecting fixed nodes as block-producing nodes; selecting block-producing nodes based on the proof-of-work algorithm; selecting block-producing nodes based on the proof-of-stake algorithm; selecting block-producing nodes based on the proof-of-authority algorithm; and selecting block-producing nodes based on the proof-of-cover algorithm.

12. The method according to any one of claims 1-11, characterized in that, The first task is a task from the resource allocation type, cache optimization type, image data processing type, routing optimization type, or mobile edge computing type.

13. A method for selecting block-producing nodes, characterized in that, include: The second node receives the first result, which is generated by the first node based on the first task. The second node determines its verification result based on the first result. The verification result of the second node is used to determine whether the first node is a block-producing node. The block-producing node is used to generate blocks of the distributed ledger based on the transactions in the transaction pool.

14. The method as described in claim 13, characterized in that, The second node determines its verification result based on the first result, including: The second node determines the verification result based on the first task and the first result.

15. The method as described in claim 14, characterized in that, The first task includes task data and a task objective. The second node, based on the first task and the first result, determines its verification result, including: If the second node determines that the first result has achieved the task objective based on the task data, the second node determines that the verification result of the second node is successful. or, The first task includes task data, task objectives, and task constraints. The second node, based on the first task and the first result, determines its verification result, including: If the second node determines that the first result achieves the task objective and satisfies the task constraints based on the task data, the second node determines that the verification result is successful.

16. The method according to any one of claims 13-15, characterized in that, Also includes: The second node receives a second result from the third node, which is determined by the third node based on the verification result of the second node; Based on the second result, the second node determines that the first node is the block-producing node.

17. The method according to any one of claims 13-15, characterized in that, Also includes: Based on the verification result of the second node, the second node determines that the first node is the block producing node.

18. A method for selecting block-producing nodes, characterized in that, include: The fourth node generates the first task; The fourth node sends the first task, which is used to determine the block-producing node, and the block-producing node is used to generate blocks for the distributed ledger based on the transactions in the transaction pool.

19. The method as described in claim 18, characterized in that, The fourth node generates the first task, including: The fourth node generates the first task according to the parameter format corresponding to the task type of the first task.

20. The method as described in claim 18 or 19, characterized in that, Before the fourth node generates the first task, it also includes: The fourth node obtains configuration information, which includes parameter formats corresponding to multiple types, including the task type of the first task.

21. The method according to any one of claims 18-20, characterized in that, Also includes: The fourth node obtains the first result corresponding to the first task from the distributed ledger.

22. A device for selecting block output nodes, characterized in that, It includes a module for performing the method as described in any one of claims 1 to 12, or includes a module for performing the method as described in any one of claims 13 to 17, or includes a module for performing the method as described in any one of claims 18 to 21.

23. A device for selecting block output nodes, characterized in that, The device includes a processor and an interface circuit, the interface circuit being configured to receive signals from other devices besides the selection device and transmit them to the processor, or to send signals from the processor to other devices besides the selection device. The processor is configured to implement the method as described in any one of claims 1 to 12 via logic circuits or executable code instructions, or the processor is configured to implement the method as described in any one of claims 13 to 17 via logic circuits or executable code instructions, or the processor is configured to implement the method as described in any one of claims 18 to 21 via logic circuits or executable code instructions.

24. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a selected device, implement the method as described in any one of claims 1 to 12; or, when executed by a selected device, implement the method as described in any one of claims 13 to 17; or, when executed by a selected device, implement the method as described in any one of claims 18 to 21.

25. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a selected device, implement the method as described in any one of claims 1 to 12, or implement the method as described in any one of claims 13 to 17, or implement the method as described in any one of claims 18 to 21.

26. A communication system, characterized in that, Includes one or more of the first node, second node, and fourth node; Wherein, the first node is used to perform the method of any one of claims 1 to 12; the second node is used to perform the method of any one of claims 13 to 17; and the fourth node is used to perform the method of any one of claims 18 to 21.

Images