Blockchain consensus method, device and equipment

Abstract

The present application provides a blockchain consensus method, apparatus, and device for use in the field of blockchain technology. The method includes screening at least one candidate node from all blockchain nodes in response to a service call submitted by a user through a light node. The candidate node is a node with a valid spatiotemporal credential among multiple blockchain nodes. The validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node. The node information of each candidate node is obtained. The node information includes geographic location information, available time information, historical service call information, and historical valid feedback information. Based on the node information of the candidate node, the block production weight of the candidate node is determined. Based on the block production weight of each candidate node, a block production node is screened from all candidate nodes to respond to the service call. This can solve the problem of resource waste and monopoly by a few nodes in the traditional consensus mechanism.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain consensus method, apparatus, and device. Background Art

[0002] With the widespread adoption of blockchain technology, its core mechanism—the consensus algorithm—has become crucial for ensuring the consistency and security of distributed ledgers. Currently, the mainstream consensus mechanisms include proof of work (PoW) and proof of stake (PoS). While PoW relies on computing power competition to determine accounting rights, while offering greater security, its energy consumption and inefficiency make it difficult to adapt to green and low-carbon development trends. PoS, on the other hand, allocates accounting rights based on the amount and duration of coin holdings. While this offers some energy savings, it can lead to resource concentration in practice, resulting in a small number of nodes dominating the network and weakening its decentralized nature.

[0003] Therefore, a blockchain consensus method is urgently needed to solve the problems of traditional consensus mechanisms such as easy waste of resources and easy monopoly by a few nodes. Summary of the Invention

[0004] The purpose of this application is to provide a blockchain consensus method, device and equipment to solve the problem that traditional consensus mechanisms are prone to waste of resources and are easily monopolized by a few nodes.

[0005] In a first aspect, embodiments of the present application provide a blockchain consensus method, which is applied to a blockchain system comprising multiple blockchain nodes. The method comprises: in response to a service call submitted by a user via a light node, screening at least one candidate node from all blockchain nodes. The candidate node is a node with a valid spatiotemporal credential from among the multiple blockchain nodes. The validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node. Node information for each candidate node is obtained. The node information includes geographic location information, available time information, historical service call information, and historical valid feedback information. Available time information includes available time and theoretical online time. Historical service call information includes the number of historical calls, the unit computing power value of the task, and the service completion success rate. Based on the node information of the candidate node, the block production weight of the candidate node is determined. Based on the block production weight of each candidate node, a block production node is screened from all candidate nodes to respond to the service call.

[0006] The blockchain consensus method provided in the embodiments of this application determines the block weight by comprehensively considering multiple dimensions of data, including the candidate node's geographic location information, available time information, historical service call information, and historical valid feedback information. This comprehensive evaluation method not only avoids the resource concentration and centralization issues that may arise from relying solely on computing power (such as PoW) or coin holdings (such as PoS), but also more fairly reflects the actual contribution and stability of the nodes. Furthermore, the method provided in the embodiments of this application enhances the stability and security of the blockchain system by utilizing the spatiotemporal credential verification and multi-dimensional information evaluation of blockchain nodes, effectively preventing malicious or unstable nodes from participating in the block production process.

[0007] It should be noted that the consensus process of this application does not involve cryptocurrency.

[0008] One possible implementation method determines the block production weight of a candidate node based on its node information. This includes determining the geographic distribution breadth of the candidate nodes in the blockchain system based on the geographic location information of all candidate nodes. Geographic distribution breadth represents the global distribution range of candidate nodes in longitude and latitude. For each candidate node, the candidate's online service indicator is determined based on its available time and theoretical online time. The number of valid task completions is determined based on the historical number of calls, the unit computing power of tasks, and the service completion success rate. The user trust indicator is determined based on the number of calls and historical valid feedback information. The block production weight of the candidate node is determined based on the geographic distribution breadth, online service indicators, valid task completion data, and user trust indicators.

[0009] One possible implementation method involves screening block-producing nodes from all candidate nodes based on the block-producing weight of each candidate node. This includes assigning a weight range to each candidate node based on the block-producing weight of each candidate node. The range of the weight range corresponds to the block-producing weight of the candidate node, and the range of the weight range is determined by dividing the sum of the block-producing weights of all candidate nodes into a number of consecutive sub-ranges. A generated random number is obtained. The random number is within the sum of the block-producing weights of all candidate nodes. Based on the random number, a block-producing weight range is screened from all weight ranges. The block-producing weight range corresponds to the block-producing node. The block-producing node is the candidate node corresponding to the block-producing weight range.

[0010] One possible implementation involves selecting at least one candidate node from all blockchain nodes. This includes receiving, for any blockchain node among all blockchain nodes, a spatiotemporal credential uploaded by the node. The spatiotemporal credential includes geographic location information and a timestamp. The geographic location information is determined based on satellite signals from multiple satellites acquired when the blockchain node is started. The timestamp indicates the time the spatiotemporal credential was generated. If the geographic location information is determined to be within a preset geographic location range and the timestamp is determined to be within a preset timestamp range, the blockchain node is determined to be a candidate node.

[0011] In one possible implementation, the spatiotemporal credential also includes a carrier phase error of the blockchain node. The method further includes determining the movement path of the blockchain node at the multiple timestamps based on the geographic location information and carrier phase error of the multiple timestamps. If the movement path is determined to be continuous and conforms to pre-set movement path detection rules, the blockchain node is determined to be a candidate node.

[0012] In one possible implementation, the method further includes: determining a total reward amount corresponding to the service call. The total reward amount is determined based on the complexity of the service call and the estimated resource consumption. The total reward amount is split into a first reward and a second reward according to a preset distribution ratio. The distribution ratio is dynamically adjusted based on the incentive strategy of the blockchain system. The first reward is distributed to the block-producing node. The second reward is distributed to all candidate nodes other than the block-producing node based on the block production weights of the candidate nodes other than the block-producing node.

