Multi-robot consistency Byzantine fault detection method

Abstract

The invention relates to the technical field of robot fault recognition, and provides a multi-robot consistency Byzantine fault detection method. The method comprises the steps that observation motion information of each target robot in the multi-robot system at the current moment is acquired; encrypting each piece of observation motion information to obtain encrypted information of each piece of observation motion information, and uploading all the encrypted information to the block chain; decrypting and integrating all encrypted information at the current moment on the block chain to obtain a state data frame at the current moment; and when the state data frames are conflict data frames, determining the number of supporters and the number of counters of each target robot according to the conflict data frames, and determining a Byzantine fault robot from all the target robots based on the number of supporters and the number of counters of all the target robots. According to the method, the Byzantine fault identification reliability can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of robot fault identification, and in particular to a multi-robot consistent Byzantine fault detection method. Background Art

[0002] In multi-robot consensus research, the group needs to reach consensus on one or more state variables. However, when a small number of robots exhibit malicious behavior, such as Byzantine faults, group consensus becomes difficult to achieve. Existing Byzantine fault detection methods are mostly based on the Weighted Mean Subsequence Reduction method (WMSR) and its improvements. This method generally collects the state values ​​of nearby neighboring robots and identifies outliers, then locates the faulty robot or excludes its data. Researchers have successfully implemented this method in blockchain smart contracts. While this method can help address Byzantine faults encountered during multi-robot consensus, it still has some limitations, such as the requirement to know the number of Byzantine robots F in advance, the need for each robot to maintain 2F + 1 neighbors, and inconsistent detection results between different robots. Overall, the reliability of current Byzantine fault detection is low. Summary of the Invention

[0003] The present application provides a multi-robot consensus Byzantine fault detection method, which can solve the problem of low reliability of Byzantine fault detection.

[0004] The present application provides a multi-robot consensus Byzantine fault detection method, which includes: Obtaining the observed motion information of each target robot in the multi-robot system at the current moment; the observed motion information includes the motion information of the target robot itself and the motion information of multiple neighboring robots of the target robot; Encrypt each observed motion information, obtain the encrypted information of each observed motion information, and upload all encrypted information to the blockchain; Decrypt and integrate all encrypted information on the blockchain at the current moment to obtain the current state data frame; the state data frame includes the observed motion information of all target robots at the corresponding moment; When the status data frame is a conflict data frame, the number of supporters and opponents of each target robot is determined according to the conflict data frame, and based on the number of supporters and opponents of all target robots, the Byzantine fault robot is determined from all target robots; the conflict data frame is a status data frame in which there is a conflict in the motion information of the target robot, and the Byzantine fault robot is the target robot that uploads incorrect information.

[0005] Optionally, each piece of observed motion information is encrypted to obtain encrypted information of each piece of observed motion information, including: For each piece of observed motion information, perform the following steps: Obtain the private key of the target robot corresponding to the observed motion information and the public key on the blockchain; The observed motion information is encrypted using the public key on the blockchain to obtain the encrypted payload; Generate a digital signature of the target robot corresponding to the observed motion information using the target robot's private key; The identification information of the target robot corresponding to the observed motion information, the time corresponding to the observed motion information, the encrypted payload, and the digital signature are integrated into one data to obtain the encrypted information of the observed motion information.

[0006] Optionally, determine the number of supporters and opponents of each target robot based on the conflict data frame, including: For each target robot, perform the following steps: Other robots whose observed motion information in the conflict data frame includes the motion information of the target robot are used as observation robots; The number of supporters and the number of opponents of the target robot are determined according to the observed motion information of all observing robots in the conflict data frame and the observed motion information of the target robot in the conflict data frame.

[0007] Optionally, determining the number of supporters and opponents of the target robot based on the observed motion information of all observing robots in the conflict data frame and the observed motion information of the target robot in the conflict data frame includes: For each observing robot, determining whether the motion information of the target robot included in the observed motion information of the observing robot in the conflict data frame is the same as the motion information of the target robot included in the observed motion information of the target robot in the conflict data frame; if so, the observing robot is regarded as a supporter of the target robot; otherwise, the observing robot is regarded as an opponent of the target robot; The number of supporters of the target robot is counted to obtain the number of supporters of the target robot, and the number of opponents of the target robot is counted to obtain the number of opponents of the target robot.

[0008] Optionally, based on the number of supporters and opponents of all target robots, identify Byzantine fault robots from all target robots, including: Calculate the reputation value of each target robot based on the number of supporters and opponents of each target robot; Identify Byzantine faulty robots from all target robots based on all reputation values.

[0009] Optionally, calculate the reputation value of each target robot based on the number of supporters and opponents of each target robot, including: When the number of supporters of the target robot is greater than the number of opponents, the initial reputation value of the target robot is increased by a preset value to obtain the reputation value of the target robot; When the number of supporters of the target robot is less than the number of opponents, the initial reputation value of the target robot is reduced by a preset value to obtain the reputation value of the target robot.

