Fault-tolerant system-on-chip

The fault-tolerant system-on-chip (FTSOC) addresses the challenge of Byzantine faults by using a decentralized approach with PBFT consensus algorithms and blockchain technology to detect and isolate faulty elements, improving reliability and energy efficiency.

WO2025114904A1PCT designated stage expired Publication Date: 2025-06-05GHEYSARI ARMAN +2
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
PCT/IB2024/061908
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-11-28
Filing Date
2024-11-27
Publication Date
2025-06-05

AI Technical Summary

Technical Problem

Existing fault-tolerant systems-on-chip (SOCs) face challenges in detecting and isolating Byzantine faults, which can lead to incorrect data and control signals, compromising system reliability and energy efficiency.

Method used

The proposed fault-tolerant system-on-chip (FTSOC) employs a decentralized method using consensus algorithms, specifically the practical Byzantine fault tolerance (PBFT) algorithm, in conjunction with blockchain technology to detect and isolate faulty processing elements (FPEs). This involves broadcasting executable instruction segments, reaching consensus among consensus modules, generating and comparing Merkle tree roots, and identifying faulty elements to switch them off and purge their execution results.

Benefits of technology

The FTSOC effectively detects and isolates Byzantine faults, enhancing system reliability and reducing power consumption by identifying and shutting down faulty processing units, thereby mitigating the risks of single points of failure and energy wastage.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure IB2024061908_05062025_PF_FP_ABST
    Figure IB2024061908_05062025_PF_FP_ABST
Patent Text Reader

Abstract

A method for tolerating Byzantine faults in a many core system-on-chip (SOC). Each processing element on the SOC is controlled by a respective consensus module. Each consensus module receives instructions from an SOC controller and after running a practical Byzantine fault tolerance consensus algorithm with other consensus modules, sends instruction to respective processing element. After running instructions by processing elements, each respective consensus module stores respective execution results in a respective blockchain. Each consensus module calculates a Merkle tree root from respective blockchain and send it to an arbiter module installed on the SOC. The arbiter module identifies faulty processing elements based on receive Merkle tree roots and send identification numbers of faulty processing elements to the SOC controller. The SOC controller switches off all faulty elements and their consensus modules. Each live consensus module purges respective blockchain.
Need to check novelty before this filing date? Find Prior Art

Description

Ref-1403-02-0307001FAULT-TOLERANT SYSTEM-ON-CHIPCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of priority from IR Patent Application Ser. No. 140250140003006003, filed on November 28, 2023, entitled “A METHOD FOR TOLERATING AND DETECTING CRASH AND BYZANTINE FAULTS IN SYSTEM-ON-CHIP USING BLOCKCHAIN, CONSENSUS ALGORITHMS, AND AN INVENTED CONSENSUS ALGORITHM.” which is incorporated herein by reference in its entirety.TECHNICAL FIELD

[0002] The present invention relates to an exemplary fault-tolerant system-on-chip (SOC), and more particularly to an exemplary fault-tolerant SOC that may tolerate Byzantine faults using consensus algorithms (i.e., an exemplary practical Byzantine fault tolerance algorithm) and blockchain technology.BACKGROUND

[0003] Hardware faults in a computer systems, especially in a systems-on-chip, are a serious concern for the proper functioning of them. This concern will be compounded, especially if these systems are used in safety-critical applications e.g. automation and industrial settings. Byzantine faults is kind of hardware faults that may not always stop the hardware from working, but may provide wrong information which may cause serious consequences. For example, it may be a hardware Trojan file installed on a processor which the hardware Trojan file may not be activated all time but may be in some circumstances e.g. high speed or pressure. As a result, it may seem there is no faults in system and miss-inform an operator or user of the hardware.

[0004] To deal with these kind of faults, hardware redundancies such as triple or multiple modular redundancy have been used frequently since past. In multiple hardware redundancy, multiple processing units with the same function are placed next to each other, and the output ofRef-1403-02-0307001 each processing unit is fed into a voting circuit, and finally the input with the highest number of votes is used as the output. But the very basic problem that exists is that the voting circuit itself may have a problem and fail. In this case, the system failure is certain. This problem is called a single point of failure (SPF), which is a fundamental problem in the world of computer and electrical engineering. It is important to note that in multiple modular redundancy, faulty units are not discovered and only their effects are so-called masked. This may cause problem in two ways: system energy consumption and system monitoring. In terms of energy consumption, since the faulty processing unit remains in the system, it continues to consume energy. In terms of system monitoring, since the user does not know how many processing units are faulty, he / she still has high confidence in the system. If he knows that the fault tolerance threshold has been reached, he / she can take appropriate measures.

[0005] Therefore, there is need to provide a mechanism that not only may detect the Byzantine faults in SOC but also may isolate them. This may solve system energy consumption and system monitoring problems. Also to bring more robustness, the mechanism may operate in decentralized manner which may solve the SPF problem.SUMMARY

[0006] This summary is intended to provide an overview of the subject matter of the present disclosure, and is not intended to identify essential elements or key elements of the subject matter, nor is it intended to be used to determine the scope of the claimed implementations. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later. The proper scope of the present disclosure may be ascertained from the claims set forth below in view of the detailed description below and the drawings.

[0007] One or more exemplary embodiments describe an exemplary method for tolerating one or more exemplary faulty processing elements (FPEs), with a number of f, among a pluralityRef-1403-02-0307001 of exemplary processing elements (PEs), with a number of N > 3f, installed on an exemplary system-on-chip (SOC). In an exemplary embodiment, an exemplary method may include reading, by an exemplary controller of the SOC, an exemplary executable instruction segment (EIS) stored on an exemplary main memory of an exemplary SOC; broadcasting, by an exemplary controller, an exemplary EIS to each respective consensus module (CM) of a plurality of exemplary CMs, with a number of N, installed on an exemplary SOC, wherein each respective exemplary CM corresponds to a respective exemplary PE of a plurality of exemplary PEs;

[0008] In an exemplary embodiment, an exemplary method may further include reaching an exemplary consensus, among at least 2f+l CMs of a plurality of exemplary CMs, on sending an exemplary EIS by each respective CM of a plurality of exemplary CMs to respective PE of a plurality of exemplary PEs, by executing an exemplary practical Byzantine fault tolerance (PBFT) consensus algorithm; sending, by each respective CM of a plurality of exemplary CMs, an exemplary EIS to a respective PE of a plurality of exemplary PEs;