[0013] One possible implementation method distributes the second reward to all candidate nodes other than the block-producing node based on the block production weights of the candidate nodes other than the block-producing node, including: determining the reward distribution ratio corresponding to each candidate node other than the block-producing node based on the block production weights of the candidate nodes other than the block-producing node, and distributing the second reward to the corresponding candidate node based on the reward distribution ratio.

[0014] In one possible implementation, the method further includes: after the block producing node completes the service call, receiving service feedback information from the user regarding the block producing node. The service feedback information carries signature information signed by the user through the user wallet. If the signature information is determined to be valid, the service feedback information is determined to be valid feedback information.

[0015] In a second aspect, embodiments of the present application provide a blockchain consensus device, which is applied to a blockchain system including multiple blockchain nodes. The device includes: a screening module, an acquisition module, and a determination module.

[0016] The screening module is configured to select at least one candidate node from all blockchain nodes in response to a service call submitted by a user via a light node. The candidate node is a node with a valid spatiotemporal credential from among multiple blockchain nodes. The validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node.

[0017] The acquisition module is used to obtain node information for each candidate node. Node information includes geographic location, availability, historical service call history, and historical valid feedback. Availability includes available time and theoretical online time. Historical service call information includes the number of historical calls, task unit computing power, and service completion success rate.

[0018] The determination module is used to determine the block weight of the candidate node based on the node information of the candidate node.

[0019] The screening module is also used to screen out block-producing nodes from all candidate nodes based on the block-producing weight of each candidate node to respond to service calls.

[0020] In a third aspect, embodiments of the present application provide a blockchain consensus device that implements the blockchain consensus method of the first aspect or any possible implementation of the first aspect. This function can be implemented through hardware or through hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions.

[0021] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, the computer can execute the blockchain consensus method of the above-mentioned first aspect or any possible implementation of the first aspect.

[0022] In a fifth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when run on a computer, enables the computer to execute the blockchain consensus method of the above-mentioned first aspect or any possible implementation method.

[0023] Among them, the technical effects brought about by any design method in the second to fifth aspects can refer to the technical effects brought about by the first aspect or different possible implementation methods in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific implementation methods or the description of the prior art. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0025] Figure 1 A system architecture diagram of a blockchain system provided in an embodiment of the present application;

[0026] Figure 2 A flowchart of a blockchain consensus method provided in an embodiment of the present application;

[0027] Figure 3 A schematic diagram of the structure of a blockchain consensus device provided in an embodiment of the present application;

[0028] Figure 4 A schematic diagram of the structure of a blockchain consensus system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Generally, the components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations.

[0030] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for protection, but merely represents selected embodiments of the present application. All other embodiments obtained by persons of ordinary skill in the art based on the embodiments in the present application without creative work are within the scope of protection of the present application.

[0031] Before introducing the embodiments of the present application, the technical terms involved in the embodiments of the present application are described.

[0032] Blockchain is a secure implementation of a distributed ledger that uses blocks as a data structure to store transaction information. For example, a blockchain system is a complete distributed database maintained by several computing devices that jointly "keep accounts" (i.e., record transaction information) using blocks as a data structure. In a blockchain system, any blockchain node can generate a new block based on transaction information sent by a client and broadcast it to other blockchain nodes. These nodes then verify the block, and once all blockchain nodes in the system reach consensus, the new block can be added to the blockchain. A blockchain can consist of multiple blocks, with adjacent blockchain nodes maintaining a specific chain structure. This chain structure ensures that once a block is added to each node's replica after consensus, it cannot be altered (or tampered with).

[0033] Currently, mainstream consensus mechanisms include PoW and POS. PoW is a consensus mechanism that verifies transactions and generates new blocks by solving complex mathematical problems. Nodes under the PoW mechanism must devote significant computing resources to solving these problems. Only nodes that successfully solve the problems are entitled to generate new blocks and receive rewards. This process consumes significant amounts of electricity, resulting in significant waste of computing resources.

[0034] PoS is a consensus mechanism that determines who is authorized to generate new blocks based on the number of tokens held by a node and the time they have held them. Under the PoS mechanism, nodes are required to stake a certain amount of tokens. The system verifies and generates new blocks based on the staked amount and the amount of time spent. This can lead to a gradual concentration of resources in the hands of a small number of wealthy nodes. Over time, the influence of these wealthy nodes can grow, leading to their dominance over the entire blockchain system and weakening its decentralized nature.

[0035] Based on this, an embodiment of the present application provides a blockchain consensus method, which is applied to a blockchain system including multiple blockchain nodes. The method includes screening at least one candidate node from all blockchain nodes in response to a service call submitted by a user through a light node. The candidate node is a node with a valid spatiotemporal credential from among the multiple blockchain nodes. The validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node. Node information for each candidate node is obtained. The node information includes geographic location information, available time information, historical service call information, and historical valid feedback information. Available time information includes available time and theoretical online time. Historical service call information includes: historical call count, task unit computing power value, and service completion success rate. Based on the node information of the candidate node, the block production weight of the candidate node is determined. Based on the block production weight of each candidate node, a block production node is screened from all candidate nodes to respond to the service call.

[0036] The blockchain consensus method provided in the embodiments of this application determines the block weight by comprehensively considering multiple dimensions of data, including the candidate node's geographic location information, available time information, historical service call information, and historical valid feedback information. This comprehensive evaluation method not only avoids the resource concentration and centralization issues that may arise from relying solely on computing power (such as PoW) or coin holdings (such as PoS), but also more fairly reflects the actual contribution and stability of the nodes. Furthermore, the method provided in the embodiments of this application enhances the stability and security of the blockchain system by utilizing the spatiotemporal credential verification and multi-dimensional information evaluation of blockchain nodes, effectively preventing malicious or unstable nodes from participating in the block production process.

[0037] The method provided in the embodiments of the present application will be described below with reference to specific drawings.

[0038] On the one hand, the embodiment of the present application provides a blockchain system. Figure 1 As shown, the blockchain system 100 may include multiple blockchain nodes 101, light nodes 102, monitoring nodes 103, smart contracts 104 and user interfaces 105.