[0010] Optionally, determine Byzantine faulty robots from all target robots based on all reputation values, including: For each target robot, perform the following steps: Determine whether the reputation value of the target robot is less than the reputation value threshold; If so, it is considered that the target robot uploads error information at the current moment and the target robot is marked as a Byzantine fault robot.

[0011] Optionally, after the step of determining a Byzantine fault robot from all target robots according to all reputation values, the multi-robot consensus Byzantine fault detection method further includes: Isolate all Byzantine fault bots.

[0012] The above solution of the present application has the following beneficial effects: In some embodiments of the present application, by obtaining the observed motion information of each target robot in the multi-robot system at the current moment, then encrypting each observed motion information to obtain the encrypted information of each observed motion information, and uploading all the encrypted information to the blockchain, and then decrypting and integrating all the encrypted information at the current moment on the blockchain to obtain the state data frame at the current moment, when the state data frame is a conflict data frame, the number of supporters and the number of opponents of each target robot are determined according to the conflict data frame, and based on the number of supporters and the number of opponents of all target robots, the Byzantine fault robot is determined from all target robots. Among them, the observed motion information is encrypted and uploaded to prevent the information from being tampered with, improve information security and reliability, calculate the number of supporters and the number of opponents based on the conflict data frame, and determine the Byzantine fault robot, taking into account the motion information observed by all target robots, and effectively improving the reliability of Byzantine fault detection.

[0013] Other beneficial effects of the present application will be described in detail in the subsequent specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0015] Figure 1 A flowchart of a multi-robot consensus Byzantine fault detection method provided in one embodiment of the present application; Figure 2 A schematic diagram of an encrypted ROS message communication mechanism provided in one embodiment of the present application; Figure 3 A flowchart of robot behavior provided in one embodiment of the present application; Figure 4 A schematic diagram of an estimated value change curve provided in an embodiment of the present application; Figure 5 A schematic diagram of the statistical results of estimation error and convergence time provided in one embodiment of the present application. DETAILED DESCRIPTION

[0016] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0017] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0018] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0019] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0020] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0021] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0022] In response to the low reliability of existing Byzantine fault detection, an embodiment of the present application provides a multi-robot consistency Byzantine fault detection method. The multi-robot consistency Byzantine fault detection method obtains the observed motion information of each target robot in the multi-robot system at the current moment, then encrypts each observed motion information to obtain the encrypted information of each observed motion information, and uploads all the encrypted information to the blockchain. Then, all the encrypted information at the current moment on the blockchain is decrypted and integrated to obtain the status data frame at the current moment. When the status data frame is a conflict data frame, the number of supporters and opponents of each target robot is determined according to the conflict data frame, and based on the number of supporters and opponents of all target robots, the Byzantine fault robot is determined from all target robots. Among them, the observed motion information is encrypted and uploaded to prevent information from being tampered with, improve information security and reliability, calculate the number of supporters and opponents based on the conflict data frame, and determine the Byzantine fault robot. This method takes into account the motion information observed by all target robots, effectively improving the reliability of Byzantine fault detection.

[0023] Next, the multi-robot consistency Byzantine fault detection method provided by this application is exemplified.

[0024] like Figure 1 As shown, the multi-robot consistency Byzantine fault detection method provided by this application includes the following steps: Step 11: Obtain the observed motion information of each target robot in the multi-robot system at the current moment.

[0025] The above-mentioned observed motion information includes the motion information of the target robot itself (such as position, speed, acceleration, etc.) and the motion information of multiple neighboring robots of the target robot (such as position, speed, acceleration, etc.). The above-mentioned multi-robot system is a system including multiple target robots performing tasks together, such as an autonomous driving fleet system, etc. The neighboring robots are other target robots within a preset range around the target robot.

[0026] In some embodiments of the present application, observation information of the target robot may be obtained through sensors, radars, and other equipment provided on the target robot.

[0027] For example, at the current moment, there are three neighboring robots within a preset range around the target robot, and the observed motion information of the target robot includes its own motion information and the motion information of the three neighboring robots.

[0028] It should be noted that this step can be implemented using the control system of the target robot itself.

[0029] It is worth mentioning that by obtaining the motion information of neighboring robots within a preset range around the target robot, that is, the neighboring robots change with the movement of the target robot, there is no need to maintain a fixed information list of neighboring robots, which reduces the computing resource usage.

[0030] Step 12: Encrypt each observed motion information to obtain the encrypted information of each observed motion information, and upload all the encrypted information to the blockchain.

[0031] In some embodiments of the present application, the step of encrypting each piece of observed motion information to obtain encrypted information of each piece of observed motion information includes: For each piece of observed motion information, perform the following steps: The first step is to obtain the private key of the target robot corresponding to the observed motion information and the public key on the blockchain.

