stringtranslate.com

Falla bizantina

Un fallo bizantino es una condición de un sistema, en particular un sistema informático distribuido , en la que se produce un fallo de tal manera que se presentan diferentes síntomas a distintos observadores, incluida información imperfecta sobre si un componente del sistema ha fallado. El término toma su nombre de una alegoría , el "problema de los generales bizantinos", [1] desarrollado para describir una situación en la que, para evitar un fallo catastrófico de un sistema, los actores del sistema deben ponerse de acuerdo sobre una estrategia, pero algunos de estos actores no son fiables de tal manera que hacen que otros actores (buenos) no estén de acuerdo sobre la estrategia y es posible que no sean conscientes de dicho desacuerdo.

Una falla bizantina también se conoce como un problema de generales bizantinos , un problema de acuerdo bizantino o un fracaso bizantino .

La tolerancia a fallas bizantinas ( BFT ) es la resiliencia de un sistema informático tolerante a fallas o un sistema similar a tales condiciones.

Definición

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:

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

Referencias

  1. ^ 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.
  2. ^ 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. ISBN 978-0-7803-8539-9.S2CID 15549497  .
  3. ^ 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. ISBN 978-3-540-20126-7. ISSN  0302-9743. S2CID  12690337.
  4. ^ 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. 
  5. ^ 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.
  6. ^ 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. 
  7. ^ 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 .
  8. ^ 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.
  9. ^ "Computación confiable y tolerancia a fallas". Archivado desde el original el 2 de abril de 2015. Consultado el 2 de marzo de 2015 .
  10. ^ 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 .
  11. ^ 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.
  12. ^ 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. ISBN 978-0-7695-2282-1.S2CID 14096385  .
  13. ^ 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. ISBN 978-3-7091-8873-6. ISSN  0932-5581.
  14. ^ 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
  15. ^ 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. 
  16. ^ 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.
  17. ^ 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. ISBN 1-931971-47-1.
  18. ^ 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.
  19. ^ 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 .
  20. ^ 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 .
  21. ^ 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.
  22. ^ 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. ISBN 978-1-4799-8649-1. Número de identificación del sujeto  16310807.
  23. ^ 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. ISBN 9781595935915.S2CID6685352  .​
  24. ^ 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. 
  25. ^ 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 .
  26. ^ 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.
  27. ^ 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. ISBN 978-3-642-45064-8. ISSN  0302-9743. S2CID  31337539.
  28. ^ 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. 
  29. ^ 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. ISBN 978-0-7695-2377-4. Número de identificación del sujeto  21468069.
  30. ^ 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 .
  31. ^ 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, ISBN 978-3-031-07535-3, consultado el 27 de enero de 2024
  32. ^ Deirmentzoglou, Papakyriakopoulos y Patsakis 2019, p. 28716.
  33. ^ "Operaciones de nodo".
  34. ^ 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. ISBN 978-1-4822-0733-0.
  35. ^ 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–. ISBN 978-3-540-42673-8. Archivado (PDF) del original el 22 de septiembre de 2015. Consultado el 5 de marzo de 2015 .
  36. ^ 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  .​
  37. ^ "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

Enlaces externos