Home / Current Issue / Paper 1720196
IsoBFT: A Novel Byzantine Fault-Tolerant Consensus Algorithm for Ultra-Low-Latency Decentralized Networks in Critical Infrastructure and Industrial IoT
Subject area: Science,Engineering and Technology · Area of research: IoT
DOI: https://doi.org/10.64388/IREV10I1-1720196
Abstract
The networks that run operational technology (OT) substations, water treatment plants, oil and gas pipelines, and manufacturing lines are moving from a centralized control to a federated, multi-stakeholder architecture coordinated by permissioned distributed ledgers. Protection and control loops in the electrical grid and other critical infrastructure have protection-relay tripping times, IEC 61850 GOOSE message classes, and SCADA/PMU polling cycles that impose multi-millisecond to sub-second deadlines on protection and control operations, while Byzantine fault-tolerant (BFT) consensus protocols like PBFT, Tendermint, HotStuff, and HoneyBadgerBFT were designed for settlement workloads that can tolerate hundreds of milliseconds to seconds of latency. In this paper, we survey four representative BFT families, discuss their structural latency and scalability constraints for OT deployment, and introduce a hybrid consensus algorithm called IsoBFT (Isochronous Byzantine Fault Tolerance), which combines an optimistic single-round-trip fast path with a PBFT-style fallback mechanism based on a network-stability monitor, and elects a small rotating committee using a verifiable random function (VRF). A formal system model, safety/liveness/termination proof, and security analysis for eight attack classes are provided, with a proposition quantifying the degradation of the practical availability of the safety guarantee when the global Byzantine fraction is approaching one-third. Using realistic Modbus/DNP3/IEC 61850 OT traffic, the discrete-event simulation of the design IsoBFT managed to execute realistic workloads with median consensus latency ranging from 4.90ms at n = 10-50 to 9.17-11.26ms at n = 100 and n = 500, remaining competitive with or better than PBFT and Tendermint across this range. Committee-bounded communication overhead stayed essentially flat with respect to the number of validators from n = 10 to n = 50, but newly completed runs at n = 100 and n = 500 (n = 200 still outstanding) show overhead growing faster than the quadratic scaling of PBFT and Tendermint over that range, together with a heavy P95/P99 latency tail not present at smaller scale; this discrepancy with the theoretical scale-independence result is reported and discussed rather than resolved. IsoBFT could reduce the median latency by approximately 81% and 56% under up to 33% Byzantine faults compared to HotStuff and HoneyBadgerBFT, respectively, at n = 10-50, while maintaining the safety of the system; a Byzantine-resilience sweep at n = 100 shows a narrower advantage over PBFT/Tendermint than at smaller scale.
Keywords
Byzantine Fault Tolerance, Consensus Algorithms, Critical Infrastructure, Industrial Internet Of Things, Operational Technology.
References
[1] Baird, L. (2016). The Swirlds hashgraph consensus algorithm: Fair, fast, Byzantine fault tolerance (Report No. SWIRLDS-TR-2016-01). Swirlds.
[2] Buchman, E. (2016). Tendermint: Byzantine fault tolerance in the age of blockchains [Master's thesis, University of Guelph].
[3] Buterin, V., & Griffith, V. (2017). Casper the friendly finality gadget. arXiv. https://arxiv.org/abs/1710.09437
[4] Castro, M., & Liskov, B. (1999). Practical Byzantine fault tolerance. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (pp. 173–186). USENIX Association.
[5] Danezis, G., Kokoris-Kogias, L., Sonnino, A., & Spiegelman, A. (2022). Narwhal and Tusk: A DAG-based mempool and efficient BFT consensus. In Proceedings of the 17th European Conference on Computer Systems (pp. 34–50). ACM.
[6] David, B., Gazi, P., Kiayias, A., & Russell, A. (2018). Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake blockchain. In Advances in Cryptology—EUROCRYPT 2018 (pp. 66–98). Springer.
[7] Dragos, Inc. (2017). TRISIS malware: Analysis of safety system targeted malware [Threat intelligence report].
[8] Dwork, C., Lynch, N., & Stockmeyer, L. (1988). Consensus in the presence of partial synchrony. Journal of the ACM, 35(2), 288–323.
[9] Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2), 374–382.
[10] Gilad, Y., Hemo, R., Micali, S., Vlachos, G., & Zeldovich, N. (2017). Algorand: Scaling Byzantine agreements for cryptocurrencies. In Proceedings of the 26th ACM Symposium on Operating Systems Principles (pp. 51–68). ACM.
[11] Gueta, G. G., Abraham, I., Grossman, S., Malkhi, D., Pinkas, B., Reiter, M., Seredinschi, D., Tamir, O., & Tomescu, A. (2019). SBFT: A scalable and decentralized trust infrastructure for blockchains. In Proceedings of the 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (pp. 568–580). IEEE.
[12] Institute of Electrical and Electronics Engineers. (2011). IEEE standard for synchrophasor data transfer for power systems (IEEE Std C37.118.2-2011).
[13] Institute of Electrical and Electronics Engineers. (2012). IEEE standard for electric power systems communications—Distributed network protocol (DNP3) (IEEE Std 1815-2012).
[14] Institute of Electrical and Electronics Engineers. (n.d.). IEEE standard for relays and relay systems associated with electric power apparatus (IEEE Std C37.90).
[15] International Electrotechnical Commission. (n.d.-a). IEC 61850: Communication networks and systems for power utility automation (IEC Std 61850 series).
[16] International Electrotechnical Commission. (n.d.-b). IEC 62351: Power systems management and associated information exchange—Data and communications security (IEC 62351 series).
[17] International Electrotechnical Commission. (n.d.-c). Use of IEC 61850 for the communication between substations (IEC TR 61850-90-1).
[18] Kotla, R., Alvisi, L., Dahlin, M., Clement, A., & Wong, E. (2007). Zyzzyva: Speculative Byzantine fault tolerance. In Proceedings of the 21st ACM Symposium on Operating Systems Principles (pp. 45–58). ACM.
[19] Kwon, J. (2014). Tendermint: Consensus without mining [White paper].
[20] Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4(3), 382–401.
[21] Langner, R. (2011). Stuxnet: Dissecting a cyberwarfare weapon. IEEE Security & Privacy, 9(3), 49–51.
[22] Lee, R. M., Assante, M. J., & Conway, T. (2016). Analysis of the cyber attack on the Ukrainian power grid [Report]. SANS Industrial Control Systems / Electricity Information Sharing and Analysis Center.
[23] Micali, S., Rabin, M., & Vadhan, S. (1999). Verifiable random functions. In Proceedings of the 40th Annual Symposium on Foundations of Computer Science (pp. 120–130). IEEE.
[24] Miller, A., Xia, Y., Croman, K., Shi, E., & Song, D. (2016). The honey badger of BFT protocols. In Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (pp. 31–42). ACM.
[25] Modbus Organization. (2012). Modbus application protocol specification V1.1b3.
[26] Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf
[27] National Institute of Standards and Technology. (n.d.). Guide to industrial control systems (ICS) security (NIST Special Publication 800-82, Rev. 3).
[28] North American Electric Reliability Corporation. (n.d.). Critical infrastructure protection (CIP) reliability standards.
[29] Reyna, A., Martin, C., Chen, J., Soler, E., & Diaz, M. (2018). On blockchain and its integration with IoT: Challenges and opportunities. Future Generation Computer Systems, 88, 173–190.
[30] SimPy Developers. (n.d.). SimPy: Discrete-event simulation for Python [Documentation]. https://simpy.readthedocs.io
[31] Yin, M., Malkhi, D., Reiter, M. K., Gueta, G. G., & Abraham, I. (2019). HotStuff: BFT consensus in the lens of blockchain. In Proceedings of the ACM Symposium on Principles of Distributed Computing (pp. 347–356). ACM.
How to cite this paper
@article{1720196,
author = {Hassan Cessi Ibrahim, Damilare Timothy Ogunjobi, Philip Mensah},
title = {IsoBFT: A Novel Byzantine Fault-Tolerant Consensus Algorithm for Ultra-Low-Latency Decentralized Networks in Critical Infrastructure and Industrial IoT},
journal = {Iconic Research And Engineering Journals},
year = {2026},
volume = {10},
number = {1},
pages = {3591-3615},
issn = {2456-8880},
url = {https://www.irejournals.com/formatedpaper/1720196.pdf},
abstract = {The networks that run operational technology (OT) substations, water treatment plants, oil and gas pipelines, and manufacturing lines are moving from a centralized control to a federated, multi-stakeholder architecture coordinated by permissioned distributed ledgers. Protection and control loops in the electrical grid and other critical infrastructure have protection-relay tripping times, IEC 61850 GOOSE message classes, and SCADA/PMU polling cycles that impose multi-millisecond to sub-second deadlines on protection and control operations, while Byzantine fault-tolerant (BFT) consensus protocols like PBFT, Tendermint, HotStuff, and HoneyBadgerBFT were designed for settlement workloads that can tolerate hundreds of milliseconds to seconds of latency. In this paper, we survey four representative BFT families, discuss their structural latency and scalability constraints for OT deployment, and introduce a hybrid consensus algorithm called IsoBFT (Isochronous Byzantine Fault Tolerance), which combines an optimistic single-round-trip fast path with a PBFT-style fallback mechanism based on a network-stability monitor, and elects a small rotating committee using a verifiable random function (VRF). A formal system model, safety/liveness/termination proof, and security analysis for eight attack classes are provided, with a proposition quantifying the degradation of the practical availability of the safety guarantee when the global Byzantine fraction is approaching one-third. Using realistic Modbus/DNP3/IEC 61850 OT traffic, the discrete-event simulation of the design IsoBFT managed to execute realistic workloads with median consensus latency ranging from 4.90ms at n = 10-50 to 9.17-11.26ms at n = 100 and n = 500, remaining competitive with or better than PBFT and Tendermint across this range. Committee-bounded communication overhead stayed essentially flat with respect to the number of validators from n = 10 to n = 50, but newly completed runs at n = 100 and n = 500 (n = 200 still outstanding) show overhead growing faster than the quadratic scaling of PBFT and Tendermint over that range, together with a heavy P95/P99 latency tail not present at smaller scale; this discrepancy with the theoretical scale-independence result is reported and discussed rather than resolved. IsoBFT could reduce the median latency by approximately 81% and 56% under up to 33% Byzantine faults compared to HotStuff and HoneyBadgerBFT, respectively, at n = 10-50, while maintaining the safety of the system; a Byzantine-resilience sweep at n = 100 shows a narrower advantage over PBFT/Tendermint than at smaller scale.},
keywords = {Byzantine Fault Tolerance, Consensus Algorithms, Critical Infrastructure, Industrial Internet Of Things, Operational Technology.},
month = {July},
doi = {https://doi.org/10.64388/IREV10I1-1720196}
}