[0032] Exemplarily, an asymmetric encryption algorithm can be used to generate the private key and public key of the target robot, and the public key and private key can be generated on the blockchain at the same time. The public key on the blockchain is sent to the device or system that performs this step (such as the control system of the target robot itself), and the public key of the target robot is sent to the blockchain at the same time (that is, the public keys of both the target robot and the blockchain exist).

[0033] The second step is to use the public key on the blockchain to encrypt the observed motion information and obtain the encrypted payload.

[0034] For example, an asymmetric encryption algorithm can be used to encrypt the observed motion information using the public key on the blockchain.

[0035] The third step is to use the private key of the target robot to generate the digital signature of the target robot corresponding to the observed motion information.

[0036] Exemplarily, an asymmetric encryption algorithm may be used to generate a digital signature of the target robot corresponding to the observed motion information using the private key of the target robot.

[0037] The fourth step is to integrate the identification information of the target robot corresponding to the observed motion information, the time corresponding to the observed motion information, the encrypted payload, and the digital signature into one data to obtain the encrypted information of the observed motion information.

[0038] The above identification information is used to indicate the identity of the target robot, and may be an identity ID, a number, etc.

[0039] It should be noted that encrypting the observed motion information before transmission can prevent information tampering, which can lead to fault detection errors. For example, there are three target robots, target robot 1, target robot 2, and target robot 3, located at positions A, B, and C respectively (motion information). The three target robots can observe each other. Then the data recorded by target robots 1, 2, and 3 are as follows: ; ; ; in, , 2, 3 represent the target robot numbers for recording data, Indicates the time when the data was recorded. in It means that target robot 1 observes target robot 2 at position B. It means that target robot 1 observes target robot 3 at position C, in It means that target robot 2 observes target robot 1 at position A. It means that target robot 2 observes target robot 3 at position C, in It means that target robot 3 observes target robot 1 at position A. This indicates that target robot 3 observes target robot 2 at position B.

[0040] If all target robots are normal, then when this information is aggregated on the blockchain and checked by the smart contract, no conflict will be detected and everything will be normal.

[0041] However, if there are Byzantine robots, conflicts will arise. Assume that target robots 1 and 2 are normal robots, and target robot 3 is a Byzantine robot. First, target robot 3 will lie and tamper with the data it is about to submit to the blockchain to data that does not conform to the actual situation, such as tampering with Then, when the smart contract is finally tested, it will be found that the support rate for target robot 3 at point A is 1 / 3, and the support rate for target robot 3 at point C is 2 / 3. According to the majority rule, it is finally determined that target robot 3 is at point C, which is consistent with the actual situation. There is no problem at this time, but if there is no encryption, target robot 3 will first tamper with its own data, and then intercept the message of target robot 2 and tamper with the data in it. For example, the data of target robot 2 will be tampered with , then when the smart contract performs statistical testing, it will detect that the support rate of target robot 3 at point A is 2 / 3, and the support rate of target robot 3 at point C is 1 / 3. It will eventually determine that target robot 3 is located at point A, which does not conform to the actual situation. That is, the Byzantine robot has successfully committed evil, concealed its location and has not been discovered.

[0042] It should be noted that this step can be implemented using the control system of the target robot itself.

[0043] Step 13: decrypt and integrate all encrypted information on the blockchain at the current moment to obtain the status data frame at the current moment.

[0044] The above state data frame includes the observed motion information of all target robots at the corresponding moment.

[0045] It should be noted that to decrypt encrypted information on the blockchain, based on the principle of asymmetric encryption algorithm, the public key of the target robot on the blockchain can be used to verify the digital signature in the encrypted information, confirm the source and integrity of the message, and if the verification is passed, the private key on the blockchain can be used to decrypt the encrypted data.

[0046] The encrypted information recorded on the blockchain is disorganized. Although each target robot periodically submits its observed information to the blockchain in chronological order, the blockchain also exchanges messages with other target robots, synchronizes data, and re-sorts the data, which may not necessarily remain consistent with chronological order. Therefore, the data aggregated on the blockchain needs to be classified and sorted. Classification involves categorizing all recorded information by target robot ID. Sorting further sorts the classified data by time, integrating the observed motion information at each moment.

[0047] For example, all the decrypted observed motion information at the current moment is sorted in sequence according to the identification information of the target robot to obtain a state data frame. The position information in a state data frame including four uploaded encrypted information is shown in Table 1: Table 1 ; The observation list contains the IDs and positions of neighbor robots observed by the target robot. The numbers represent the IDs of neighbor robots, P2 and P3 represent the positions of neighbor robots, and a blank indicates that the target robot has not observed a neighbor robot.

[0048] Step 14: When the state data frame is a conflict data frame, the number of supporters and the number of opponents of each target robot are determined according to the conflict data frame, and based on the number of supporters and the number of opponents of all target robots, the Byzantine fault robot is determined from all target robots.