[0039] Blockchain node 101 is used to store blockchain data, which may include all blocks and all transaction information. Blockchain node 101 interacts with other nodes via a peer-to-peer communication protocol to ensure the consistency and security of blockchain data. Blockchain node 101 is also used to participate in consensus with other blockchain nodes 101 to generate and verify new block-producing nodes. Blockchain node 101 can determine block-producing nodes using the blockchain consensus method provided in the embodiments of this application.

[0040] Light nodes 102 are resource-constrained nodes, typically running on mobile devices. Light nodes 102 can interact with blockchain nodes 101 to verify transactions or obtain necessary information. Users can submit service calls through light nodes 102 to trigger blockchain node 101 to determine the block producer.

[0041] Monitoring node 101 is used to monitor abnormal behavior in the blockchain system in real time, such as malicious attacks, node failures, and transaction fraud. Monitoring node 101 analyzes data traffic, node behavior, and transaction records in the blockchain system to promptly identify and report potential security threats. Specifically, monitoring node 101 verifies the spatiotemporal credentials of blockchain nodes, ensuring their geographic location information and timestamps are valid, thereby screening for safe and reliable candidate nodes.

[0042] Smart contracts 104 can automatically process transactions and business logic according to pre-set rules. Specifically, smart contracts 104 can be used to process transactions generated by users' likes or calls to block-producing nodes. For example, after a user provides a service call through light node 102 and obtains the corresponding service, the user can like or comment on the block-producing node through the light node, generating a smart contract call transaction.

[0043] The user interface 105 is used to provide an operating platform for users. Specifically, users can submit transactions, check wallet balances, view transaction records, manage wallets, etc. through the user interface. The user interface can be a web application, mobile application, or desktop application.

[0044] It should be noted that the blockchain node or light node in this application can be a processing unit.

[0045] In one possible implementation, a blockchain node or light node can be a physical device, such as a server or terminal device. Another possible implementation is a blockchain node or light node can be a virtual computer. A virtual computer is a general term for the virtualized operating environment created by software in all types of virtualized devices, including virtual machines and containers. In other possible implementations, a blockchain node or light node can be a process or thread. A thread is the smallest unit of computation that an operating system can schedule. A thread is contained within a process and is the actual operational unit within the process. A process is a computer program's execution of a data set and serves as the basic unit for resource allocation and scheduling in the system.

[0046] It should be noted that the above Figure 1 The illustrated blockchain system 100 is merely an example of an application scenario of the present application solution, and is not intended to limit the application scenario of the present application solution.

[0047] On the one hand, the embodiment of the present application provides a blockchain consensus method, which can be deployed by Figure 1 The blockchain system 100 shown is executed. Figure 2 As shown, the method may include the following steps.

[0048] S201, in response to a service call submitted by a user through a light node, screening out at least one candidate node from all blockchain nodes.

[0049] A candidate node is a node among multiple blockchain nodes for which a spatiotemporal credential is valid. The spatiotemporal credential includes the blockchain node's geographic location information and a timestamp. The geographic location information is determined based on satellite signals from multiple satellites acquired when the blockchain node is started. The timestamp indicates when the spatiotemporal credential was generated. The validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node.

[0050] Specifically, a user submits a service call through a light node. The light node encapsulates the user's service call into a transaction containing key information such as the user address, service request content, and a timestamp, and broadcasts this transaction to the blockchain network. Upon receiving the service call broadcast by the light node, the blockchain node in the blockchain network first selects at least one candidate node from multiple blockchain nodes. This selection process is based on the spatiotemporal credentials uploaded by the blockchain node, and the node's candidate status is determined by verifying the validity of the spatiotemporal credentials.

[0051] One possible implementation involves receiving a time-space certificate of any blockchain node uploaded by the blockchain node from among all blockchain nodes. If the location information is determined to fall within a preset location range and the timestamp falls within a preset timestamp range, the blockchain node is determined to be a candidate node.

[0052] Furthermore, the movement path of the blockchain node at the multiple timestamps is determined based on the geographic location information and carrier phase error of the multiple timestamps. If the movement path is determined to be continuous and meets the preset movement path detection rules, the blockchain node is determined to be a candidate node.

[0053] Specifically, the blockchain system analyzes the node's location data at different times, determines the node's movement path at multiple timestamps, and verifies the continuity of the path and whether it was generated by a single receiver. If a block link's movement path shows time and space jumps, abnormal displacement, or mutation, it can be determined that the node is fraudulent or manipulated, thus ensuring the node's uniqueness and authenticity.

[0054] Among them, the uploading process of the space-time certificate of the blockchain node can be that the blockchain node monitors the satellite signal, extracts the key observation data from the satellite signal, determines the space-time certificate based on the key observation data, and uploads the space-time certificate to the blockchain network.

[0055] In one possible implementation, the blockchain node's spatiotemporal credentials can be uploaded by having its receiver continuously monitor the BeiDou B1 / B2 frequency band signals upon startup, extracting key observation data from the BeiDou B1 / B2 frequency band signals. This key observation data can include pseudorange, carrier phase information, and signal frequency shifts.

[0056] For example, blockchain nodes use code and carrier loops to track and capture the PRN code transmitted by the satellite, thereby extracting pseudorange (code delay) and carrier phase information. Simultaneously, blockchain nodes track signal frequency changes and estimate the relative velocity deviation between the satellite and the node receiver.

[0057] In one possible implementation, after extracting key observation data, a blockchain node uses a preset number of key observation data to determine its geographic location and timestamp. This data, along with the carrier phase error, is then packaged to create a spatiotemporal certificate. The blockchain node then uploads the spatiotemporal certificate along with the node's signature to the blockchain, verifying its identity and location.

[0058] For example, using the pseudoranges and carrier phases of at least four satellites, a GNSS positioning algorithm is used to parse the precise geographic location and timestamp of the node receiver. The geographic location information includes, but is not limited to, longitude, latitude, and altitude, and the timestamp can be the time the node receiver received the satellite signal. The blockchain node then encapsulates this geographic location information, timestamp, and carrier phase error, and signs it, which is then uploaded to the blockchain as a spatiotemporal certificate.