[0009] In an exemplary embodiment, an exemplary method may further include generating, by each respective PE of a plurality of exemplary PEs, an exemplary respective execution result by executing an exemplary EIS; sending, by each respective PE of a plurality of exemplary PEs, an exemplary respective execution result to a respective CM of a plurality of exemplary CMs; storing, by each respective CM of a plurality of exemplary CMs, an exemplary respective execution result on an exemplary respective blockchain corresponding to each respective CM of a plurality of exemplary CMs, wherein an exemplary respective blockchain configured to store a constant number of an exemplary respective execution result, wherein a constant number of an exemplary respective execution result is m;

[0010] In an exemplary embodiment, an exemplary method may further include generating, by each respective CM of a plurality of exemplary CMs , an exemplary respective Merkle tree rootRef-1403-02-0307001(MTR) relating to an exemplary respective blockchain corresponding to each respective CM of a plurality of exemplary CMs, in response to storing exemplary m respective execution results on the respective blockchain; broadcasting, by each respective CM of a plurality of exemplary CMs, an exemplary respective MTR to each respective CM corresponding to other (N-l) PEs of plurality of exemplary PEs; generating, by each respective CM of a plurality of exemplary CMs, an exemplary respective comparison result, wherein generating an exemplary respective comparison result may include checking equality between an exemplary respective MTR and an exemplary each respective MTR received from exemplary other (N-l) CMs of a plurality of exemplary CMs; and identifying each faulty PE from a plurality of exemplary PEs, in response to existence of an inequality between an exemplary respective MTR and an exemplary each respective MTR received from exemplary other (N-l) of a plurality of exemplary CMs;

[0011] In an exemplary embodiment, an exemplary method may further generating an exemplary respective comparison result based on an exemplary identified faulty PE of plurality of exemplary PEs, wherein an exemplary comparison result comprises a plurality of exemplary identification numbers relate to the one or more FPEs among a plurality of exemplary PEs; sending, by each respective CM of a plurality of exemplary CMs, an exemplary respective comparison result to an exemplary arbiter module; identifying, by an exemplary arbiter module, one or more exemplary FPEs based on exemplary N comparison results received from all (N) exemplary CMs; sending, by an exemplary arbiter module, an exemplary identification result to an exemplary controller;

[0012] In an exemplary embodiment, an exemplary method may further include switching off, by an exemplary controller, one or more exemplary FPEs among a plurality of exemplary PEs based on an exemplary received identification result, by sending an exemplary off signal to an exemplary respective switch relating to each respective FPEs of one or more exemplary FPEs; and purging, by each respective exemplary CM corresponding to each respective non-faultyRef-1403-02-0307001PEs among a plurality of exemplary PEs, exemplary m respective execution results stored on an exemplary respective blockchain corresponding to each respective exemplary non- faulty PEs.

[0013] This summary may introduce a number of concepts in a simplified format; the concepts are further disclosed within the “Detailed Description” section. This summary is not intended to configure essential / key features of the claimed subject matter, nor is intended to limit the scope of the claimed subject matter.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The novel features which are believed to be characteristic of the present disclosure, as to its structure, organization, use and method of operation, together with further objectives and advantages thereof, will be better understood from the following drawings in which a presently preferred embodiment of the present disclosure will now be illustrated by way of example. It is expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the present disclosure. Embodiments of the present disclosure will now be described by way of example in association with the accompanying drawings in which:

[0015] FIG. 1 illustrates a diagram of an exemplary fault-tolerant system-on-chip (FTSOC), consistent with one or more exemplary embodiments of the present disclosure.

[0016] FIGs. 2A-D illustrate diagrams of an exemplary implementation relating to tolerating exemplary faulty processing elements, consistent with one or more exemplary embodiments of the present disclosure.

[0017] FIG. 3 illustrates a diagram of an exemplary implementation of an exemplary practical Byzantine fault tolerating consensus algorithm, consistent with one or more exemplary embodiments of the present disclosure.Ref-1403-02-0307001

[0018] FIG. 4 illustrates a diagram of internal structure of a block of an exemplary blockchain, consistent with one or more exemplary embodiments of the present disclosure.

[0019] FIG. 5 illustrates a diagram of an internal structure of an exemplary blockchain, consistent with one or more exemplary embodiments of the present disclosure.

[0020] FIGs. 6A-D illustrate diagrams of an exemplary implementation of Byzantine fault detection algorithm, consistent with one or more exemplary embodiments of the present disclosure.

[0021] FIG. 7 illustrates a diagram of an exemplary correspondence between an exemplary blockchain and an exemplary respective ordered hash, consistent with one or more exemplary embodiments of the present disclosure.

[0022] FIG. 8 illustrates a diagram of an exemplary calculation of Merkle tree root based on an exemplary ordered hash set, consistent with one or more exemplary embodiments of the present disclosure.

[0023] FIG. 9 illustrates a flow chart of an exemplary method for detecting one or more exemplary faulty processing elements, consistent with one or more exemplary embodiments of the present disclosure.DETAILED DESCRIPTION

[0024] In the following detailed description, numerous specific details are set forth by way of examples to provide a thorough understanding of the relevant teachings related to the exemplary embodiments. However, it should be apparent that the present teachings may be practiced without such details. In other instances, well known methods, procedures, components, and / or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

[0025] The following detailed description is presented to enable a person skilled in the art to make and use the methods and devices disclosed in one or more exemplary embodiments of theRef-1403-02-0307001 present disclosure. For purposes of explanation, specific nomenclature is set forth to provide a thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that these specific details are not required to practice the disclosed exemplary embodiments. Descriptions of specific exemplary embodiments are provided only as representative examples. Various modifications to the exemplary implementations will be plain to one skilled in the art, and the general principles defined herein may be applied to other implementations and applications without departing from the scope of the present disclosure. The present disclosure is not intended to be limited to the implementations shown, but is to be accorded the widest possible scope consistent with the principles and features disclosed herein.