[0049] The conflicting data frames are state data frames containing conflicting target robot motion information. If all observed motion information for a particular target robot is inconsistent within the state data frame, the state data frame is considered a conflicting frame. A Byzantine fault robot is a target robot that uploads incorrect information. Supporters are other robots that observe the target robot's motion information and that this information is consistent with the target robot's own observed motion information. Opponents are other robots that observe the target robot's motion information and that this information is inconsistent with the target robot's own observed motion information.

[0050] It should be noted that if the state data frame is not a conflict data frame, all target robots at the current moment will not be processed.

[0051] In some embodiments of the present application, the steps of determining the number of supporters and the number of opponents of each target robot according to the conflict data frame, and determining the Byzantine fault robot from all target robots based on the number of supporters and the number of opponents of all target robots include: In the first step, the number of supporters and opponents of each target robot is determined based on the conflict data frame.

[0052] Specifically, for each target robot, perform the following steps: First, other robots whose observed motion information in the conflict data frame includes the motion information of the target robot are used as observation robots.

[0053] Then, the number of supporters and the number of opponents of the target robot are determined according to the observed motion information of all observation robots in the conflict data frame and the observed motion information of the target robot in the conflict data frame.

[0054] Specifically, for each observation robot, determine whether the motion information of the target robot contained in the observation motion information of the observation robot in the conflict data frame is the same as the motion information of the target robot contained in the observation motion information of the target robot in the conflict data frame. If so, the observation robot is regarded as a supporter of the target robot; otherwise, the observation robot is regarded as an opponent of the target robot.

[0055] The number of supporters of the target robot is counted to obtain the number of supporters of the target robot, and the number of opponents of the target robot is counted to obtain the number of opponents of the target robot.

[0056] In the second step, the reputation value of each target robot is calculated based on the number of supporters and opponents of each target robot.

[0057] Specifically, when the number of supporters of the target robot is greater than the number of opponents, the initial reputation value of the target robot is increased by a preset value to obtain the reputation value of the target robot.

[0058] When the number of supporters of the target robot is less than the number of opponents, the initial reputation value of the target robot is reduced by a preset value to obtain the reputation value of the target robot.

[0059] When the number of supporters of the target robot is equal to the number of opponents, the initial reputation value of the target robot will not be adjusted.

[0060] It should be noted that, before the current moment, if Byzantine fault detection has been performed and the reputation value of the target robot has been adjusted, the last adjusted reputation value will be used as the initial reputation value of this step. If Byzantine fault detection has not been performed, the preset initial value will be used as the initial reputation value of this step.

[0061] In the third step, the Byzantine faulty robots are identified from all target robots according to all reputation values.

[0062] Specifically, for each target robot, perform the following steps: Determine whether the reputation value of the target robot is less than the reputation value threshold.

[0063] If so, it is considered that the target robot uploads error information at the current moment and the target robot is marked as a Byzantine fault robot.

[0064] Otherwise, the target robot is not marked, and the reputation value of the target robot is recorded as the initial reputation value of the target robot in the next Byzantine fault identification.

[0065] It should be noted that the aforementioned reputation thresholds are preset values. Once Byzantine faulty robots are identified, they are isolated (no longer receiving their uploaded information, and even stopping their motion programs and communication with them, among other actions, to prevent them from impacting the overall mission of the multi-robot system). Steps 13 and 14 can both be implemented through smart contracts on the blockchain.

[0066] It is worth mentioning that the observed motion information is encrypted before uploading to prevent information tampering, improve information security and reliability, calculate the number of supporters and opponents based on the conflict data frame, and determine the Byzantine fault robots. The motion information observed by all target robots is taken into account, which effectively improves the reliability of Byzantine fault detection.

[0067] In addition, the method of the present application has the following advantages: Architectural advantages: A hybrid monitoring architecture is adopted, combining local neighbor observation and global blockchain verification to realize a distributed monitoring network, ensuring data reliability and system scalability. The state observation of each target robot is recorded in an unalterable manner on the blockchain, and Byzantine fault robots are detected through smart contract rule audits.

[0068] Security features: Encrypted communication uses asymmetric encryption and digital signature mechanisms. Each target robot generates a public / private key pair and exchanges public keys for message encryption, effectively preventing man-in-the-middle attacks, ensuring the security and authenticity of message transmission, and providing strong security protection for the system.

[0069] Innovation in detection mechanism: The innovative three-stage detection process significantly improves the accuracy of fault detection through historical state reconstruction, multi-perspective analysis, and dynamic reputation adjustment. The multi-perspective comparison implemented by smart contracts enhances the system's fault tolerance. The dynamic reputation adjustment mechanism can effectively isolate Byzantine nodes and improve the robustness of the system.

[0070] The method of the present application is illustrated below with reference to a specific example.