[0059] Furthermore, in order to ensure the authenticity of Beidou nodes, this application also introduces navigation message signatures (SM2 / SM3), spread spectrum authentication, RDSS two-way communication, signal quality detection, machine learning anomaly monitoring, and timestamp anti-replay mechanism.

[0060] Specifically, BeiDou-2 uses domestic cryptographic algorithms (such as SM2 signature, SM3 hash, and SM4 encryption) in civilian signals to authenticate and encrypt navigation messages. By inserting signature information into reserved bits of the navigation message, it verifies satellite time, satellite position, and message integrity. Node receivers verify the signature using a pre-installed satellite public key, confirming the message's authenticity. If signature verification fails or if the continuous time / position information is abnormal, the signal is deemed forged.

[0061] Furthermore, spread spectrum technology is used to transmit signature and authentication information for navigation messages, enhancing tamper resistance through spread spectrum modulation. In special circumstances, short messages encrypted with AES / ECC / GAN can also be sent. Only receiver nodes with the specified key (e.g., generated by the RDSS channel) and location restrictions can decrypt them, thus preventing unauthorized eavesdropping and replay attacks.

[0062] Furthermore, the BeiDou RDSS provides a bidirectional link between BeiDou satellites and node receivers. This means that node receivers can respond to information from the master control station, which then verifies the node receiver's geographic location via satellite. This bidirectional link is inherently difficult to forge, effectively identifying false or forwarded spoofed signals and enhancing the credibility of both BeiDou satellite identities and blockchain node identities.

[0063] Finally, each spatiotemporal credential carries a unique timestamp, session ID, and signature to prevent replay attacks. The system monitors the continuity and consistency of a node's historical spatiotemporal trajectory and triggers credential revocation for sudden or erratic behavior, thereby eliminating Sybil nodes that use multiple identities.

[0064] Furthermore, in the process of determining the geographic location information and timestamp of the blockchain node using a preset number of key observation data, the blockchain node will also identify and eliminate false signals in the key observation data.

[0065] Specifically, blockchain nodes monitor key observation data in real time, including the carrier signal's full width at half maximum (FWHM), Doppler fluctuations, and navigation message change rate. Machine learning methods are used to assist in detecting carrier signal anomalies and identify forged signals. For example, if a carrier signal exhibits multiple peaks, abnormal frequency shifts, or sudden changes in navigation information, the signal can be identified as forged.

[0066] One possible implementation method is to use the full width at half maximum principle to identify abnormal multi-peak or broadened signals in key observation data. If the forged signal has multipath characteristics, it will be eliminated.

[0067] Specifically, blockchain nodes use multi-peak detection and a half-peak width algorithm to filter out multipath or forwarding fraudulent signals. A true signal is typically single-peaked with a half-peak width less than a set threshold. If a signal exceeds this threshold, it is likely a forged signal and is therefore rejected.

[0068] Another possible implementation method is to monitor the Doppler changes detected by the carrier multiple times. If the changes are inconsistent or fluctuate violently, it indicates the presence of an intermediate signal injector, and the signal will be determined as a false signal.

[0069] Another possible implementation method is to use the navigation message authentication signal (NMA) and spread spectrum authenticated encryption (SSI) provided by the BeiDou-2 satellite to verify the legitimacy of the navigation message to further resist obfuscation attacks and ensure the security of node identity.

[0070] It should be noted that during this process, blockchain nodes can directly upload key observation data to the blockchain system. The system then uses a preset amount of key observation data to determine the blockchain node's spatiotemporal credentials. Simultaneously, this process also involves identifying and removing forged information from the key observation data. Finally, the aforementioned process of screening blockchain nodes is performed.

[0071] S202: Obtain node information of each candidate node.

[0072] Node information includes geographic location, available time, historical service call information, and historical valid feedback information. Available time includes available time and theoretical online time. Historical service call information includes the number of historical calls, task unit computing power value, and service completion success rate.

[0073] S203: Determine the block generation weight of the candidate node based on the node information of the candidate node.

[0074] One possible implementation method is to determine the geographic distribution breadth of candidate nodes in the blockchain system based on the geographic location information of all candidate nodes. The geographic distribution breadth is used to represent the distribution range of candidate nodes in terms of global longitude and latitude.

[0075] Specifically, the collected geographic location information of candidate nodes is preprocessed, such as through data cleaning and standardization. Discrete distribution clustering (e.g., based on uniform grid entropy) is performed using the longitude and latitude trajectories generated by on-board positioning of the Beidou satellite chain to measure distribution balance and determine the geographic distribution breadth (G) of subsequent nodes in the blockchain system. This geographic distribution breadth represents the global spatial distribution of nodes in the blockchain system and can reflect the availability and spatiotemporal redundancy of blockchain system services.

[0076] One possible implementation method is to determine the online service index of any candidate node among all candidate nodes based on the available time and theoretical online time. The online service index is used to indicate the stability of the candidate node in providing continuous services.

[0077] Specifically, for any candidate node, the available time and theoretical online time are obtained. Available time refers to the total amount of time during the statistical period that the node's GPU computing power is actually available. The theoretical online time refers to the maximum online time a node can theoretically achieve during the same statistical period. By dividing the available time by the theoretical online time, the candidate node's online service metric, GPU online service time (T), is calculated. GPU online service time is used to encourage nodes to provide long-term, stable service, reduce temporary speculative behavior, and ensure the stable operation and efficient service of the blockchain network.

[0078] One possible implementation method is to determine the number of valid task completions based on the number of historical calls, the unit computing power of the task, and the service completion success rate. The number of valid task completions is used to represent the computing power tasks (contribution value) actually completed by the candidate node.

