Una falla bizantina es cualquier falla que presenta diferentes síntomas para diferentes observadores. [2] Una falla bizantina es la pérdida de un servicio del sistema debido a una falla bizantina en sistemas que requieren consenso entre múltiples componentes. [3]
Si todos los generales atacan coordinadamente, la batalla está ganada (izquierda). Si dos generales declaran falsamente que tienen intención de atacar, pero en lugar de ello se retiran, la batalla está perdida (derecha).
La alegoría bizantina considera a varios generales que están atacando una fortaleza. Los generales deben decidir en grupo si atacan o se retiran; algunos pueden preferir atacar, mientras que otros prefieren retirarse. Lo importante es que todos los generales estén de acuerdo en una decisión común, ya que un ataque a medias por parte de unos pocos generales se convertiría en una derrota , y sería peor que un ataque coordinado o una retirada coordinada.
El problema se complica por la presencia de generales traidores que no sólo pueden votar por una estrategia subóptima, sino que pueden hacerlo de forma selectiva. Por ejemplo, si nueve generales están votando, cuatro de los cuales apoyan el ataque mientras que otros cuatro están a favor de la retirada, el noveno general puede enviar un voto de retirada a los generales que están a favor de la retirada, y un voto de ataque al resto. Aquellos que recibieron un voto de retirada del noveno general se retirarán, mientras que el resto atacará (lo que puede no ser bueno para los atacantes). El problema se complica aún más porque los generales están separados físicamente y tienen que enviar sus votos a través de mensajeros que pueden no entregar los votos o falsificar votos.
La tolerancia a las fallas bizantinas se puede lograr si el número de generales leales (sin fallas) es mayor que tres veces el número de generales desleales (con fallas). Puede haber un valor de voto predeterminado para los mensajes faltantes. Por ejemplo, a los mensajes faltantes se les puede dar un valor "nulo" . Además, si el acuerdo es que los votos nulos son mayoría, se puede utilizar una estrategia predeterminada preasignada (por ejemplo, retirada). [4]
La típica aplicación de esta alegoría a los sistemas informáticos es que los ordenadores son los generales y sus enlaces de sistemas de comunicación digital son los mensajeros. Aunque el problema se formula en la alegoría como un problema de toma de decisiones y seguridad, en electrónica no se puede resolver únicamente con firmas digitales criptográficas , porque fallos como voltajes incorrectos pueden propagarse a través del proceso de cifrado. Así, se podría enviar un mensaje defectuoso de modo que algunos destinatarios detecten el mensaje como defectuoso (mala firma), otros vean que tiene una buena firma y un tercer grupo también vea una buena firma pero con un contenido de mensaje diferente al del segundo grupo. [2]
Historia
El problema de obtener un consenso bizantino fue concebido y formalizado por Robert Shostak , quien lo denominó el problema de la consistencia interactiva . Este trabajo se realizó en 1978 en el contexto del proyecto SIFT [5] patrocinado por la NASA en el Laboratorio de Ciencias de la Computación de SRI International . SIFT (Software Implemented Fault Tolerance, tolerancia a fallos implementados por software) fue una creación de John Wensley y se basó en la idea de utilizar múltiples computadoras de propósito general que se comunicarían a través de mensajes por pares para alcanzar un consenso, incluso si algunas de las computadoras tuvieran fallas.
Al principio del proyecto no estaba claro cuántos ordenadores en total se necesitaban para garantizar que una conspiración de n ordenadores defectuosos no pudiera "frustrar" los esfuerzos de los que funcionaban correctamente para alcanzar un consenso. Shostak demostró que se necesita un mínimo de 3 n+ 1, e ideó un protocolo de mensajería de dos rondas 3 n+1 que funcionaría para n = 1. Su colega Marshall Pease generalizó el algoritmo para cualquier n > 0, demostrando que 3 n + 1 es necesario y suficiente. Estos resultados, junto con una prueba posterior de Leslie Lamport de la suficiencia de 3 n utilizando firmas digitales, se publicaron en el artículo seminal Reaching Agreement in the Presence of Faults [Alcanzando un acuerdo en presencia de fallos]. [6] Los autores recibieron el premio Edsger W. Dijkstra 2005 por este artículo.
Para que el problema de la coherencia interactiva fuera más fácil de entender, Lamport ideó una colorida alegoría en la que un grupo de generales del ejército formula un plan para atacar una ciudad. En su versión original, la historia presentaba a los generales como comandantes del ejército albanés . El nombre se cambió y finalmente se decidió que sería " bizantino ", por sugerencia de Jack Goldberg para prevenir posibles ataques en el futuro. [7] Esta formulación del problema, junto con algunos resultados adicionales, fueron presentados por los mismos autores en su artículo de 1982, "El problema de los generales bizantinos". [4]
Mitigación
El objetivo de la tolerancia a fallos bizantinos es poder defenderse contra fallos de los componentes del sistema con o sin síntomas que impidan que otros componentes del sistema lleguen a un acuerdo entre ellos, cuando dicho acuerdo sea necesario para el correcto funcionamiento del sistema.
Los componentes restantes operativamente correctos de un sistema tolerante a fallas bizantinas podrán continuar brindando el servicio del sistema como se pretendía originalmente, suponiendo que haya una cantidad suficiente de componentes que funcionen correctamente para mantener el servicio.
Si consideramos la propagación de fallos únicamente a través de errores, los fallos bizantinos se consideran la clase de fallos más general y más difícil entre los modos de fallo . El llamado modo de fallo fail-stop ocupa el extremo más simple del espectro. Mientras que el modo de fallo fail-stop simplemente significa que la única forma de fallar es una caída de un nodo , detectada por otros nodos, los fallos bizantinos no implican restricciones sobre qué errores se pueden crear, lo que significa que un nodo fallido puede generar datos arbitrarios, incluidos datos que lo hacen parecer un nodo funcional a un subconjunto de otros nodos. Por lo tanto, los fallos bizantinos pueden confundir a los sistemas de detección de fallos, lo que dificulta la tolerancia a fallos. A pesar de la alegoría, un fallo bizantino no es necesariamente un problema de seguridad que implique una interferencia humana hostil: puede surgir puramente de fallos físicos o de software.
Los términos falla y fallo se utilizan aquí según las definiciones estándar [8] creadas originalmente por un comité conjunto sobre "Conceptos fundamentales y terminología" formado por el Comité técnico sobre computación confiable y tolerancia a fallas de la IEEE Computer Society y el Grupo de trabajo 10.4 de IFIP sobre computación confiable y tolerancia a fallas. [9] Véase también confiabilidad .
La tolerancia a fallos bizantinos solo se ocupa de la coherencia de la transmisión, es decir, la propiedad de que cuando un componente transmite un valor a todos los demás componentes, todos reciben exactamente el mismo valor o, en caso de que el emisor no sea coherente, los demás componentes acuerden un valor común. Este tipo de tolerancia a fallos no abarca la corrección del valor en sí; por ejemplo, un componente adversario que envía deliberadamente un valor incorrecto, pero envía ese mismo valor de forma coherente a todos los componentes, no quedará atrapado en el esquema de tolerancia a fallos bizantino.
Soluciones
Lamport, Shostak y Pease describieron varias soluciones tempranas en 1982. [4] Comenzaron señalando que el Problema de los Generales se puede reducir a la solución de un problema de "Comandante y Tenientes" donde los Tenientes leales deben actuar todos al unísono y que su acción debe corresponder a lo que ordenó el Comandante en el caso de que el Comandante sea leal:
Una solución considera escenarios en los que se pueden falsificar mensajes, pero que serán tolerantes a fallas bizantinas siempre que el número de generales desleales sea menor que un tercio de los generales. La imposibilidad de lidiar con un tercio o más de traidores en última instancia se reduce a probar que el problema de un comandante y dos tenientes no se puede resolver, si el comandante es traidor. Para ver esto, supongamos que tenemos un comandante traidor A, y dos tenientes, B y C: cuando A le dice a B que ataque y a C que se retire, y B y C se envían mensajes entre sí, reenviando el mensaje de A, ni B ni C pueden averiguar quién es el traidor, ya que no es necesariamente A: el otro teniente podría haber falsificado el mensaje supuestamente de A. Se puede demostrar que si n es el número de generales en total, y t es el número de traidores en ese n , entonces hay soluciones al problema solo cuando n > 3 t y la comunicación es sincrónica (retardo acotado). [10] El conjunto completo de requisitos de BFT son: para un número F de fallas bizantinas, debe haber al menos 3F+1 jugadores (zonas de contención de fallas), 2F+1 rutas de comunicación independientes y F+1 rondas de comunicación. Puede haber modelos de falla híbridos en los que pueden existir fallas benignas (no bizantinas) así como fallas bizantinas simultáneamente. Para cada falla benigna adicional que se deba tolerar, los números anteriores deben incrementarse en uno. Si no existen las rondas de comunicación BFT, pueden ocurrir fallas bizantinas incluso sin hardware defectuoso.
Una segunda solución requiere firmas de mensajes infalsificables. Para sistemas críticos para la seguridad , las firmas digitales (en los sistemas informáticos modernos, esto se puede lograr, en la práctica, mediante el uso de criptografía de clave pública ) pueden proporcionar una tolerancia a fallos bizantinos en presencia de un número arbitrario de generales traidores. Sin embargo, para sistemas críticos para la seguridad (donde la "seguridad" aborda amenazas inteligentes mientras que la "protección" aborda los peligros inherentes de una actividad o misión, es decir, fallos debidos a fenómenos naturales), los códigos de detección de errores, como los CRC , proporcionan una cobertura más fuerte a un costo mucho menor. (Tenga en cuenta que los CRC pueden proporcionar una cobertura garantizada para errores que la criptografía no puede. Si un esquema de cifrado pudiera proporcionar alguna garantía de cobertura para errores de mensajes, tendría una estructura que lo haría inseguro. [11] ) Pero ni las firmas digitales ni los códigos de detección de errores como los CRC proporcionan un nivel conocido de protección contra errores bizantinos de causas naturales. Y, de manera más general, las medidas de seguridad pueden debilitar la seguridad y viceversa. Por lo tanto, los métodos de firma digital criptográfica no son una buena opción para sistemas críticos para la seguridad, a menos que también exista una amenaza específica para la seguridad. [12] Si bien los códigos de detección de errores, como los CRC, son mejores que las técnicas criptográficas, ninguno proporciona una cobertura adecuada para la electrónica activa en sistemas críticos para la seguridad. Esto se ilustra con el escenario de CRC de Schrödinger , donde un mensaje protegido por CRC con un solo bit defectuoso bizantino presenta datos diferentes a diferentes observadores y cada observador ve un CRC válido. [2] [3]
También se presenta [¿ dónde? ] [¿ por quién? ] una variación de las dos primeras soluciones que permite un comportamiento tolerante a fallas bizantinas en algunas situaciones en las que no todos los generales pueden comunicarse directamente entre sí. [ cita requerida ]
Hay muchos sistemas que afirman ser BFT sin cumplir los requisitos mínimos anteriores (por ejemplo, blockchain). Dado que hay pruebas matemáticas de que esto es imposible, estas afirmaciones deben incluir una salvedad: su definición de BFT se aleja de la original. Es decir, sistemas como blockchain no garantizan el acuerdo, solo encarecen el desacuerdo.
En 1980 se diseñaron varias arquitecturas de sistemas que implementaron la tolerancia a fallas bizantinas, entre ellas: FTMP de Draper, [13] MMFCS de Honeywell, [14] y SIFT de SRI. [5]
En 1999, Miguel Castro y Barbara Liskov introdujeron el algoritmo "Practical Byzantine Fault Tolerance" (PBFT), [15] que proporciona replicación de máquina de estados bizantina de alto rendimiento, procesando miles de solicitudes por segundo con aumentos de latencia de submilisegundos.
Después de PBFT, se introdujeron varios protocolos BFT para mejorar su robustez y rendimiento. Por ejemplo, Q/U, [16] HQ, [17] Zyzzyva, [18] y ABsTRACTs, [19] abordaron los problemas de rendimiento y costo; mientras que otros protocolos, como Aardvark [20] y RBFT, [21] abordaron sus problemas de robustez. Además, Adapt [22] intentó hacer uso de los protocolos BFT existentes, a través de cambiar entre ellos de manera adaptativa, para mejorar la robustez y el rendimiento del sistema a medida que cambian las condiciones subyacentes. Además, se introdujeron protocolos BFT que aprovechan los componentes confiables para reducir la cantidad de réplicas, por ejemplo, A2M-PBFT-EA [23] y MinBFT. [24]
Aplicaciones
En dos artículos de revistas científicas equivalentes se dan varios ejemplos de fracasos bizantinos que han ocurrido. [2] [3] Estos y otros ejemplos se describen en las páginas web de NASA DASHlink. [25]
Aplicaciones en informática
Los mecanismos de tolerancia a fallos bizantinos utilizan componentes que repiten un mensaje entrante (o solo su firma, que puede reducirse a un solo bit de información si se utilizan pares de autocomprobación para los nodos) a otros destinatarios de ese mensaje entrante. Todos estos mecanismos parten del supuesto de que el acto de repetir un mensaje bloquea la propagación de síntomas bizantinos. En el caso de los sistemas que tienen un alto grado de criticidad de seguridad o protección, se debe demostrar que estas suposiciones son verdaderas hasta un nivel aceptable de cobertura de fallos . Al proporcionar pruebas mediante pruebas, una dificultad es crear una gama suficientemente amplia de señales con síntomas bizantinos. [26] Es probable que dichas pruebas requieran inyectores de fallos especializados . [27] [28]
Aplicaciones militares
Se observaron errores bizantinos con poca frecuencia y en puntos irregulares durante las pruebas de resistencia de los submarinos de nueva construcción de la clase Virginia , al menos hasta 2005 (cuando se informaron públicamente los problemas). [29]
Aplicaciones de criptomonedas
La red Bitcoin trabaja en paralelo para generar una cadena de bloques con prueba de trabajo que permite al sistema superar fallas bizantinas y alcanzar una visión global coherente del estado del sistema. [30] [31] Algunas cadenas de bloques de prueba de participación también utilizan algoritmos BFT. [32]
Tecnología Blockchain
La tolerancia a fallas bizantinas (BFT, por sus siglas en inglés) es un concepto crucial en la tecnología blockchain , que garantiza que una red pueda seguir funcionando incluso cuando algunos nodos [33] (participantes) fallan o actúan de manera maliciosa. Esta tolerancia es necesaria porque las cadenas de bloques son sistemas descentralizados sin autoridad central, lo que hace que sea esencial lograr un consenso entre los nodos, incluso si algunos intentan interrumpir el proceso.
Aplicaciones y ejemplos de tolerancia a fallas bizantinas en blockchain
Mecanismos de seguridad: Diferentes cadenas de bloques utilizan varios mecanismos de consenso basados en BFT como Practical Byzantine Fault Tolerance (PBFT), Tendermint y Delegated Proof of Stake (DPoS) para manejar fallas bizantinas. Estos protocolos garantizan que la mayoría de los nodos honestos puedan ponerse de acuerdo sobre el siguiente bloque en la cadena, lo que protege la red contra ataques y evita el doble gasto y otros tipos de fraude. Ejemplos prácticos de redes incluyen Hyperledger Fabric , Cosmos y Klever en esta secuencia.
Mitigación de ataques del 51%: mientras que las cadenas de bloques tradicionales como Bitcoin utilizan Prueba de trabajo (PoW), que es susceptible a un ataque del 51%, los sistemas basados en BFT están diseñados para tolerar hasta un tercio de nodos defectuosos o maliciosos sin comprometer la integridad de la red.
Confianza descentralizada: la tolerancia a fallos bizantinos sustenta el modelo de confianza en las redes descentralizadas . En lugar de depender de una autoridad central, la seguridad de la red depende de la capacidad de los nodos honestos de superar en número y maniobrabilidad a los maliciosos.
Cadenas de bloques privadas y autorizadas: BFT es especialmente importante en cadenas de bloques privadas o autorizadas, donde un número limitado de participantes conocidos necesita llegar a un consenso de forma rápida y segura. Estas redes suelen utilizar protocolos BFT para mejorar el rendimiento y la seguridad.
Aplicaciones en la aviación
Algunos sistemas de aeronaves, como el sistema de gestión de información de aeronaves Boeing 777 (a través de su red ARINC 659 SAFEbus), el sistema de control de vuelo Boeing 777 y los sistemas de control de vuelo Boeing 787, utilizan tolerancia a fallas bizantinas; debido a que estos son sistemas en tiempo real, sus soluciones de tolerancia a fallas bizantinas deben tener una latencia muy baja. Por ejemplo, SAFEbus puede lograr tolerancia a fallas bizantinas en el orden de un microsegundo de latencia agregada. [34] [35] [36] El SpaceX Dragon considera la tolerancia a fallas bizantinas en su diseño. [37]
Véase también
Confirmación atómica : operación que aplica un conjunto de cambios distintos como una sola operación
^ Lamport, L. ; Shostak, R.; Pease, M. (1982). "El problema de los generales bizantinos" (PDF) . ACM Transactions on Programming Languages and Systems . 4 (3): 382–401. CiteSeerX 10.1.1.64.2312 . doi :10.1145/357172.357176. S2CID 55899582. Archivado (PDF) desde el original el 13 de junio de 2018.
^ abcd Driscoll, K.; Hall, B.; Paulitsch, M.; Zumsteg, P.; Sivencrona, H. (2004). "Los verdaderos generales bizantinos". La 23.ª Conferencia de sistemas de aviónica digital (IEEE Cat. No. 04CH37576) . págs. 6.D.4–61–11. doi :10.1109/DASC.2004.1390734. ISBN978-0-7803-8539-9.S2CID 15549497 .
^ abc Driscoll, Kevin; Hall, Brendan; Sivencrona, Håkan; Zumsteg, Phil (2003). "Tolerancia a fallos bizantinos, de la teoría a la realidad". Seguridad informática, fiabilidad y protección . Apuntes de clase en informática. Vol. 2788. págs. 235–248. doi :10.1007/978-3-540-39878-3_19. ISBN978-3-540-20126-7. ISSN 0302-9743. S2CID 12690337.
^ abc Lamport, L. ; Shostak, R.; Pease, M. (1982). "El problema de los generales bizantinos" (PDF) . ACM Transactions on Programming Languages and Systems . 4 (3): 387–389. CiteSeerX 10.1.1.64.2312 . doi :10.1145/357172.357176. S2CID 55899582. Archivado desde el original (PDF) el 7 de febrero de 2017.
^ ab "SIFT: diseño y análisis de un computador tolerante a fallos para control de aeronaves". Microelectronics Reliability . 19 (3): 190. 1979. doi :10.1016/0026-2714(79)90211-7. ISSN 0026-2714.
^ Pease, Marshall; Shostak, Robert; Lamport, Leslie (abril de 1980). "Llegar a un acuerdo en presencia de fallos". Revista de la Asociación de Maquinaria Informática . 27 (2): 228–234. CiteSeerX 10.1.1.68.4044 . doi :10.1145/322186.322188. S2CID 6429068.
^ Lamport, Leslie (19 de diciembre de 2016). "El problema de los generales bizantinos". ACM Transactions on Programming Languages and Systems . SRI International . Consultado el 18 de marzo de 2019 .
^ Avizienis, A.; Laprie, J.-C.; Randell, Brian ; Landwehr, C. (2004). "Conceptos básicos y taxonomía de la computación segura y confiable". IEEE Transactions on Dependable and Secure Computing . 1 (1): 11–33. doi :10.1109/TDSC.2004.2. hdl : 1903/6459 . ISSN 1545-5971. S2CID 215753451.
^ "Computación confiable y tolerancia a fallas". Archivado desde el original el 2 de abril de 2015. Consultado el 2 de marzo de 2015 .
^ Feldman, P.; Micali, S. (1997). "Un protocolo probabilístico óptimo para el acuerdo bizantino sincrónico" (PDF) . SIAM J. Comput . 26 (4): 873–933. doi :10.1137/s0097539790187084. Archivado (PDF) desde el original el 2016-03-05 . Consultado el 2012-06-14 .
^ Koopman, Philip; Driscoll, Kevin; Hall, Brendan (marzo de 2015). "Código de redundancia cíclica y algoritmos de suma de comprobación para garantizar la integridad de los datos críticos" (PDF). Administración Federal de Aviación. DOT/FAA/TC-14/49. Archivado (PDF) desde el original el 18 de mayo de 2015. Consultado el 9 de mayo de 2015.
^ Paulitsch, M.; Morris, J.; Hall, B.; Driscoll, K.; Latronico, E.; Koopman, P. (2005). "Cobertura y uso de códigos de redundancia cíclica en sistemas ultraconfiables". Conferencia internacional de 2005 sobre sistemas y redes confiables (DSN'05). págs. 346–355. doi :10.1109/DSN.2005.31. ISBN978-0-7695-2282-1.S2CID 14096385 .
^ Hopkins, Albert L.; Lala, Jaynarayan H.; Smith, T. Basil (1987). "La evolución de la computación tolerante a fallos en el laboratorio Charles Stark Draper, 1955-85". La evolución de la computación tolerante a fallos . Computación confiable y sistemas tolerantes a fallos. Vol. 1. págs. 121-140. doi :10.1007/978-3-7091-8871-2_6. ISBN978-3-7091-8873-6. ISSN 0932-5581.
^ Driscoll, Kevin; Papadopoulos, Gregory; Nelson, Scott; Hartmann, Gary; Ramohalli, Gautham (1984), Sistema de control de vuelo con múltiples microprocesadores (informe técnico), Base de la Fuerza Aérea Wright-Patterson, Ohio: AFWAL/FIGL US Air Force Systems Command, AFWAL-TR-84-3076
^ Castro, M.; Liskov, B. (2002). "Tolerancia práctica a fallos bizantinos y recuperación proactiva". ACM Transactions on Computer Systems . 20 (4). Association for Computing Machinery : 398–461. CiteSeerX 10.1.1.127.6130 . doi :10.1145/571637.571640. S2CID 18793794.
^ Abd-El-Malek, M.; Ganger, G.; Goodson, G.; Reiter, M.; Wylie, J. (2005). "Servicios tolerantes a fallos bizantinos escalables por fallos". Revisión de sistemas operativos ACM SIGOPS . 39 (5). Association for Computing Machinery : 59. doi :10.1145/1095809.1095817.
^ Cowling, James; Myers, Daniel; Liskov, Barbara ; Rodrigues, Rodrigo; Shrira, Liuba (2006). Replicación de HQ: un protocolo de quórum híbrido para tolerancia a fallos bizantinos. Actas del 7.º Simposio USENIX sobre diseño e implementación de sistemas operativos. págs. 177–190. ISBN1-931971-47-1.
^ Kotla, Ramakrishna; Alvisi, Lorenzo; Dahlin, Mike; Clement, Allen; Wong, Edmund (diciembre de 2009). "Zyzzyva: Tolerancia a fallos bizantinos especulativos". ACM Transactions on Computer Systems . 27 (4). Association for Computing Machinery : 1–39. doi :10.1145/1658357.1658358.
^ Guerraoui, Rachid; Kneževic, Nikola; Vukolic, Marko; Quéma, Vivien (2010). Los próximos 700 protocolos BFT. Actas de la 5.ª conferencia europea sobre sistemas informáticos. EuroSys. Archivado desde el original el 2 de octubre de 2011. Consultado el 4 de octubre de 2011 .
^ Clement, A.; Wong, E.; Alvisi, L.; Dahlin, M.; Marchetti, M. (22–24 de abril de 2009). Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults (PDF) . Simposio sobre diseño e implementación de sistemas en red. USENIX . Archivado (PDF) desde el original el 25 de diciembre de 2010 . Consultado el 17 de febrero de 2010 .
^ Aublin, P.-L.; Ben Mokhtar, S.; Quéma, V. (8–11 de julio de 2013). RBFT: Tolerancia a fallos bizantinos redundantes. 33.ª Conferencia internacional IEEE sobre sistemas informáticos distribuidos. Conferencia internacional sobre sistemas informáticos distribuidos . Archivado desde el original el 5 de agosto de 2013.
^ Bahsoun, JP; Guerraoui, R.; Shoker, A. (1 de mayo de 2015). "Cómo hacer que los protocolos BFT sean realmente adaptativos". Simposio internacional IEEE sobre procesamiento paralelo y distribuido de 2015. págs. 904–913. doi :10.1109/IPDPS.2015.21. ISBN978-1-4799-8649-1. Número de identificación del sujeto 16310807.
^ Chun, Byung-Gon; Maniatis, Petros; Shenker, Scott; Kubiatowicz, John (1 de enero de 2007). "Memoria de solo anexión certificada". Actas del vigésimo primer simposio ACM SIGOPS sobre principios de sistemas operativos . SOSP '07. Nueva York, NY, EE. UU.: ACM. págs. 189–204. doi :10.1145/1294261.1294280. ISBN9781595935915.S2CID6685352 .
^ Veronese, GS; Correia, M.; Bessani, AN; Lung, LC; Verissimo, P. (1 de enero de 2013). "Tolerancia a fallos bizantinos eficiente". IEEE Transactions on Computers . 62 (1): 16–30. CiteSeerX 10.1.1.408.9972 . doi :10.1109/TC.2011.221. ISSN 0018-9340. S2CID 8157723.
^ Driscoll, Kevin (11 de diciembre de 2012). "Real System Failures" (Fallas del sistema real). DASHlink . NASA . Archivado desde el original el 2 de abril de 2015 . Consultado el 2 de marzo de 2015 .
^ Nanya, T.; Goosen, HA (1989). "El modelo de falla de hardware bizantino". IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems . 8 (11): 1226–1231. doi :10.1109/43.41508. ISSN 0278-0070.
^ Martín, Rolando; Gandhi, Rajeev; Narasimhan, Priya; Pertet, Soila; Casimiro, Antonio; Kreutz, Diego; Veríssimo, Paulo (2013). "Experiencias con inyección de fallas en un protocolo bizantino tolerante a fallas". Middleware 2013 . Apuntes de conferencias sobre informática. vol. 8275, págs. 41–61. doi :10.1007/978-3-642-45065-5_3. ISBN978-3-642-45064-8. ISSN 0302-9743. S2CID 31337539.
^ Patente estadounidense 7475318, Kevin R. Driscoll, "Método para probar el rango de entrada sensible de filtros bizantinos", emitida el 6 de enero de 2009, asignada a Honeywell International Inc.
^ Walter, C.; Ellis, P.; LaValley, B. (2005). "El servicio de plataforma confiable: una arquitectura de servicio tolerante a fallas basada en propiedades". Noveno Simposio Internacional IEEE sobre Ingeniería de Sistemas de Alta Seguridad (HASE'05) . págs. 34–43. doi :10.1109/HASE.2005.23. ISBN978-0-7695-2377-4. Número de identificación del sujeto 21468069.
^ Rubby, Matt (20 de enero de 2024). "Cómo se relaciona el problema de los generales bizantinos con usted en 2024". Swan Bitcoin . Consultado el 27 de enero de 2024 .
^ Tholoniat, Pierre; Gramoli, Vincent (2022), Tran, Duc A.; Thai, My T.; Krishnamachari, Bhaskar (eds.), "Verificación formal de la tolerancia a fallas bizantinas de la cadena de bloques", Manual sobre cadena de bloques , Springer Optimization and Its Applications, Cham: Springer International Publishing, págs. 389–412, arXiv : 1909.07453 , doi :10.1007/978-3-031-07535-3_12, ISBN978-3-031-07535-3, consultado el 27 de enero de 2024
^ Deirmentzoglou, Papakyriakopoulos y Patsakis 2019, p. 28716.
^ "Operaciones de nodo".
^ M., Paulitsch; Driscoll, K. (9 de enero de 2015). "Capítulo 48: SAFEbus". En Zurawski, Richard (ed.). Manual de tecnología de comunicación industrial, segunda edición . CRC Press. págs. 48–1–48–26. ISBN978-1-4822-0733-0.
^ Thomas A. Henzinger; Christoph M. Kirsch (26 de septiembre de 2001). Embedded Software: First International Workshop, EMSOFT 2001, Tahoe City, CA, EE. UU., 8-10 de octubre de 2001. Actas (PDF) . Springer Science & Business Media. págs. 307–. ISBN978-3-540-42673-8. Archivado (PDF) del original el 22 de septiembre de 2015. Consultado el 5 de marzo de 2015 .
^ Yeh, YC (2001). "Aviónica crítica para la seguridad del sistema de control de vuelo primario del 777". 20.ª DASC. 20.ª Conferencia sobre sistemas de aviónica digital (n.º de cat. 01CH37219) . Vol. 1. págs. 1C2/1–1C2/11. doi :10.1109/DASC.2001.963311. ISBN .978-0-7803-7034-0.S2CID61489128 .
^ "ELC: Lecciones aprendidas por SpaceX [LWN.net]". Archivado desde el original el 5 de agosto de 2016. Consultado el 21 de julio de 2016 .
Fuentes
Deirmentzoglou, Evangelos; Papakyriakopoulos, Georgios; Patsakis, Constantinos (2019). "Una encuesta sobre ataques de largo alcance para protocolos de prueba de participación". IEEE Access . 7 : 28712–28725. Bibcode :2019IEEEA...728712D. doi : 10.1109/ACCESS.2019.2901858 . eISSN 2169-3536. S2CID 84185792.
Bashir, Imran. "Consenso de blockchain". Consenso de blockchain: una introducción a los protocolos de consenso clásicos, de blockchain y cuánticos . ISBN 978-1-4842-8178-9 Apress, Berkeley, CA, 2022. doi :10.1007/978-1-4842-8179-6