[0071] Encrypted Robot Operating System (ROS) message communication mechanism such as Figure 2 As shown, the sender (i.e., the robot)’s plaintext ( , For robot identification, For time, is the robot position, For the robot point of view, The neighbor observation list) is encrypted with the receiver's (i.e., blockchain) public key to obtain the ciphertext, and signed with the sender's private key to obtain a digital signature. The two are serialized to obtain an encrypted ROS message, and the message is published to the POS topic of "sender ID / topic name" corresponding to the sender. The receiver subscribes to the message to obtain the encrypted ROS message, deserializes it to obtain the ciphertext and digital signature, and uses the receiver's private key to decrypt the ciphertext to obtain the plaintext, which is verified based on the digital signature, plaintext, and sender's key.

[0072] Each robot initially generates a pair of public and private keys and exchanges them with other robots. These public and private keys are used to encrypt and decrypt messages in subsequent processes. First, the sender encrypts the plaintext to be sent using the receiver's public key, producing ciphertext that can only be decrypted by the receiver using their private key. Simultaneously, the sender signs the plaintext using its own private key and a hash function, creating a digital signature that also serves as a digital digest. The sender then packages the ciphertext and digital signature into a serialized ROS message and publishes it to the topic "sender ID / topic name" corresponding to the sender ID.

[0073] The receiver continuously listens to the topic. Once a new ROS message arrives, the receiver's callback function is automatically triggered. This callback function subscribes to messages on the topic, deserializes the ROS message into its original type, and obtains the corresponding ciphertext and digital signature. The receiver then decrypts the ciphertext using its private key to obtain a plaintext segment. To verify that the plaintext is sent by the sender and has not been tampered with, the receiver passes the sender's public key, the decrypted plaintext, and the digital signature to the verification function for verification. If verification succeeds, the plaintext is considered valid.

[0074] By introducing asymmetric encryption algorithms as a security protection mechanism, the security of the ROS subscription / publish communication model can be improved, preventing unauthorized access and data tampering. This enhanced security helps build trust between multiple robots and protect the robotic system from potential security threats, thereby reducing the additional system processing delay caused by attacks launched by malicious nodes. Although encryption and decryption increase the computational burden and communication latency, the impact can be reduced and communication efficiency can be guaranteed by selecting efficient algorithms and optimizing the encryption process. Therefore, secure encryption mechanisms contribute to improving the overall performance of the system to a certain extent. In summary, the impact of secure encryption mechanisms on the efficient consensus of robots is positive, but of course, the balance between security and efficiency must be considered.

[0075] The data frame at time t is shown in Table 2.

[0076] Table 2 ; in, represents the position of robot 1 itself, represents the position of robot 2 itself, represents the position of robot 3 itself, represents the position of the robot 4 itself, represents the perspective of robot 1 itself, Indicates the perspective of robot 2 itself, Indicates the perspective of robot 3 itself, Represents the viewpoint of robot 4 itself, which is other information observed by the robot, such as the color of the floor tiles at its location. The position of robot 2 as observed by robot 1 and Views , The position of robot 3 as observed by robot 1 and Views , The position of robot 1 as observed by robot 2 and Views , The position of robot 1 as observed by robot 3 and Views .

[0077] First, get the position reported by robot i at time t from each data frame df(t) and Views Then, in the same data frame df(t), the algorithm can determine whether other robots have observed this robot at time t by checking the observation list of each robot. For example, in Table 2, robot 1 has observed the states of robots 2 and 3.

[0078] For each neighbor robot j that observes robot i, further check whether the neighbor robot j in its observation list The position of robot i observed by robot j is and state perspectives Is it the same as the position claimed by robot i? and state perspectives Conflict (here only the visible state is detected, such as the color of the tile where robot i is located ). Based on the inspection results, the algorithm can calculate the number of supporters and opponents, that is, "at time t, robot i is in position Hold a point of view "The number of supporters and opponents of this statement. Next, the majority principle is used to determine whether robot i has lied and whether to increase or decrease the reputation of robot i. As the algorithm continues to execute, it will obtain a list R containing the accumulated reputation of all robots. This reputation list will be used in the Byzantine failure classification process. This process compares the reputation of the robot with the preset reputation threshold γ. If the reputation of robot i, i.e. Ri, is less than the threshold γ, robot i will be added to the Byzantine robot set Q, and its data will not be used in the next calculation.

[0079] The method of the present application is exemplified below with reference to a comparative experiment.

[0080] We compared the fault tolerance of our proposed method with that of the traditional Weighted Multi-Scale Regression (W-MSR) algorithm under different numbers of Byzantine failure robots. All experiments were conducted using the Epuck 2.0 robot on the Webots simulator.

[0081] The experimental environment is a square test table with randomly distributed black and white square tiles (in this experiment, the proportion of black tiles is 0.40). The size of each tile is 10cm 10cm. The size of the field is set to 2m 2m.