[0026] Disclosed herein is an exemplary fault-tolerant system-on-chip (FTSOC) with an associated method for tolerating Byzantine faults. In an exemplary embodiment, an exemplary Byzantine fault may refer to an exemplary fault that may not crash entire an exemplary SOC, but may produce some exemplary wrong information such as wrong data, wrong control signals, and etc. In an exemplary embodiment, an exemplary Byzantine fault may refer to an exemplary fault that may not be shown in normal operation of an exemplary SOC, but may be shown in some exemplary special circumstances such as high speed, high pressure, and etc. In an exemplary embodiment, an exemplary Byzantine fault may not be detectable and may consume limited energy provided to an exemplary SOC. In an exemplary embodiment, an exemplary Byzantine fault may not be detectable which may alter the level of confidence that a user relayed upon an exemplary SOC.

[0027] An exemplary FTSOC, may not only detect but also isolate exemplary faulty processing units, with number of f, among all exemplary processing units, with number of N > 3f, installed on an exemplary FTSOC. In an exemplary embodiment, an exemplary faulty processing units installed on an exemplary FTSOC, may experience an exemplary Byzantine fault. In an exemplary embodiment, an exemplary FTSOC in order to increase the robustness againstRef-1403-02-0307001 exemplary crashing faults, may tolerate exemplary Byzantine faults in an exemplary decentralized manner. In an exemplary embodiment, an exemplary FTSOC may increase an exemplary level of reliability, and may reduce power consuming rate by isolating and shutting down exemplary faulty processing units installed on an exemplary FTSOC.

[0028] Referring to the figures, FIG. 1 illustrates a diagram of an exemplary fault-tolerant system-on-chip 100 (FTSOC 100), consistent with one or more exemplary embodiments of the present disclosure. In an exemplary embodiment, FTSOC 100 may include network-on-chip 102 (NOC 102), system-on-chip (SOC) controller 104 (SOCC 104), main memory 106, input / output (VO) devices 108, arbiter module 110, plurality of processing elements 112 (PEs 112) with number of N and same type of processing operations, plurality of consensus modules 114 (CMs 114) with number of N, plurality of blockchains 116 (BCs 116) with number of N, and plurality of switches 118 (SWs 118) with number of N. In an exemplary embodiment, FTSOC 100 may tolerate at most f faulty PEs of plurality of PEs 112 where N > 3f.

[0029] In an exemplary embodiment, communication between components of FTSOC 100 may be performed through NOC 102. In an exemplary embodiment, plurality of PEs 112 may include first processing element 112a (PE 112a), second processing element 112b (PE 112b), third processing element 112c (PE 112c), and fourth processing element 112d (PE 112d). In an exemplary embodiment, plurality of PEs 112 may include more PEs in addition to first PE 112a, second PE 112b, third PE 112c, and fourth PE 112d which are not shown in FIG. 1. In an exemplary embodiment, plurality of CMs 114 may include first consensus module 114a (CM 114a), second consensus module 114b (CM 114b), third consensus module 114c (CM 114c), and fourth consensus module 114d (CM 114d). In an exemplary embodiment, plurality of CMs 114 may include more CMs in addition to first CM 114a, second CM 114b, third CM 114c, and fourth CM 114d which are not shown in FIG. 1.Ref-1403-02-0307001

[0030] In further reference to FIG. 1, in an exemplary embodiment, plurality of BCs 116 may include first blockchain 116a (BC 116a), second blockchain 116b (BC 116b), third blockchain 116c (BC 116c), and fourth blockchain 116d (BC 116d). In an exemplary embodiment, plurality of BCs may include more BCs in addition to first BC 116a, second BC 116b, third BC 116c, and fourth BC 116d which are not shown in FIG. 1. In an exemplary embodiment, plurality of SWs 118 may include first switch 118a (SW 118a), second switch 118b (SW 118b), third switch 118c (SW 118c), and fourth switch 118d (SW 118d). In an exemplary embodiment, plurality of SWs 118 may include more SWs in addition to first SW 118a, second SW 118b, third SW 118c, and fourth SW 118d which are not shown in FIG. 1.

[0031] In further detail with respect to FIG. 1, in an exemplary embodiment, each PE of plurality of PEs 112 may associated only with an exemplary respective CM of plurality of CMs 114. For example, first PE 112a may be associated only with first CM 114a. In an exemplary embodiment, association between each PE of plurality of PEs 112 and a respective CM of plurality of CMs 114 may refer to the fact that each PE of plurality of PEs 112 may send or receive data to and be powered on or off by, through NOC 102, a respective CM of plurality of CMs 114. In an exemplary embodiment, each BC of plurality of BCs 116 may associated only with a respective CM of plurality of CMs 114. For example, first BC 118a may be associated only with first CM 114a. In an exemplary embodiment, association between each BC of plurality of BCs 118 and a respective CM of plurality of CMs 114 may refer to the fact that each BC of plurality of BCs 112 may send or receive data to and be powered on or off by, through NOC 102, a respective CM of plurality of CMs 114. In an exemplary embodiment, each SW of plurality of SWs 118 may associate to a respective CM of plurality of CMs 114. For example first SW 118a may associate to first CM 114a. In an exemplary embodiment, association between each SW of plurality of SWs 118 and a respective CM of plurality of CMs 114 may refer to the fact that each SW may connect or disconnect power line of an exemplary respective CM of plurality of CMs 114.Ref-1403-02-0307001

[0032] In further detail with respect to FIG. 1, in an exemplary embodiment, an exemplary respective unique identification number may be assigned to each PE of plurality of PEs 112 and may be available in SOCC 104.

[0033] FIGs. 2A-D illustrate diagrams of implementation 200 relating to tolerating exemplary faulty processing elements, consistent with one or more exemplary embodiments of the present disclosure. In further detail with respect to FIGs. 1, and 2A, in an exemplary embodiment, SOCC 104 may fetch, from main memory 106, executable instruction segment 202 (EIS 202) among plurality of executable instructions stored on main memory 106. In an exemplary embodiment, a size of EIS 202 may be defined in SOCC 104 according to an exemplary processing properties of plurality of CMs 114. In an exemplary embodiment, SOCC 104 may broadcast EIS 202 to each CM of plurality of CMs 114, simultaneously. For example, SOCC 104 may broadcast EIS 202 to first CM 114a, second CM 114 b, third CM 114c, and fourth CM 114d, simultaneously. In further detail with reference to FIGs. 1, and 2A-B, in an exemplary embodiment, plurality of CMs 114 may execute an exemplary practical Byzantine fault tolerance (PBFT) algorithm when each CM of plurality of CMs 114 receives EIS 202 from SOCC 104. In an exemplary embodiment, plurality of CMs 114 may execute an exemplary PBFT algorithm in order to reach an exemplary consensus on sending EIS 202 to a respective PE of plurality of PEs 112. An example of executing an exemplary PBFT algorithm with plurality of CMs 114 is explained in more detail in connection with FIG. 3.