[0079] Specifically, after each blockchain node completes block generation, the blockchain system records its historical call count—the total number of times the node has been requested to perform a task. It then determines the unit computing power value for each task call, representing the amount of computing resources required by the node to complete each task. It then calculates the service completion success rate, which is the ratio of successfully completed tasks to the total number of calls. By multiplying these three factors, the number of valid tasks completed—the number of tokens produced (C)—is calculated. This token output reflects the number of valid computing tasks completed by a node, representing its computing power contribution. By tightly tying verifiable computing power services to economic returns, it drives actual computing supply, incentivizes blockchain nodes to provide high-quality computing power services, and ensures efficient operation of the blockchain system and effective resource utilization.

[0080] One possible implementation method is to determine the user usage trust index based on the number of calls and historical valid feedback information. The user usage trust index is used to represent the reputation and trust reflected by the user's actual usage and endorsement behavior.

[0081] Specifically, the number of calls to each node is counted, representing the frequency of user requests for that node's services. Historical valid feedback is collected, including user likes and activity metrics, such as the ratio of daily active users (DAU) to monthly active users (MAU). By taking a weighted average of the number of calls and combining likes and user activity data, a comprehensive user trust index (U) is calculated, representing end-user usage and likes. This user trust index, comprised of the frequency of calls to the service by light nodes or end users, the duration of their stay, and feedback ratings, comprehensively reflects user satisfaction and trust in the node's services.

[0082] Finally, the block production weight of the candidate node is determined based on the geographical distribution breadth, online service indicators, effective task completion data and user trust indicators.

[0083] Specifically, first, the geographical distribution width x G , online service indicators x T , effective task completion data x C and user usage trust indicator x U Standardize by the following formula to get the corresponding proportion value p G , p T , p C , p U The specific normalization formula is as follows:

[0084]

[0085] Among them, x j The raw value of each indicator. GThe score for the geographical distribution breadth of the node in global longitude and latitude, that is, the degree of geographical diversity of the node. T The online service time of the node's GPU, indicating the stability of the node's service in unit time. C The number of tokens produced by the node, reflecting the number of computing tasks or contribution value actually completed by the node. U The node’s end-user usage / likes indicate the user’s service participation and endorsement of the node.

[0086] It should be noted that the normalization formula normalizes the original values ​​of the four dimensions into a proportional form, so that they can be treated uniformly in relative comparison and subsequent weighted calculation. The normalized proportional value p G , p T , p C , p U satisfy:

[0087] p G + p T + p C + p U = 1.

[0088] After normalizing the index values ​​using the normalized ratio values, the corresponding index values ​​are Gᵢ, Tᵢ, Cᵢ, and Uᵢ.

[0089] Finally, the comprehensive weight share of each node is calculated based on the preset weight parameters α, β, γ and δ weightᵢ Among them, the weight parameters α–δ can be adjusted in real time. The adjustment strategy of the weight parameters α–δ is determined by the on-chain governance mechanism and can be flexibly adjusted according to the development stage and specific needs of the blockchain system. The specific comprehensive weight calculation formula is as follows:

[0090] share weightᵢ = α·Gᵢ + β·Tᵢ + γ·Cᵢ + δ·Uᵢ.

[0091] This process fully considers the specific performance of candidate nodes in multiple aspects and adjusts the block weight parameters, enabling the blockchain system to more accurately evaluate the contribution and value of each candidate node. This ensures fairness and transparency while incentivizing nodes to maintain good performance in multiple key areas, thereby promoting the healthy, stable and sustainable development of the entire blockchain system.

[0092] S204: Filter out block-producing nodes from all candidate nodes based on the block-producing weight of each candidate node to respond to the service call.

[0093] Specifically, the candidate nodes are ranked according to their block production weight, and the smart contract determines the block production node based on the ranking of the candidate nodes.

[0094] One possible implementation method assigns a weight range to each candidate node based on its block production weight. The weight range corresponds to the candidate node's block production weight and is determined by dividing the sum of the block production weights of all candidate nodes into several consecutive sub-ranges. A random number is generated. The random number falls within the sum of the block production weights of all candidate nodes. Based on the random number, a block production weight range is selected from all weight ranges. The block production weight range corresponds to the block producing node. The block producing node is the candidate node corresponding to the block production weight range.

[0095] Specifically, after determining the block production weight of each candidate node, the sum of the block production weights of all candidate nodes is first calculated. Based on this weight, each candidate node is assigned a weight range. The range of the weight range is proportional to the candidate node's block production weight. For example, the sum of the block production weights of all candidate nodes is divided into several consecutive sub-ranges to determine the range of the weight range for each candidate node. A verifiable random function (VRF) in the blockchain system is used to generate a random number, and based on this random number, the winning node within the weight range is selected as the block production node.

[0096] This process selects block-producing nodes from candidate nodes based on their block-producing weights, ensuring that block-producing nodes can be fairly selected based on the contributions of candidate nodes in the blockchain system. It also allows low-weight nodes to have random block-producing opportunities, thus avoiding resource concentration and monopoly.

[0097] Furthermore, after the block producing node completes the service call, it receives the user's service feedback information for the block producing node. The service feedback information carries the signature information signed by the user through the user's wallet. If the signature information is determined to be valid, the service feedback information is determined to be valid feedback information.

[0098] After a block producer completes a user's service call, the user can like or rate the block producer. These actions are signed by the user's wallet, ensuring traceability and authenticity. Each like or call generates a smart contract call transaction, which is uploaded to the blockchain along with the user's address, service node address, timestamp, and service quality tags (such as latency and success rate). The smart contract writes these interactions to the blockchain, establishing an immutable record of usage and providing a solid foundation for the system's transparency and trustworthiness.

[0099] Users have a decentralized identity (DID), created and managed by an off-chain Beidou spacetime authentication or naming service (e.g., ENS). Light nodes (e.g., mobile apps) are bound to user wallets, allowing them to like posts or call services using their wallet addresses without deploying a full node (blockchain node), lowering the barrier to entry for users using blockchain systems. When users invoke services (e.g., AI inference or image rendering) through the app, the light nodes collect interaction data in real time.