[0082] This experiment used ten simulated Epuck2.0 robots. The Epuck2.0 is a mobile microrobot with a cylindrical shape, 45 mm in height and 70 mm in diameter. The Epuck2.0 robot is equipped with eight infrared sensors that can measure ambient light and close proximity to objects up to 6 cm. It also features a color camera that provides downward observation of the color of floor tiles. Simulation was also used to enable the robots to sense and communicate with their neighbors. Both the robot's communication and perception ranges were set to 50 cm.

[0083] Normal robot behavior process follows Figure 3Its motion control follows three basic procedures: random walk, environment exploration, and obstacle avoidance. After starting, it performs random walk, environment exploration, or obstacle avoidance. Within the exploration environment, it sequentially performs image acquisition, color detection, calculation of the black block ratio, location acquisition, neighbor observation, submission of a vote quintuple (i.e., plaintext) to the blockchain replica, blockchain data synchronization, blockchain consensus data extraction, construction of a spatiotemporal data frame set, detection of conflicting opinions, updating the reputation list, classification of Byzantine robots, exclusion of Byzantine robot ratio estimates, online update of the ratio estimate, and determination of whether the standard error of the ratio estimate reaches a preset value. If so, the robot terminates; otherwise, it returns to the starting point. The ratio estimate describes the proportion of a specific piece of information relative to the total information in a multi-robot system. Furthermore, at each step, the robot samples the floor color using its downward-looking camera and observes the status of its neighboring robots. The robot calculates an estimate of the black ratio based on all samples collected over the past 10 seconds. Except for the initial 10 seconds, the robot submits a quintuple consisting of its ID, timestamp, location, sampled color, current estimated ratio, and a list of neighbor status observations to the blockchain interface at 1-second intervals. Simultaneously, a smart contract program on the blockchain extracts blockchain consensus data, constructs a spatiotemporal observation data frame, and detects whether neighbor observations conflict with the robot's submitted viewpoint. This information is then used to update the reputation list and, based on the difference between the reputation value and the reputation threshold, determines whether the robot is classified as a Byzantine robot. After excluding the proportion estimate data for Byzantine robots, an online algorithm is used to update the historical average proportion estimate and standard error for all robots. Finally, a check is performed to determine whether the standard error is less than a preset threshold. If so, the experiment is terminated; otherwise, the process is repeated.

[0084] This experiment sets the maximum number of Byzantine robots to between 0 and 5. A Byzantine robot tampers with sensor readings—that is, the tile colors captured by the downward-looking camera—and calculates a black proportion estimate based on these tampered colors. This experiment sets the Byzantine robot to continuously tamper with the captured colors to black, regardless of whether the sensor captures black or white, so that its proportion estimate remains constant at x = 1. Furthermore, if there are other Byzantine robots in its neighborhood, they will collude to send their tampered sample data to the neighboring Byzantine robots and modify the Byzantine robot's position and color in the local observation list based on the data sent by the neighboring Byzantine robots, thereby perjuring each other.

[0085] This experiment sets up indicators to measure the convergence performance of multi-robot joint cognition, namely the estimated value (intuitive feeling) and the estimation error (precise quantification); and the indicator to measure the efficiency of joint cognition, namely the convergence time.

[0086] Estimate: This metric shows how the estimated black ratio of each robot in the environment changes over time, reflecting the consensus convergence performance.

[0087] Estimation Error (EstimateError). This metric is the difference between the true proportion of black tiles and the proportion estimated by the final consensus of multiple robots. This experiment was repeated 10 times with the same settings, and the average error of these 10 experiments was calculated as the statistic.

[0088] Convergence Time. This metric indicates the time required for all robots' estimates to converge to a consensus estimate, or the time required for all non-Byzantine robots to roughly converge to a single value. The former applies to this method, while the latter applies to the W-MSR method. This metric is also the average of 10 experiments.

[0089] The experimental results obtained are as follows Figure 4 As shown, Figure 4 The horizontal axis represents time in seconds, the vertical axis represents the estimated value, F represents the upper limit of the number of tolerable Byzantine robots, f represents the number of Byzantine robots, and different curves represent different robots. Figure 4 a is the estimated value change curve when f=2 and F=2 under the W-MSR algorithm, Figure 4 b is the estimated value change curve when f=3 and F=2 under the W-MSR algorithm. Figure 4 c is the estimated value change curve when f=2 under the Blockchain method (i.e., the method of this application), Figure 4 d is the estimated value change curve when f=3 under the blockchain method.

[0090] When the number of Byzantine bots, f ≤ F, the W-MSR method shows good convergence performance. With the exception of the Byzantine bots, whose estimated value remains constant at x = 1.0, all non-Byzantine bots successfully converge to an approximation close to the true value (x = 0.4, gray dashed line). However, when f > F, the W-MSR method shows that all non-Byzantine bots are affected by the Byzantine bots, and their estimates converge to the Byzantine bots' estimate of x = 1.0.