[0034] In further detail with reference to FIGs. 1, and 2A-C, in an exemplary embodiment, after reaching an exemplary consensus among plurality of CMs 114, each CM of plurality of CMs 114 may send EIS 202 to respective PE of plurality of PEs 112. For example, first CM 114a may send EIS 202 to PE 112a, second CM 114b to PE 112b, third CM 114c to third PE 112c and fourth CM 114d to fourth PE 112d. In an exemplary embodiment, each PE of plurality of PEs 112 may execute EIS 202 in response to receiving EIS 202 from a respective CM of plurality of CMs 114Ref-1403-02-0307001 and then may send back plurality of execution results 204 (ERs 204) to a respective CM of plurality of CMs 114 where in each ER of plurality of ERs 204 comprises result of executing EIS 202 by a respective PE of plurality of PEs 112. In an exemplary embodiment, plurality of ERs 204 may include first ER 204a produced by first PE 112a, second ER 204b produced by second PE 112b, third ER 204c produced by third PE 112c, and fourth ER 204d produced by fourth PE 112d.

[0035] In an exemplary embodiment, first PE 112a may receive EIS 202 from first CM 114a then execute EIS 202 and produce first ER 204a then send back first ER 204a to first CM 114a, second PE 112b may receive EIS 202 from second CM 114b then execute EIS 202 and produce second ER 204b then send back second ER 204b to second CM 114b, third PE 112c may receive EIS 202 from third CM 114c then execute EIS 202 and produce third ER 204c then send back third ER 204c to third CM 114c, and fourth PE 112d may receive EIS 202 from fourth CM 114d then execute EIS 202 and produce fourth ER 204d then send back fourth ER 204d to fourth CM 114d.

[0036] In further detail with respect to FIGs. 1, and 2D, in an exemplary embodiment, each CM of plurality of CMs 114, in response to receiving a respective ER of plurality of ERs 204 from a respective PE of plurality of PEs 112, may store a respective ER of plurality of ERs 204 on a respective BC of plurality of BCs 118 then send a respective ER of plurality of ERs 204 to SOCC 104. For example, first CM 114a, in response to receiving first ER 204a from first PE 112a, may store first ER 204a on first BC 118a then send first ER 204a to SOCC 104, and second CM 114b, third CM 114c and fourth CM 114d may act similar to first CM 114a.

[0037] In further detail with respect to FIGs. 1, and 2D, in an exemplary embodiment, SOCC 104 may check equality between plurality of ERs 204 received from plurality of CMs 114 and generate consensus execution result 206 (CER 206) when f+1 ERs of plurality of ERs 204 are identical. In an exemplary embodiment, CER 206 is equal to one of exemplary identical f+1 ERs of plurality of ERs 204.Ref-1403-02-0307001

[0038] In an exemplary embodiment, non-faulty PEs of plurality of PEs 112 may produce exemplary identical ERs and BCs while faulty PEs of plurality of PEs 112 may produce exemplary ERs and BCs which are, respectively, different from exemplary ERs and BCs produced by non- faulty PEs.

[0039] FIG. 3 illustrates a diagram of implementation 300 of an exemplary PBFT consensus algorithm, consistent with one or more exemplary embodiments of the present disclosure. In further reference to FIGs. 1, 2A-D, 3, in an exemplary embodiment, implementation 300 may include first CM 114a, second CM 114b, third CM 114c, fourth CM 114d, first PE 112a, second PE 112b, third PE 112c, fourth PE llOd, first BC 118a, second BC 118b, third BC 118c, and fourth BC 118d among plurality of CMs 114, plurality of PEs 112, and plurality of BCs 118 respectively (all are shown in FIG. 1). In an exemplary embodiment, third CM 114c may include an exemplary Byzantine fault and first CM 114a may be a primary node 114a of an exemplary PBFT consensus algorithm. In an exemplary embodiment, an exemplary PBFT consensus algorithm may comprise 5 phases that may include request phase 302, pre-prepare phase 304, prepare phase 306, commit phase 308, and replay phase 310. In an exemplary embodiment, preprepare phase 304, prepare phase 306, and commit phase 308, are main phases of an exemplary PBFT consensus algorithm.

[0040] With continued reference to FIG. 2A-D, and 3, in an exemplary embodiment, at request phase 302, SOCC 104 may send EIS 202 (shown in FIG 2A), as an exemplary request, to each of CMs 114a-d. In an exemplary embodiment, at pre -prepare phase 304, primary node 114a (first CM 114a) may generate an exemplary message, that may be called an exemplary pre-prepare message, with following exemplary elements« PRE-PREPARE, n, v, d >op, m > (1) where PRE-PREPARE may represent type of message (1), v an exemplary window number, n an exemplary sequence number, d an exemplary digest, cpan exemplary private key associated toRef-1403-02-0307001 primary node 114a (first CM 114a), and m an exemplary received request from SOCC 104. In an exemplary embodiment, first CM 114a may generate 3 exemplary encrypted messages by encrypting message (1) 3 times with an exemplary respective private key and may send 3 exemplary encrypted messages to each of CMs 114b-d.

[0041] In an exemplary embodiment, at prepare phase 306, each of CMs 114b-d may receive an exemplary respective encrypted message from first CM 114a then may decrypt an exemplary respective encrypted message with an exemplary public key associated to first CM 114a which may be available in each of CMs 114b-d. In an exemplary embodiment, each of CMs 114b-d may extract a number and window number from an exemplary respective decrypted message (both are shown in message (1)) and may validate based on principles of an exemplary PBFT consensus algorithm. For example, if second CM 114b may receive an exemplary encrypted message from first CM 114a, may decrypt an exemplary encrypted message with an exemplary public key of first CM 114a and may extract a sequence number from an exemplary decrypted message with smaller value compare to a sequence number of an exemplary decrypted message that has been processed by second CM 114b before , based on this, second CM 114b may reject an exemplary encrypted message received from CM 114a, may broadcast an exemplary error message to other CMs (CMs 114a, and 114c-d), and may exit the consensus algorithm. If third CM 114c and fourth CM 114d also may have broadcasted an exemplary similar error to other CMs (CMs 114a-b, and 114d and CMs 114a-c respectively), it may indicate that first CM 114a may be faulty / Byzantine, and first CM 114a may be replaced in an exemplary next round of consensus algorithm, In an exemplary embodiment, if a sequence number of an exemplary decrypted message is larger than a sequence number of an exemplary decrypted message that has been processed by second CM 114b so far, second CM 114b may accept an exemplary encrypted message sent by CM 114a.Ref-1403-02-0307001