[0100] Each user's wallet corresponds to a DID and can only participate in a single like or call, eliminating the possibility of duplicate voting. User reviews are accompanied by real usage and timestamps, and combined with spatiotemporal authentication, further prevent fraudulent activity. Furthermore, a payment fee can be added to the review process, increasing the cost of attacks while also ensuring system security. Furthermore, the system can incorporate Proof of Humanity or verification mechanisms to enhance the credibility of endorsers.

[0101] Every like or call is counted as an endorsement by the blockchain system, and a corresponding certificate token is generated by the smart contract for each endorsement. Likes grant "influence tickets" to service nodes, while calls generate "usage tickets." These tickets form a scoring system based on actual user behavior. This creates a KYC-free, Sybil-resistant, decentralized reputation system that effectively prevents fraudulent activity and vote manipulation.

[0102] Once uploaded to the blockchain, all endorsement data is queryable and can be read and reused by other systems (e.g., reputation platforms and community governance). Users' accumulated usage and review records form a "reputation profile," which is not only portable across platforms but can also be used in scenarios such as reward mechanisms and credit lending. By leveraging the core mechanisms of Web3 (decentralized identity, smart contracts, on-chain reputation, and governance / Sybil resistance), the entire process establishes a consensus logic framework driven by "light nodes + user behavior," achieving a closed loop from "service consumption" to "node block production," bringing greater fairness, transparency, and user-driven incentives to the system.

[0103] Furthermore, the total reward amount corresponding to the service call is determined. This total reward amount is determined based on the complexity of the service call and the estimated resource consumption. The total reward amount is split into a primary reward and a secondary reward according to a preset distribution ratio. This distribution ratio is dynamically adjusted based on the blockchain system's incentive strategy. The primary reward is distributed to the block-producing node. The secondary reward is distributed to all candidate nodes other than the block-producing node based on their block production weights.

[0104] Based on the block weights of candidate nodes other than the block-producing node, the reward distribution ratio corresponding to each candidate node other than the block-producing node is determined. Based on the reward distribution ratio, the second reward is distributed to the corresponding candidate node.

[0105] Specifically, based on the complexity of the service call and the estimated resource consumption, the total reward R corresponding to the service call is determined. The total reward R for each round is divided into two parts, including the main block reward R main (equivalent to the first reward mentioned above) and contribution dividend pool R bonus (Equivalent to the second reward mentioned above).

[0106] Among them, the main block reward R main It can be determined by the following formula.

[0107] R main = λ×R, where λ is 60% to 90%.

[0108] Contribution dividend pool R bonus It can be determined by the following formula.

[0109] R bonus = (1–λ)×R.

[0110] The main block reward is a one-time payment to the winning block producer to reward their key contributions to the block generation process. The contribution dividend pool is distributed according to the weight ratio of all candidate nodes in the round. This distribution process ensures that candidate nodes that actively participate but are not selected as block producers can also receive certain incentives.

[0111] For each candidate node i selected as a block producer, the additional bonus (bonusᵢ) it receives can be calculated as: bonusᵢ = R bonus × (share weightᵢ / Σshare weight ), where share weightᵢ is the block weight of node i, Σshare weight The sum of the block production weights of all candidate nodes. This distribution method not only ensures that the contributions of block-producing nodes are recognized and rewarded, but also incentivizes other nodes to actively participate in the maintenance and operation of the network, thereby enhancing the stability and decentralization of the entire blockchain network.

[0112] It should be noted that when allocating additional dividends to candidate nodes, in addition to considering their block production weight, the balance of candidate nodes in different dimensions can also be measured by calculating their contribution entropy, and their rewards can be increased or weakened by introducing a reward base.

[0113] Specifically, the "contribution entropy" of the node is calculated, and the Shannon entropy formula is used to measure the degree of balance of the four indicators. The specific Shannon entropy formula is as follows:

[0114]

[0115] The maximum value is log2(4) = 2, indicating perfect balance. The closer it is to 0, the more imbalanced it is, indicating that one factor is dominant or the other is 0. This process allows us to evaluate the balance of candidate nodes in different dimensions, thereby more comprehensively reflecting the comprehensive contribution of the nodes.

[0116] Finally, we introduce a reward base (e.g., the number of tokens) and use the base multiplied by the exponential of the contribution entropy to increase or decrease the reward. The specific formula is as follows:

[0117]

[0118] Among them, C i is the actual number of tokens contributed by the candidate node, H' is the degree of balance, and λ is the entropy impact factor.

[0119] The method provided in the embodiments of the present application will be described below with reference to specific examples.

[0120] For example, a local edge computing center deployed in a certain location hopes to provide services such as real-time AI recognition of video surveillance content, image defect detection for industrial equipment, inference computing for local office terminals, and leasing GPU computing power to AI model users for nearby small and medium-sized enterprises or mobile terminal users. However, the center faces challenges in proving the availability and stable online status of computing power, evaluating service quality and user value, incentivizing participants to provide continuous supply while avoiding speculation, and attracting users to participate in trust evaluation and incentive allocation.

[0121] Through the blockchain consensus method provided in the embodiments of this application, on the supply side, each blockchain node authenticates its physical location and time window through Beidou signals and confirms ownership on the chain, ensuring the authenticity and reliability of computing power. When a node completes an AI reasoning task, the system records its contribution and issues tokens as an immediate incentive. At the same time, the node's service score is quantified based on four dimensions: geographical distribution, online stability, task completion, and user trust. This affects its next round of block weight and reward ratio, forming a dynamic supply incentive mechanism.

[0122] On the demand side, users of the service can "like" and "evaluate" through light nodes such as terminal apps, web pages, or devices. Their call records, consumption behavior, and like weights will be recorded on the chain, becoming the social endorsement of the node service. User behavior affects the user trust index of the node, which in turn affects its reward weight, transforming users from "trust consumers" to consensus participants in the production relationship. In terms of sustainability, as the usage scenario changes, the workload, distribution density, and user activity of the node will change dynamically. The system dynamically adjusts incentive distribution through the automatic normalization and weight adjustment mechanism of on-chain indicators to adapt to market supply and demand. It does not rely on a single platform operator, but rather a production relationship shaped by node performance and user behavior, achieving a dynamic balance between computing power supply and demand and the sustainable development of the system.