[0091] The present method eliminates the need for prior knowledge of F, effectively eliminating the influence of Byzantine bots. The results show that regardless of whether the number of Byzantine bots is 2 or 3, the estimated values ​​of all bots (including Byzantine bots) converge to a level close to the true proportion value. This result has two implications. First, the convergence performance of the proportion estimate is unaffected by the number of Byzantine bots in the present method. This is because the present method does not use a preset upper limit on the number of Byzantine bots to determine the number of Byzantine bots or their identity. Instead, it uses neighbor observation information and the accumulated reputation of the bots to determine which is more likely to be a Byzantine bot. Therefore, if a robot is observed by its neighbors in an abnormal state, it will likely be detected. Second, the estimated values ​​of Byzantine and non-Byzantine bots converge consistently. This is because the statistical results are directly derived from the smart contract, rather than the output of the off-chain Byzantine bot controller. Blockchain-based smart contracts offer excellent isolation and fairness. Whether running in a normal robot's local virtual machine environment or a Byzantine bot's local virtual machine environment, the output data is consistent.

[0092] The box plot statistics of estimation error and convergence time are as follows Figure 5 As shown, Figure 5 The horizontal axis represents the number of Byzantine robots, the vertical line represents the maximum value range, the rectangular area represents the quartiles, and the rectangular points represent abnormal points. Figure 5 a is the estimation error result of the W-MSR method, and the vertical axis represents the estimation error. Figure 5 b is the estimated error result of the blockchain method (i.e., the method of this application), and the vertical axis represents the estimated error. Figure 5 c is the convergence time result of the W-MSR method. The vertical axis represents the convergence time in seconds. Figure 5 d is the convergence time result of the blockchain method (i.e., the method of this application), and the vertical axis represents the convergence time in seconds.

[0093] Looking at the estimation error metric, the W-MSR method's results show an average estimation error close to zero when dealing with a small number of Byzantine bots (f ≤ 2). When the number of Byzantine bots exceeds the tolerance threshold F = 2, which is preset in the W-MSR method, the average estimation error increases significantly (to around 0.6). In contrast, the results of the present application's method show that when f ≤ 5, the average estimation error remains close to zero. This result demonstrates that, with the preset F = 2, the W-MSR method's fault tolerance is only 20%, while the proposed method achieves 50%.

[0094] In order to further verify the consistency of the Byzantine failure detection results of each robot under the action of the method of the present application, the results of an experiment testing the method of the present application are shown in Table 3.

[0095] Table 3 ; This shows that robots 5 and 7 were set as Byzantine robots at the beginning of the experiment. By the end of the experiment, all robots detected the same Byzantine robot set, {5, 7}, indicating that all robots' detection results were consistent and correct. At the same time, the final proportion estimates of all robots were 0.388074353, indicating that the proportion estimates of all robots were consistent and close to the true proportion of 0.4.

[0096] For comparison, the experimental results of the W-MSR method are shown in Table 4.

[0097] Table 4 ; It can be seen that robots 6 and 8 were set as Byzantine robots at the beginning of the experiment. At the end of the experiment, the Byzantine robot set results detected by all robots were not completely consistent. First, the results of robots 6 and 8 were {4, 1} and {9, 3}, respectively. This is because as Byzantine robots, the local controller can freely change its own detection results. Second, the detection result of robot 4, {4, 1}, is also different from most correct detection results. This is because under the W-MSR method, robots can only use the latest estimated values ​​of current neighbors and outdated estimated values ​​of historical neighbors as inputs to the detection function. Due to insufficient message propagation, robot 4 may not have received the latest estimated values ​​of all robots, resulting in inconsistent detection results. Judging from the results of the final proportion estimate, the results of non-Byzantine robots are also inconsistent.

[0098] A comprehensive analysis of the above results reveals that the number of Byzantine robots that the W-MSR method can tolerate is related to its preset F value. When the number of Byzantine robots exceeds F, the results are completely affected by them, so its fault tolerance is P = F / N, where N is the total number of robots. The method proposed in this application, on the other hand, does not require a pre-defined upper limit on the number of tolerable Byzantine robots. Furthermore, even when the number of tolerable Byzantine robots is half the total number of robots in the swarm, it still maintains good anti-interference capabilities (the estimated error remains close to 0), so its fault tolerance is P = 50%.

[0099] Regarding the average convergence time metric, the proposed method shows a slight increase in average convergence time compared to the W-MSR method as the number of Byzantine robots increases. This is primarily because the W-MSR method does not require all robots to converge to the exact same value, but rather to a rough approximation (convergence is considered complete when the difference between the maximum and minimum estimates across all robots is less than a certain threshold). However, the proposed method, on the one hand, requires collecting all robots' estimates and forming a consensus, then calculating an identical average estimate based on all the consensus estimates; on the other hand, it requires using shared observation data to detect Byzantine robots before calculating the proportion estimate. These factors inevitably increase the time overhead.