[0042] In an exemplary embodiment, at final stage of pre-prepare phase 304, each of CMs 114b-d may generate an exemplary message, that may be called an exemplary prepare message, with an exemplary elements as follow:< PREPARE, n, v, d, i >Oi (2) where PREPARE may represent type of message (2), v an exemplary window number, n an exemplary sequence number, d an exemplary digest, i identity of each of CMs 114b-d, and c, an exemplary private key associated to each of CMs 114b-d. For example, second CM 114b may generate an exemplary respective prepare message as follow< PREPARE, n, v, d, 2 >o2(3)

[0043] In an exemplary embodiment, each of CMs 114b-d may generate an exemplary encrypted prepare message by encrypting respective message (2) with an exemplary respective private key and then may send an exemplary respective encrypted prepared message to other CMs of CMs 114a-d. For example, second CM 114b may create an exemplary respective encrypted prepare message by encrypting message (3) with an exemplary respective private key and may send an exemplary respective encrypted prepared message to each of first CM 114a, third CM 114c and fourth CM 114d.

[0044] With continued reference to FIG. 3, in an exemplary embodiment, at prepare phase 306, each of CMs 114a-d may receive an exemplary plurality of encrypted prepare messages from other CMs of CMs 114a-d. For example, first CM 114a may receive an exemplary plurality of encrypted prepare messages from second CM 114b, third CM 114c, and fourth CM 114d. In an exemplary embodiment, each of CMs 114a-d may decrypt each prepare massage of an exemplary plurality of prepare massages received from other CMs of CMs 114a-d by using each respective public key of other CMs of CMs 114a-d, may extract exemplary respective sequence number, window number and digest from each exemplary decrypted prepare massage, and may validate each prepare message receive from other CMs of CMs 114a-d based on principles of an exemplaryRef-1403-02-0307001PBFT consensus algorithm. For example, in implementation 300, CM 114a may decrypt 3 prepare messages received from each of CMs 114b-d, may extract 3 respective sequence numbers, 3 respective window number and 3 respective digest, and may validate 3 respective prepare message received from each of CMs 114b-d as true if each respective digest of each of CMs 114b-d is equal to a digest of CM 114a and also each sequential and window numbers are valid in a sense that already explained as an example at pre-prepare phase 306 explanation paragraph.

[0045] In an exemplary embodiment, at prepare phase 306, each of CMs 114a-d may generate an exemplary message, which may be called an exemplary commit message, if each of CMs 114a-d validates at least 2 numbers of prepare message from 3 prepare messages received from other CMs. For example, in implementation 300, first CM 114a may generate an exemplary respective commit message, because only CM 114c is faulty and CM 114a may validate 3 prepare messages from exemplary plurality of prepare messages received from second CM 114b, third CM 114c and fourth 114d.

[0046] In an exemplary embodiment, an exemplary commit message may comprises following elements<COMMIT, n, v, i>Oi (4) where COMMIT may represent type of message (4), v an exemplary window number, n an exemplary sequence number, i identity of each of CMs 114b-d, and Gi an exemplary private key associated to each of CMs 114b-d. For example, CM 114a. For example, second CM 114b may generate an exemplary respective commit message as follow< COMMIT, n, v, 2>o2(5)

[0047] In an exemplary embodiment, each of CMs 114b-d may generate an exemplary encrypted commit message by encrypting respective message (4) with an exemplary respective private key and then may send an exemplary respective encrypted commit message to other CMs of CMs 114a-d. For example, second CM 114b may create an exemplary respective encryptedRef-1403-02-0307001 commit message by encrypting message (5) with an exemplary respective private key and may send an exemplary respective encrypted commit message to each of first CM 114a, third CM 114c and fourth CM 114d.

[0048] In further reference to FIGs. 1, 2C and 3, in an exemplary embodiment, at commit phase 308, each of CMs 114a-d may receive 3 encrypted commit messages from other CMs of CMsll4a-d. For example, first CM 114a may receive 3 encrypted prepare messages from second CM 114b, third CM 114c, and fourth CM 114d. In an exemplary embodiment, each of CMs 114a- b may send EIS 202 (shown in FIG. 2C) to exemplary respective PE of plurality of PEs 112 (shown in FIG. 1) if each of CMs 114a-b receives at least 2 commit messages from other CMs among CMs 114a-d. For example, in implementation 300, first CM 114a may receive 3 encrypted commit messages from second CM 114b, third CM 114c, and fourth CM 114d.

[0049] With continued reference to FIGs. 1, 2C-D and 3, in an exemplary embodiment, at reply phase 310, each of PEs 112a-d (shown in FIG. 2C) may execute EIS 202, may send each respective ER of ERs 204a-d to each respective CM of CMs 114a-d. In an exemplary embodiment, each of CMs 114a-d may send / reply each ER of ER 204a-d to SOCC 104 (shown in FIG. 2D).

[0050] In an exemplary embodiment, implementation 300 may be true for a plurality of CMs of plurality of CMS 114 shown in FIG. 1, as it already explained for 4 CMs of plurality of CMs 114.

[0051] FIG. 4 illustrates a diagram of internal structure 400 of a block of a BC of plurality of BCs 118 (shown in FIG. 1), consistent with one or more exemplary embodiments of the present disclosure. In an exemplary embodiment, internal structure 400 may include two main sections, block header 402 and block body 404. In an exemplary embodiment, block header may include previous hash 406, hash 408, and time stamp 410 where previous hash 406 represents a hash of an exemplary previous block that block 400 connected with it, hash 408 represents a hash of block 400 itself, and time stamp 410 represents a time of updating block 400.Ref-1403-02-0307001