[0123] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the working principle of the device. It can be understood that in order to realize the above functions, the blockchain consensus device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0124] In the embodiments of the present application, the functional modules of the blockchain consensus device can be divided according to the above method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into a single processing module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0125] It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods. Figure 3 A possible schematic diagram of the composition of the blockchain consensus device involved in the above and embodiments is shown. Figure 3 As shown, the blockchain consensus device 300 may include: a screening module 301, an acquisition module 302 and a determination module 303.

[0126] Among them, the screening module 301 is used to support the blockchain consensus device 300 to execute Figure 2 Schematic diagram of S201 and S204 in the blockchain consensus method.

[0127] Acquisition module 302, used to support the blockchain consensus device 300 to execute Figure 2 S202 in the illustrated blockchain consensus method.

[0128] Determination module 303, used to support the blockchain consensus device 300 to execute Figure 2 S203 in the illustrated blockchain consensus method.

[0129] In one possible implementation, the blockchain consensus device can be specifically configured to determine the geographic distribution breadth of candidate nodes in a blockchain system based on the geographic location information of all candidate nodes. Geographic distribution breadth represents the global distribution range of candidate nodes in longitude and latitude. For each candidate node, the online service indicator is determined based on the available time and theoretical online time. The number of valid task completions is determined based on the historical number of calls, the unit computing power of tasks, and the service completion success rate. The user trust indicator is determined based on the number of calls and historical valid feedback information. The block production weight of the candidate node is determined based on the geographic distribution breadth, online service indicator, valid task completion data, and user trust indicator.

[0130] In one possible implementation, the blockchain consensus device can be specifically configured to assign a weight range to each candidate node based on the block production weight of each candidate node. The weight range corresponds to the candidate node's block production weight and is determined by dividing the sum of the block production weights of all candidate nodes into a number of consecutive sub-ranges. A generated random number is obtained. The random number is within the sum of the block production weights of all candidate nodes. Based on the random number, a block production weight range is selected from all weight ranges. The block production weight range corresponds to the block producing node. The block producing node is the candidate node corresponding to the block production weight range.

[0131] In one possible implementation, the blockchain consensus device can be configured to receive a spatiotemporal credential uploaded by any blockchain node from among all blockchain nodes. The spatiotemporal credential includes geographic location information and a timestamp. The geographic location information is determined based on satellite signals from multiple satellites acquired when the blockchain node is started. The timestamp indicates the time the spatiotemporal credential was generated. If the geographic location information is determined to fall within a preset geographic location range and the timestamp falls within a preset timestamp range, the blockchain node is determined to be a candidate node.

[0132] In one possible implementation, the spatiotemporal credential also includes the blockchain node's carrier phase error. Specifically, the blockchain consensus device can be used to determine the blockchain node's movement path at multiple timestamps based on the geographic location information and carrier phase error at multiple timestamps. If the movement path is determined to be continuous and conforms to pre-set movement path detection rules, the blockchain node is identified as a candidate node.

[0133] In one possible implementation, the blockchain consensus device can be used to determine the total reward amount corresponding to a service call. The total reward amount is determined based on the complexity of the service call and the estimated resource consumption. The total reward amount is split into a first reward and a second reward according to a preset distribution ratio. The distribution ratio is dynamically adjusted based on the blockchain system's incentive strategy. The first reward is distributed to the block-producing node. The second reward is distributed to all candidate nodes other than the block-producing node based on their block production weights.

[0134] In one possible implementation, the blockchain consensus device can be used to determine the reward distribution ratio corresponding to each candidate node other than the block-producing node based on the block production weight of the candidate node other than the block-producing node. Based on the reward distribution ratio, the second reward is distributed to the corresponding candidate node.

[0135] In one possible implementation, the blockchain consensus device can be configured to receive user feedback on a block-producing node's service after the node completes a service call. The feedback carries a signature from the user's wallet. If the signature is valid, the feedback is considered valid.

[0136] It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0137] The blockchain consensus device 300 provided in the embodiment of the present application is used to execute the above Figure 2 The blockchain consensus method shown can therefore achieve the same effect as the above-mentioned blockchain consensus method.

[0138] The embodiment of the present application also provides a blockchain consensus device, which can execute the blockchain consensus method and related steps in the above method embodiment.

[0139] An embodiment of the present application also provides a computer-readable storage medium having instructions stored thereon, which, when executed, execute the blockchain consensus method and related steps in the above method embodiment.

[0140] An embodiment of the present application also provides a computer program product, which, when executed on a computer, enables the computer to execute the blockchain consensus method and related steps in the above method embodiment.

[0141] In some embodiments, the methods described herein may be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or on other non-transitory media or articles of manufacture.

[0142] The present application also provides a blockchain consensus system 400, such as Figure 4 As shown, the blockchain consensus system 400 includes at least one processor 401 and at least one interface circuit 402.

[0143] As an example, when the blockchain consensus system 400 includes a processor and an interface circuit, the processor may be Figure 4 The processor 401 shown in the solid line frame (or the processor 401 shown in the dotted line frame) may be Figure 4 The interface circuit 402 shown in the solid line frame (or the interface circuit 402 shown in the dotted line frame). When the blockchain consensus system 400 includes two processors and two interface circuits, the two processors include Figure 4 The processor 401 shown in the solid line frame and the processor 401 shown in the dotted line frame, the two interface circuits include Figure 4 The interface circuit 402 shown in the solid line frame and the interface circuit 402 shown in the dotted line frame are not limited to this.

[0144] The processor 401 and the interface circuit 402 can be interconnected via a line. For example, the interface circuit 402 can be used to receive signals. For another example, the interface circuit 402 can be used to send signals to other devices (such as the processor 401). For example, the interface circuit 402 can read computer instructions stored in the memory and send the computer instructions to the processor 401. The processor 401 executes the instructions and, in conjunction with the input and output devices, implements the various steps in the above embodiments, such as implementing Figure 2 Of course, the blockchain consensus system may also include other discrete components, which are not specifically limited in this embodiment of the present application.