[0100] The above experimental results show that our method outperforms the classic W-MSR method in terms of convergence performance and mean error, without significantly increasing convergence time. Furthermore, our method demonstrates greater flexibility in Byzantine fault tolerance (no need to pre-set an upper limit on the number of tolerable Byzantine bots) and robustness (compared to the W-MSR method, it can tolerate a higher number of Byzantine bots, up to 50% of the total number of bots).

[0101] The above is a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles described in the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A multi-robot consensus Byzantine fault detection method, characterized in that: include: Obtain the observed motion information of each target robot in the multi-robot system at the current moment; The observed motion information includes the motion information of the target robot itself and the motion information of multiple neighboring robots of the target robot; Encrypting each of the observed motion information to obtain encrypted information of each of the observed motion information, and uploading all the encrypted information to the blockchain; Decrypt and integrate all encrypted information on the blockchain at the current moment to obtain the current state data frame; the state data frame includes the observed motion information of all target robots at the corresponding moment; When the status data frame is a conflict data frame, the number of supporters and the number of opponents of each target robot are determined according to the conflict data frame, and based on the number of supporters and the number of opponents of all target robots, the Byzantine fault robot is determined from all target robots; the conflict data frame is a status data frame in which there is a conflict in the motion information of the target robot, and the Byzantine fault robot is a target robot that uploads erroneous information.

2. The multi-robot consensus Byzantine fault detection method according to claim 1, characterized in that: The step of encrypting each piece of observed motion information to obtain encrypted information of each piece of observed motion information includes: For each piece of observed motion information, perform the following steps: Obtain the private key of the target robot corresponding to the observed motion information and the public key on the blockchain; Encrypting the observed motion information using the public key on the blockchain to obtain an encrypted payload; Generating a digital signature of the target robot corresponding to the observed motion information using the private key of the target robot; The identification information of the target robot corresponding to the observed motion information, the time corresponding to the observed motion information, the encrypted payload, and the digital signature are integrated into one data to obtain the encrypted information of the observed motion information.

3. The multi-robot consensus Byzantine fault detection method according to claim 1, characterized in that: Determining the number of supporters and the number of opponents of each target robot according to the conflict data frame includes: For each target robot, perform the following steps: other robots whose observed motion information in the conflict data frame includes the motion information of the target robot as observation robots; The number of supporters and the number of opponents of the target robot are determined according to the observed motion information of all observation robots in the conflict data frame and the observed motion information of the target robot in the conflict data frame.

4. The multi-robot consensus Byzantine fault detection method according to claim 3, characterized in that: The determining the number of supporters and the number of opponents of the target robot according to the observed motion information of all observing robots in the conflict data frame and the observed motion information of the target robot in the conflict data frame includes: For each of the observing robots, determining whether the motion information of the target robot included in the observed motion information of the observing robot in the conflict data frame is the same as the motion information of the target robot included in the observed motion information of the target robot in the conflict data frame; if so, determining the observing robot as a supporter of the target robot; otherwise, determining the observing robot as an opponent of the target robot; The number of supporters of the target robot is counted to obtain the number of supporters of the target robot, and the number of opponents of the target robot is counted to obtain the number of opponents of the target robot.

5. The multi-robot consensus Byzantine fault detection method according to claim 1, characterized in that: The Byzantine fault robots are determined from all target robots based on the number of supporters and the number of opponents of all target robots, including: Calculating the reputation value of each target robot according to the number of supporters and the number of opponents of each target robot; Identify Byzantine faulty robots from all target robots based on all reputation values.

6. The multi-robot consensus Byzantine fault detection method according to claim 5, characterized in that: Calculating the reputation value of each target robot according to the number of supporters and the number of opponents of each target robot includes: When the number of supporters of the target robot is greater than the number of opponents, the initial reputation value of the target robot is increased by a preset value to obtain the reputation value of the target robot; When the number of supporters of the target robot is less than the number of opponents, the initial reputation value of the target robot is reduced by a preset value to obtain the reputation value of the target robot.

7. The multi-robot consensus Byzantine fault detection method according to claim 6, characterized in that: The step of determining the Byzantine fault robot from all target robots according to all reputation values ​​includes: For each target robot, perform the following steps: Determining whether the reputation value of the target robot is less than a reputation value threshold; If so, it is considered that the target robot uploads error information at the current moment, and the target robot is marked as a Byzantine fault robot.

8. The multi-robot consensus Byzantine fault detection method according to claim 7, characterized in that: After the step of determining the Byzantine fault robot from all target robots according to all reputation values, the multi-robot consistency Byzantine fault detection method further includes: Isolate all Byzantine fault bots.

Images