[0052] In further detail with respect to FIGs. 1, 2D, and 4, in an exemplary embodiment, block body 404 may include data that represents an exemplary execution result ER (shown in FIG. 2D) stored by a CM of plurality of CMs 114 (shown in FIG. 1) .

[0053] FIG. 5 illustrates a diagram of internal structure 500 of a BC of plurality of BCs 118 (shown in FIG. 1), consistent with one or more exemplary embodiments of the present disclosure. In further detail with respect to FIGs. 4, and 5, in an exemplary embodiment, internal structure 500 may include plurality of blocks 400. In an exemplary embodiment, plurality of blocks 400 may include first block 400a, second block 400b, third block 400c, and fourth block 400d. In an exemplary embodiment, plurality of blocks 400 may include more blocks in addition to first block 400a, second block 400b, third block 400c, and fourth block 400d.

[0054] In an exemplary embodiment, each block of plurality blocks 400 may hold a hash of other blocks of plurality of blocks 400 as exemplary respective previous hash. For example, in internal structure 500, fourth block 400d may hold hash of third block 400c, third block 400c may hold hash of second block 400b, second block 400b may hold hash of first block 400a, and first block 400a may hold number 0 as respective previous hash, respectively.

[0055] FIGs. 6A-D illustrate diagrams of implementation 600 of Byzantine fault detection algorithm, consistent with one or more exemplary embodiments of the present disclosure. In further detail with respect to FIGs. 1 and 6A, in an exemplary embodiment, each CM of plurality of CMs 114 (shown in FIG. 1) may fetch respective ordered hash set (OHS) of plurality of ordered hash sets 602 (OHSs 602) when each BC of plurality of BCs 116 is full. In an exemplary embodiment, plurality of OHSs 602 may include first OHS 602a, second OHS 602b, third OHS 602c, and fourth OHS 602d. In an exemplary embodiment, plurality of OHSs 602 may include more OHSs in addition to first OHS 602a, second OHS 602b, third OHS 602c, and fourth OHS 602d which are not shown in FIG. 6A.Ref-1403-02-0307001

[0056] In an exemplary embodiment, each OHS of plurality of OHSs 602 may include each respective hash of an exemplary block inside each respective BC of plurality of BCs 116 where a first hash of exemplary respective OHS is a hash of an exemplary first block in each respective BC of plurality of BCs 116, and a last hash of exemplary respective OHS is a hash of an exemplary last block in each respective BC of plurality of BCs 116. In an exemplary embodiment, each respective hash in each OHS of plurality of OHSs 602 may be placed near each other in an exemplary order as same as an exemplary order they are connected. An example of OHS is explained in more detail in connection with FIG. 7

[0057] With further reference to FIGs. 1 and 6A-B, in an exemplary embodiment, each CM of plurality of CMs 114 may calculate exemplary respective Merkle tree root (MTR) based on each respective OHS of plurality of OHSs 602. For example, first CM 114a and second CM 114b may calculate each respective MTR based on first OHS 602a and second OHS 602b (shown in FIG. 6A), respectively. In an exemplary embodiment, non-faulty PEs of plurality of PEs 112 may result in identical exemplary OHSs which may result in that exemplary CMs associate to non- faulty PEs of plurality of PEs 112 calculate identical exemplary MTRs. In contrast, in an exemplary embodiment, faulty PEs of plurality of PEs 112 may result in exemplary OHSs which are different from exemplary OHSs produced by non-faulty PEs which may result in exemplary CMs associated to faulty PEs of plurality of PEs calculate exemplary MTRs different from exemplary MTRs calculated by exemplary CMs associate to non-faulty PEs of plurality of PEs 112. An example of calculating an exemplary MTR based on an exemplary OHS is explained in more detail in connection with FIG. 8.

[0058] In further detail with respect to FIGs. 1 and 6B, in an exemplary embodiment, each CM of plurality of CMs 114 may send each respective calculated MTR to other CMs of plurality of CMs 114. In further detail with respect to FIGs. 1 and 6C, in an exemplary embodiment, plurality of CMs 118 (shown in FIG. 1) may generate plurality of comparison results 604 (CRsRef-1403-02-0307001604) based on a respective plurality of exemplary MTRs received from each other. In an exemplary embodiment, each CR of plurality of CRs 604 may be generated by each respective CM of plurality of CMs 114. In an exemplary embodiment, plurality of CRs 604 may include first CR 604a, second CR 604b, third CD 604c, and fourth CR 604d wherein each of them are generated by first CM 114a, second CM 114b, third CM 114c, and fourth CM 114d respectively. In an exemplary embodiment, plurality of CRs 604 may include more CRs in addition to first CR 604a, second CR 604b, third CD 604c, and fourth CR 604d.

[0059] In an exemplary embodiment, each CR of plurality of CRs 604 may include identification numbers relating to a plurality of faulty PEs from plurality of PEs 112.

[0060] In an exemplary embodiment, each CM of plurality of CMs 114 may identify one or more CMs among other CMs of plurality of CMs 114 as exemplary one or more faulty CMs if exemplary respective MTRs received from one or more CMs among other CMs of plurality of CMs 114 are not equal to respective MTR of each CM of plurality of CMs 114. In an exemplary embodiment, each CM of plurality of CMs 114 may add exemplary identification numbers of one or more PEs of plurality of PEs associated to one or more faulty CMs of plurality of CMs 114 to each respective CR of plurality of CR 604. For example, first CM 114a may compare its MTR with each MTR received from second CM 114b, third CM 114c, and fourth CM 114d where a respective MTR relating to second CM 114b is not equal to respective MTR relating to first CM 114a but a respective MTR relating to third CM 114c and a respective MTR relating to CM 114d is equal. In an exemplary embodiment, first CM 114a may detect second PE 112b faulty and may add a respective identification number relating to second PE 112b to first CR 604a.

[0061] With continued reference to FIG. 6C, each CM from plurality of CMs 114 may send exemplary respective CR to an exemplary arbiter module 110. In an exemplary embodiment, an exemplary arbiter module 110 may receive each respective CR relating to each CM from plurality of CMs 114, may count number of times which one or more exemplary identification numbersRef-1403-02-0307001 relating to one or more PEs of plurality of PEs 112 is appeared within plurality of CRs 602 received from plurality of CMs 114, then may define one or more failure numbers, corresponding to one or more PEs of plurality of PEs 112, equal to one or more respective counted numbers for an one or more PE of plurality of PEs 112, then may identify one or more PEs of plurality of PEs 112 as one or more exemplary faulty PEs if one or more failure numbers, associating to one or more PEs of plurality of PEs, is equal or greater than f+1 where f identifies an exemplary maximum number of faulty PE from plurality of PEs 112 exists on FTSOC 100, and may send one or more identification numbers of identified one or more faulty PEs of plurality of PEs 112 to SOCC 104.