[0145] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0146] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0147] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0148] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0149] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the contributing part or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0150] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A blockchain consensus method, characterized in that: Applied to a blockchain system, the blockchain system includes multiple blockchain nodes; the method includes: In response to a service call submitted by a user through a light node, at least one candidate node is selected from all blockchain nodes; the candidate node is a node with a valid spatiotemporal credential among the multiple blockchain nodes; the validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node; Obtain node information for each candidate node; the node information includes geographic location information, available time information, historical service call information, and historical valid feedback information; the available time information includes available time and theoretical online time; the historical service call information includes: historical call count, task unit computing power value, and service completion success rate; Determine the block production weight of the candidate node according to the node information of the candidate node; Filtering a block-producing node from all candidate nodes based on the block-producing weight of each candidate node to respond to the service call; The method of screening out a block-producing node from all candidate nodes according to the block-producing weight of each candidate node includes: allocating a weight interval to each candidate node according to the block-producing weight of each candidate node; the range of the weight interval is proportional to the block-producing weight of the candidate node, and the range of the weight interval is determined by dividing the sum of the block-producing weights of all candidate nodes into a number of continuous sub-intervals; obtaining a generated random number; the random number is within the range of the sum of the block-producing weights of all candidate nodes; screening out a block-producing weight interval from all weight intervals according to the random number; the block-producing weight interval corresponds to the block-producing node; and the block-producing node is the candidate node corresponding to the block-producing weight interval.

2. The method according to claim 1, characterized in that The determining the block production weight of the candidate node according to the node information of the candidate node includes: Determine the geographic distribution breadth of the candidate nodes in the blockchain system based on the geographic location information of all candidate nodes; the geographic distribution breadth is used to represent the distribution range of the candidate nodes in global longitude and latitude; For any candidate node among all candidate nodes, determining an online service indicator of the candidate node according to the available time and the theoretical online time; Determine the number of valid task completions based on the historical call count, the task unit computing power value, and the service completion success rate; Determining a user usage trust indicator based on the number of calls and the historical valid feedback information; The block production weight of the candidate node is determined according to the geographical distribution breadth, the online service index, the effective task completion data and the user usage trust index.

3. The method according to claim 1, characterized in that The step of selecting at least one candidate node from all blockchain nodes includes: For any blockchain node among all blockchain nodes, receiving a spatiotemporal credential of the blockchain node uploaded by the blockchain node; the spatiotemporal credential includes geographic location information and a timestamp; the geographic location information is determined based on satellite signals of multiple satellites acquired when the blockchain node is started; the timestamp is used to indicate the time when the spatiotemporal credential was generated; When it is determined that the geographic location information belongs to a preset geographic location range and the timestamp belongs to a preset timestamp range, the blockchain node is determined to be the candidate node.

4. The method according to claim 3, characterized in that The space-time certificate also includes a carrier phase error of the blockchain node; the method further includes: Determining a movement path of the blockchain node at multiple timestamps based on the geographic location information and the carrier phase error at multiple timestamps; When it is determined that the movement path is continuous and complies with a preset movement path detection rule, the blockchain node is determined as the candidate node.

5. The method according to claim 1, wherein The method further comprises: Determining a total reward amount corresponding to the service call; the total reward amount is determined based on the complexity of the service call and the estimated resource consumption; Splitting the total reward into a first reward and a second reward according to a preset distribution ratio; the distribution ratio is dynamically adjusted according to the incentive strategy of the blockchain system; Allocating the first reward to the block producing node; Based on the block production weights of the candidate nodes other than the block production node, the second reward is distributed to all candidate nodes other than the block production node.

6. The method according to claim 5, characterized in that The distributing the second reward to all candidate nodes other than the block producing node based on the block producing weights of the candidate nodes other than the block producing node includes: Determine the reward allocation ratio corresponding to each candidate node other than the block-producing node based on the block-producing weights of the candidate nodes other than the block-producing node; Based on the reward distribution ratio, the second reward is distributed to the corresponding candidate nodes.

7. The method according to claim 1, characterized in that The method further comprises: After the block producing node completes the service call, receiving the user's service feedback information on the block producing node; the service feedback information carries the signature information signed by the user through the user wallet; If it is determined that the signature information is valid, the service feedback information is determined to be valid feedback information.

8. A blockchain consensus device, characterized in that: Applied to a blockchain system, the blockchain system includes multiple blockchain nodes; the device includes: A screening module, configured to screen at least one candidate node from all blockchain nodes in response to a service call submitted by a user through a light node; the candidate node is a node with a valid spatiotemporal credential among the plurality of blockchain nodes; the validity of the spatiotemporal credential is determined based on the geographic location information and timestamp uploaded by the blockchain node; An acquisition module is configured to acquire node information of each candidate node; the node information includes geographic location information, available time information, historical service call information, and historical valid feedback information; the available time information includes available time and theoretical online time; the historical service call information includes: historical call count, task unit computing power value, and service completion success rate; A determination module, configured to determine the block production weight of the candidate node based on the node information of the candidate node; The screening module is further configured to screen out a block-producing node from all candidate nodes based on the block-producing weight of each candidate node, so as to respond to the service call; The screening module is specifically configured to assign a weight interval to each candidate node based on the block production weight of each candidate node; the range of the weight interval is proportional to the block production weight of the candidate node, and the range of the weight interval is determined by dividing the sum of the block production weights of all candidate nodes into a number of continuous sub-intervals; obtain a generated random number; the random number is within the sum of the block production weights of all candidate nodes; based on the random number, screen out a block production weight interval from all weight intervals; the block production weight interval corresponds to the block production node; the block production node is the candidate node corresponding to the block production weight interval.

9. A blockchain consensus device, characterized in that: The blockchain consensus device includes a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the blockchain consensus method according to any one of claims 1 to 7.

Images