[0062] In further detail with respect to FIGs. 6C-D, in an exemplary embodiment, SOCC 104 may send one or more exemplary off signals 608 to one or more SWs from plurality of SWs 118 associating to one or more faulty PEs of plurality of PEs 112 identified by an exemplary arbiter module 110, where one or more identification numbers associate to one or more faulty of PEs of plurality PEs 112 is sent to SOCC 104 by an exemplary arbiter 110. For example, SOCC 104 may send two off signals 608 to first SW 118a and second 118b when an exemplary arbiter 110 sends exemplary respective identification numbers of respective PE associated to first SW 118a and second SW 118b respectively. In an exemplary embodiment, each respective CM of plurality of CMs 114 may

[0063] In an exemplary embodiment, SOCC 104 may send one or more purge-blockchain signals 610 to one or more CMs associated to one or more non-faulty PEs of plurality of PEs 114 which may result in one or more CMs associated to one more non-faulty PEs of plurality of PEs 114 purge all ERs stored on respective BC of plurality of BCs 118

[0064] With further reference to FIG.l and 6D, in an exemplary embodiment, each SW of plurality of SWs 118 may send an exemplary off signal to respective CM of plurality of CMs 114 and respective CM of plurality of CMs 114 may power off a processor of respective PE of pluralityRef-1403-02-0307001 of PEs 114. For example, first SW 118a may send an exemplary off signal to first CM 114a and first CM 114a may power off first PE 112a.

[0065] FIG. 7 illustrates a diagram of correspondence 700 between blockchain 400 and respective OHS 702, consistent with one or more exemplary embodiments of the present disclosure. In an exemplary embodiment, OHS 702 may include first hash 702a, second hash 702b, third hash 702c, and fourth hash 702d. In an exemplary embodiment, OHS 702 may include more hashes in addition to first hash 702a, second hash 702b, third hash 702c, and fourth hash 702d which are not shown in FIG. 7. In an exemplary embodiment, blockchain 400 may include first block 400a, second block 400b, third block 400d, and fourth block 400d. In an exemplary embodiment, fourth block 400d may be on top of third block 400c, third block 400c may be on top of second block 400b, and second block 400b may be on top of first block 400a. In an exemplary embodiment, each top block from blockchain 400 may have access to an exemplary hash of respective bottom block from blockchain 400.

[0066] In further detail with respect to FIG. 7, in an exemplary embodiment, each hash from OHS 702 may associate to each block from blockchain 400. In an exemplary embodiment, association between each hash from OHS 702 and each block from blockchain 400 may refer to the fact that an exemplary order of hashes in OHS 702 is as same as an exemplary order of blocks in blockchain 400 and each hash from OHS 702 is equal to associated block from blockchain 400. For example, first hash 702a may be equal to a hash of first block 400a, second hash 702b may be equal to a hash of second block 400b, third hash 703 may be equal to a hash of third block 400c, and fourth hash 702d may be equal to a hash of fourth block 400d.

[0067] FIG. 8 illustrates a diagram of calculation 800 of Merkle tree root based on an OHS 802, consistent with one or more exemplary embodiments of the present disclosure. In an exemplary embodiment, OHS 802 may include first hash 802a, second hash 802b, third hash 802c, and fourth hash 802d. In an exemplary embodiment, OHS 802 may include more hashes inRef-1403-02-0307001 addition to first hash 802a, second hash 802b, third hash 802c, and fourth hash 802d which are not shown in FIG. 8.

[0068] In an exemplary embodiment, calculation 800 of MRT may be performed level by level from left to right in each level from plurality of levels 804. In an exemplary embodiment, an exemplary addition result may be generated by adding exemplary hashes from level 804a together two by two from the left side, then a hash of respective top level 804b may be calculated by applying an exemplary hashing algorithm to an exemplary addition from an exemplary bottom level 804a. In an exemplary embodiment, hashing algorithm may be an exemplary SHA-256. For example first hash 802a from level 804a may be added to second hash 802b from level 804a, and applying an exemplary hashing algorithm to an exemplary respective addition result may generate hash value 806 from level 804b. Also third hash 802C from level 804a may be added to fourth hash 802d from level 804a, and applying an exemplary hashing algorithm to an exemplary respective addition result may generate hash value 808 from level 804b.

[0069] In an exemplary embodiment, hash value 806 from level 804b may be added to hash value 808 from level 804b, and applying an exemplary hashing algorithm to an exemplary respective addition result may generate hash value 810 from root level 804c. In an exemplary embodiment, an exemplary calculation of MTR may be stopped when there is only one hash value in an exemplary top level from plurality of top levels 804 and MTR may be equal to only one hash value in an exemplary top level from plurality of top levels 804.

[0070] FIG. 9 illustrates a flow chart of method 900 for detecting one or more exemplary FPEs, consistent with one or more exemplary embodiments of the present disclosure. In further detail with respect to FIGs 6B-C and 9, in an exemplary embodiment, method 900 may include generating, by each respective CM of a plurality of CMs 114 shown in FIG. 1, a respective MTR relating to a respective blockchain corresponding to each respective CM(step 902) where step 902 is further explained with connection to FIG. 6B; broadcasting, by each respective CM of theRef-1403-02-0307001 plurality of CMs 114, an exemplary respective MTR to each respective CM corresponding to other PEs of plurality of PEs 112 shown in FIG. 1 (step 904) where step 904 is further explained in connection with FIG. 6B; generating, by each respective CM of the plurality of CMs 114, a respective comparison result (step 906) where step 906 is further explained in connection with FIG. 6C; sending, by each respective CM of the plurality of CMs 114, an exemplary respective comparison result to an arbiter module (step 908) where step 908 is further explained in connection with FIG. 6C.

[0071] In further detail with respect to FIGs 6C-D and 9, in an exemplary embodiment, method 900 may further include identifying, by an exemplary arbiter module, one or more exemplary FPEs based on a plurality of exemplary comparison results received from all CMs (step 910) where step 910 is further explained in connection with FIG. 6C; sending, by an exemplary arbiter module, an identification result to a controller of an exemplary FTSOC 100 shown in FIG. 1 (step 912) where step 912 is further explained in connection with FIG. 6C; switching off, by an exemplary controller, one or more FPEs among the plurality of PEs 112 based on an exemplary received identification result (step 914) where step 914 is further explained in connection with FIG. 6D; purging, by an exemplary each respective CM corresponding to each respective non- faulty PEs among the plurality of PEs 114, all respective execution results stored on a respective blockchain corresponding to each respective non-faulty PEs (step 916) where step 916 is further explained in connection with FIG. 6D.

[0072] While the foregoing has described what are considered to be the best mode and / or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings.Ref-1403-02-0307001

[0073] Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, including in the claims that follow, are approximate, not exact. They are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.

[0074] The scope of protection is limited solely by the claims that now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language that is used in the claims when interpreted in light of this specification and the prosecution history that follows and to encompass all structural and functional equivalents. Notwithstanding, none of the claims are intended to embrace subject matter that fails to satisfy the requirement of Sections 101, 102, or 103 of the Patent Act, nor should they be interpreted in such a way. Any unintended embracement of such subject matter is hereby disclaimed.

[0075] Except as stated immediately above, nothing that has been stated or illustrated is intended or should be interpreted to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, regardless of whether it is or is not recited in the claims.

[0076] It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. An element proceeded by “a” or “an” does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0077] Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, are approximate, not exact.Ref-1403-02-0307001They are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.

[0078] It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study, except where specific meanings have otherwise been set forth herein. Relational terms such as “first” and “second” and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions.

[0079] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it may be seen that various features are grouped together in various implementations. This is for purposes of streamlining the disclosure, and is not to be interpreted as reflecting an intention that the claimed implementations require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

[0080] While various implementations have been described, the description is intended to be exemplary, rather than limiting and it will be apparent to those of ordinary skill in the art that many more implementations and implementations are possible that are within the scope of the implementations. Although many possible combinations of features are shown in the accompanying figures and discussed in this detailed description, many other combinations of the disclosed features are possible. Any feature of any embodiment may be used in combination with or substituted for any other feature or element in any other embodiment unless specifically restricted. Therefore, it will be understood that any of the features shown and / or discussed in theRef-1403-02-0307001 present disclosure may be implemented together in any suitable combination. Accordingly, the implementations are not to be restricted except in light of the attached claims and their equivalents. Also, various modifications and changes may be made within the scope of the attached claims.

Claims

Ref-1403-02-0307001What is claimed is:

1. A method for tolerating one or more faulty processing elements (FPEs), with a number of f, among a plurality of processing elements (PEs), with a number of N > 3f, installed on a system-on-chip (SOC), the method comprising: reading, by a controller of the SOC, an executable instruction segment (EIS) stored on a main memory of the SOC; broadcasting, by the controller, the EIS to each respective consensus module (CM) of a plurality of CMs, with a number of N, installed on the SOC, wherein the each respective CM corresponds to a respective PE of the plurality of PEs; reaching a consensus, among at least 2f+l CMs of the plurality of CMs, on sending the EIS by the each respective CM to the respective PE, by executing a practical Byzantine fault tolerance (PBFT) consensus algorithm; sending, by the each respective CM of the plurality of CMs, the EIS to the respective PE; generating, by each respective PE of the plurality of PEs, a respective execution result by executing the EIS; sending, by the each respective PE of the plurality of PEs, the respective execution result to a respective CM of the plurality CMs; storing, by the each respective CM of the plurality of CMs, the respective execution result on a respective blockchain corresponding to the each respective CM, the respective blockchain configured to store a constant number of theRef-1403-02-0307001 respective execution result, wherein the constant number of the respective execution result is m; generating, by the each respective CM of the plurality of CMs , a respective Merkle tree root (MTR) relating to the respective blockchain corresponding to the each respective CM, in response to storing m respective execution results on the respective blockchain; broadcasting, by the each respective CM of the plurality of CMs, the respective MTR to each respective CM corresponding to other (N-l) PEs; generating, by the each respective CM of the plurality of CMs, a respective comparison result, wherein generating the respective comparison result comprises: checking equality between the respective MTR and each respective MTR received from the other (N-l) CMs; and identifies each faulty PE from the plurality of PEs, in response to existence of an inequality between the respective MTR and the each respective MTR received from the other (N-l) CMs; generating the respective comparison result based on the identified faulty PE from plurality of PEs, wherein the comparison result comprises a plurality of identification numbers relates to the one or more FPEs among the plurality of PEs; sending, by the each respective CM of the plurality of CMs, the respective comparison result to an arbiter module;Ref-1403-02-0307001 identifying, by the arbiter module, the one or more FPEs among the plurality of PEs based on N comparison results received from all (N) CMs; sending, by the arbiter module, an identification result to the controller; switching off, by the controller, the one or more FPEs among the plurality of PEs based on the received identification result, by sending an off signal to a respective switch relating to each respective FPEs of the one or more FPEs among the plurality of PEs; and purging, by each respective CM corresponding to each respective non-faulty PEs among the plurality of PEs, m respective execution results stored on a respective blockchain corresponding to each respective non-faulty PEs.

2. The method of claim 1, wherein identifying the one or more FPEs among the plurality of PEs comprises: extracting, from the received N comparison results, the plurality of identification numbers relates to the one or more FPEs among the plurality of PEs; assigning a respective failure number relating to the each respective PE based on a number of times which an identification number relating to a faulty PE is appeared within the plurality of identification numbers relate to the one or more FPEs among the plurality of PEs; identifying the one or more FPEs among the plurality of PEs in response to the each respective failure number relating to the each respective PE equal or greater than f+1; andRef-1403-02-0307001 generating the identification result, wherein the identification result comprises each respective identification number relating to each respective identified the one or more FPEs among the plurality of PEs.

3. The method of claim 1, wherein the switching off the one or more FPEs among the plurality of PEs further comprises: switching off each respective CM of the one or more FPEs among the plurality of PEs; and switching off each respective processor core of the one of more FPEs;

Citation Information

Patent Citations

  • System and method for ending view change protocol

    US20200145520A1