Un fallo bizantino (también consistencia interactivo , congruencia fuente , avalancha error , problema acuerdo bizantino , bizantino problema generales , y fracaso bizantino [1] ) es una condición de un sistema informático, en particular Distributed Computing sistemas, donde los componentes puede fallar y no es imperfecta información sobre si un componente ha fallado. El término toma su nombre de una alegoría , el "Problema de los generales bizantinos", [2] desarrollado para describir una situación en la que, para evitar una falla catastrófica del sistema, los actores del sistema deben acordar una estrategia concertada, pero algunos de estos actores no son confiables.
En una falla bizantina, un componente como un servidor puede aparecer de manera inconsistente como fallado y funcionando a los sistemas de detección de fallas, presentando diferentes síntomas a diferentes observadores. Es difícil para los otros componentes declarar que falló y cerrarlo de la red, porque primero necesitan llegar a un consenso sobre qué componente ha fallado en primer lugar.
La tolerancia a fallas bizantina ( BFT ) es la confiabilidad de un sistema informático tolerante a fallas en tales condiciones.
Caracteristicas
Una falla bizantina es cualquier falla que presenta diferentes síntomas a diferentes observadores. [3] Una falla bizantina es la pérdida de un servicio del sistema debido a una falla bizantina en sistemas que requieren consenso . [4]
El objetivo de la tolerancia a fallas bizantina es poder defenderse de fallas de los componentes del sistema con o sin síntomas que impidan que otros componentes del sistema lleguen a un acuerdo entre sí, donde tal acuerdo es necesario para el correcto funcionamiento del sistema.
Los restantes componentes operacionalmente correctos de un sistema tolerante a fallas bizantino podrán continuar brindando el servicio del sistema como se pretendía originalmente, asumiendo que hay una cantidad suficiente de componentes operando con precisión para mantener el servicio.
Las fallas bizantinas se consideran la clase de fallas más general y más difícil entre los modos de falla . El llamado modo de falla de parada por falla ocupa el extremo más simple del espectro. Mientras que el modo de falla de parada por falla simplemente significa que la única forma de fallar es un bloqueo de nodo , detectado por otros nodos, las fallas bizantinas no implican restricciones, lo que significa que el nodo fallado puede generar datos arbitrarios, incluidos datos que lo hacen parecer como un funcionamiento nodo. Por lo tanto, las fallas bizantinas pueden confundir a los sistemas de detección de fallas, lo que dificulta la tolerancia a fallas. A pesar de la analogía, una falla bizantina no es necesariamente un problema de seguridad que involucre interferencia humana hostil: puede surgir puramente de fallas eléctricas o de software.
Los términos falla y falla se utilizan aquí de acuerdo con las definiciones estándar [5] creadas originalmente por un comité conjunto sobre "Conceptos y terminología fundamentales" formado por el Comité Técnico de Computación confiable y tolerancia a fallas de la IEEE Computer Society y el Grupo de trabajo IFIP 10.4 sobre Computación confiable y tolerancia a fallas. [6] También se describe una versión de estas definiciones en la página de Wikipedia de confiabilidad .
Consideración
La tolerancia a fallas bizantina solo se ocupa de la corrección de la transmisión, es decir, la propiedad de que cuando un componente transmite un único valor consistente a otros componentes (es decir, envía el mismo valor a los otros componentes), todos reciben exactamente el mismo valor, o en el En caso de que la emisora no sea coherente, los demás componentes acuerdan un valor común. Este tipo de tolerancia a fallos no incluye la corrección del valor en sí; por ejemplo, un componente contradictorio que envía deliberadamente un valor incorrecto, pero envía ese mismo valor de manera consistente a todos los componentes, no quedará atrapado en el esquema de tolerancia a fallas bizantino.
Definicion formal
Escenario: [7] Dado un sistema de n componentes, t de los cuales son deshonestos, y asumiendo solo un canal punto a punto entre todos los componentes.
Cuando un componente A intentos para transmitir un valor x , los otros componentes están autorizados a discutir entre sí y verificar la consistencia de una emisión 's, y, finalmente establecerse en un valor común y .
Propiedad: Se dice que el sistema resiste fallas bizantinas si un componente A puede transmitir un valor x , y luego:
- Si A es honesto, entonces todos los componentes honestos concuerdan en el valor x .
- En cualquier caso, todos los componentes honestos coinciden en el mismo valor y .
Variantes: El problema se ha estudiado en el caso de comunicaciones tanto síncronas como asíncronas.
Se supone que el gráfico de comunicación anterior es el gráfico completo (es decir, cada componente se puede discutir entre sí), pero el gráfico de comunicación se puede restringir.
También se puede relajar en un problema más "realista" en el que los componentes defectuosos no se unen en un intento de inducir a los demás al error. Es en este escenario donde se han diseñado algoritmos prácticos.
Historia
El problema de la obtención del consenso bizantino fue concebido y formalizado por Robert Shostak , quien lo denominó el problema de la coherencia interactiva . Este trabajo se realizó en 1978 en el contexto del proyecto SIFT [8] patrocinado por la NASA en el Laboratorio de Ciencias de la Computación en SRI International . SIFT (para tolerancia a fallas implementadas por software) fue la creación de John Wensley, y se basó en la idea de usar múltiples computadoras de propósito general que se comunicarían a través de mensajes por pares para llegar a un consenso, incluso si algunas de las computadoras tenían fallas .
Al comienzo del proyecto, no estaba claro cuántas computadoras en total se necesitan para garantizar que una conspiración de n computadoras defectuosas no pueda "frustrar" los esfuerzos de las que funcionan correctamente para llegar a un consenso. Shostak demostró que se necesita un mínimo de 3 n + 1, e ideó un protocolo de mensajería 3 n + 1 de dos rondas 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. [9] Los autores recibieron el premio Edsger W. Dijkstra 2005 por este artículo.
Para facilitar la comprensión del problema de la coherencia interactiva, Lamport ideó una alegoría colorida en la que un grupo de generales del ejército formula un plan para atacar una ciudad. En su versión original, la historia presenta a los generales como comandantes del ejército albanés . El nombre fue cambiado, y finalmente se decidió por " Bizantino ", a sugerencia de Jack Goldberg para garantizar el futuro de cualquier posible infracción. [10] 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". [11]
Analogía
En su forma más simple, los generales deben decidir solo si atacar o retirarse. Algunos generales pueden preferir atacar, mientras que otros prefieren retirarse. Lo importante es que todos los generales acuerden una decisión común, ya que un ataque a medias 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 esos generales 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 ir bien 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.
Resolución
La tolerancia bizantina a las fallas se puede lograr si los generales leales (no defectuosos) tienen un acuerdo mayoritario sobre su estrategia. Puede haber un valor de voto predeterminado dado a los mensajes faltantes. Por ejemplo, a los mensajes que faltan se les puede asignar el valor
El mapeo típico de esta historia en los sistemas informáticos es que las computadoras son los generales y los enlaces de sus sistemas de comunicación digital son los mensajeros. Si bien el problema se formula en la analogía como un problema de toma de decisiones y de seguridad, en la electrónica no se puede resolver simplemente mediante firmas digitales criptográficas , porque fallas como voltajes incorrectos pueden propagarse a través del proceso de encriptación. Por lo tanto, un componente puede parecer funcionando para un componente y defectuoso para otro, lo que impide formar un consenso sobre si el componente está defectuoso o no.
Ejemplos de
En dos artículos de revistas equivalentes se dan varios ejemplos de fallas bizantinas que han ocurrido. [3] [4] Estos y otros ejemplos se describen en las páginas web de NASA DASHlink. [12] Estas páginas web también describen algunos fenómenos que pueden causar fallas bizantinas.
Los errores bizantinos se observaron con poca frecuencia y en puntos irregulares durante las pruebas de resistencia para los submarinos de la clase Virginia recién construidos , al menos hasta 2005 (cuando los problemas se informaron públicamente). [13]
Soluciones tempranas
Lamport, Shostak y Pease describieron varias soluciones en 1982. [11] Comenzaron señalando que el problema de los generales se puede reducir a resolver un problema de "comandante y tenientes" en el que los tenientes leales deben actuar todos al unísono y que su acción debe corresponder a lo ordenado por 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 las fallas bizantinas siempre que el número de generales desleales sea menos de un tercio de los generales. La imposibilidad de tratar con un tercio o más traidores se reduce en última instancia a demostrar 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 A traidor y dos Tenientes, B y C: cuando A le dice a B que ataque y 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; otro teniente podría haber falsificado el mensaje supuestamente a partir 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 ty la comunicación es síncrona (retardo limitado). [14]
- Una segunda solución requiere firmas de mensajes infalsificables. Para los sistemas críticos para la seguridad , las firmas digitales (en los sistemas informáticos modernos, esto se puede lograr en la práctica utilizando criptografía de clave pública ) pueden proporcionar tolerancia a fallas bizantinas en presencia de un número arbitrario de generales traidores. Sin embargo, para los sistemas críticos para la seguridad (donde la "seguridad" aborda las amenazas inteligentes mientras que la "seguridad" aborda los peligros inherentes de una actividad o misión), los códigos de detección de errores simples, como los CRC , brindan una cobertura más débil pero a menudo suficiente a un costo mucho menor. . Esto es cierto tanto para las fallas bizantinas como para las no bizantinas. Además, a veces las medidas de seguridad debilitan la seguridad y viceversa. Por lo tanto, los métodos de firma digital criptográfica no son una buena opción para los sistemas críticos para la seguridad, a menos que también exista una amenaza de seguridad específica. [15] 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 en el escenario de CRC de Schrödinger donde un mensaje protegido por CRC con un solo bit defectuoso bizantino presenta diferentes datos a diferentes observadores y cada observador ve un CRC válido. [3] [4]
- También se presenta una variación de las dos primeras soluciones que permiten un comportamiento tolerante a fallas bizantinas en algunas situaciones en las que no todos los generales pueden comunicarse directamente entre sí.
Se diseñaron varias arquitecturas de sistemas c. 1980 que implementó la tolerancia a fallas bizantinas. Estos incluyen: FTMP de Draper, [16] MMFCS de Honeywell, [17] y SIFT de SRI. [8]
Soluciones avanzadas
En 1999, Miguel Castro y Barbara Liskov introdujeron el algoritmo "Practical Byzantine Fault Tolerance" (PBFT), [18] que proporciona replicación de máquina de estado 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, [19] HQ, [20] Zyzzyva, [21] y ABsTRACTs, [22] abordaron los problemas de rendimiento y costos; mientras que otros protocolos, como Aardvark [23] y RBFT, [24] abordaron sus problemas de robustez. Además, Adapt [25] intentó hacer uso de los protocolos BFT existentes, cambiando entre ellos de forma adaptativa, para mejorar la solidez 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 el número de réplicas, por ejemplo, A2M-PBFT-EA [26] y MinBFT. [27]
Motivado por PBFT, Tendermint BFT [28] se introdujo para redes asíncronas parciales y se utiliza principalmente para cadenas de bloques de prueba de participación.
Implementaciones de BFT
Un ejemplo de BFT en uso es bitcoin , un sistema de efectivo digital peer-to-peer. [29] La red bitcoin funciona en paralelo para generar una cadena de bloques con prueba de trabajo que permite al sistema superar las fallas bizantinas y alcanzar una visión global coherente del estado del sistema.
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 ), [30] [31] el sistema de control de vuelo del Boeing 777, [32] y los sistemas de control de vuelo del Boeing 787 utilizan tolerancia a fallas bizantina; 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 dentro del orden de un microsegundo de latencia adicional.
Algunos sistemas de vuelo de naves espaciales como el del SpaceX Dragon [33] consideran la tolerancia a fallas bizantinas en su diseño.
Los mecanismos bizantinos de tolerancia a fallas utilizan componentes que repiten un mensaje entrante (o simplemente su firma) a otros destinatarios de ese mensaje entrante. Todos estos mecanismos suponen que el acto de repetir un mensaje bloquea la propagación de los síntomas bizantinos. Para los sistemas que tienen un alto grado de seguridad o criticidad de la protección, se debe demostrar que estas suposiciones son verdaderas para un nivel aceptable de cobertura de fallas . Al proporcionar pruebas a través de pruebas, una dificultad es crear una gama suficientemente amplia de señales con síntomas bizantinos. [34] Dichas pruebas probablemente requerirán inyectores de fallas especializados. [35] [36]
Software
- UpRight es una biblioteca de código abierto para construir servicios que toleran tanto bloqueos ("arriba") como comportamientos bizantinos ("correcto") que incorpora muchas de las innovaciones de estos protocolos. [37]
- La biblioteca BFT-SMaRt es una biblioteca de replicación de máquina de estado bizantina tolerante a fallas de alto rendimiento desarrollada en Java. Esta biblioteca implementa un protocolo muy similar al de PBFT, además de protocolos complementarios que ofrecen transferencia de estado y reconfiguración de hosts sobre la marcha. BFT-SMaRt es el esfuerzo más reciente para implementar la replicación de la máquina de estado, que aún se mantiene de forma activa. [38]
- Archistar utiliza una fina capa BFT para la comunicación. Crea un prototipo de un sistema de almacenamiento seguro de múltiples nubes que utiliza Java con licencia LGPLv2. El enfoque radica en la simplicidad y la legibilidad, su objetivo es ser la base para futuros proyectos de investigación. [39] [40]
- Askemos es una plataforma de programación persistente, simultánea y recolectada de basura sobre máquinas de estado replicadas que tolera fallas bizantinas. Crea un prototipo de un entorno de ejecución que facilita los contratos inteligentes . [41]
Ver también
- Compromiso atómico
- Algoritmo de Brooks-Iyengar
- Lista de términos relacionados con algoritmos y estructuras de datos
- Paxos bizantinos
- Acuerdo cuántico bizantino
- El problema de dos generales
Referencias
- ^ Kirrmann, Hubert (sin fecha). "Computación tolerante a fallas en la automatización industrial" (PDF) . Suiza: Centro de Investigación ABB. pag. 94. Archivado desde el original (PDF) el 26 de marzo de 2014 . Consultado el 2 de marzo de 2015 .
- ^ Lamport, L .; Shostak, R .; Pease, M. (1982). "El problema de los generales bizantinos" (PDF) . Transacciones ACM sobre lenguajes y sistemas de programación . 4 (3): 382–401. CiteSeerX 10.1.1.64.2312 . doi : 10.1145 / 357172.357176 . Archivado (PDF) desde el original el 13 de junio de 2018.
- ^ a b c 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 .
- ^ a b c Driscoll, Kevin; Hall, Brendan; Sivencrona, Håkan; Zumsteg, Phil (2003). "Tolerancia a fallas bizantinas, de la teoría a la realidad". Seguridad informática, confiabilidad y seguridad . Apuntes de conferencias en Ciencias de la Computación. 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 .
- ^ Avizienis, A .; Laprie, J.-C .; Randell, Brian ; Landwehr, C. (2004). "Conceptos básicos y taxonomía de la informática confiable y segura". Transacciones IEEE sobre computación segura y confiable . 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 .
- ^ Matthias Fitzi (2002). "Modelos generalizados de comunicación y seguridad en el acuerdo bizantino" (PDF) . ETH Zurich .
- ^ a b "SIFT: diseño y análisis de un ordenador tolerante a fallos para el control de aeronaves". Fiabilidad de la microelectrónica . 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 fallas". 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" . Transacciones ACM sobre lenguajes y sistemas de programación . SRI Internacional . Consultado el 18 de marzo de 2019 .
- ^ a b c Lamport, L .; Shostak, R .; Pease, M. (1982). "El problema de los generales bizantinos" (PDF) . Transacciones ACM sobre lenguajes y sistemas de programación . 4 (3): 387–389. CiteSeerX 10.1.1.64.2312 . doi : 10.1145 / 357172.357176 . Archivado desde el original (PDF) el 7 de febrero de 2017.
- ^ Driscoll, Kevin (11 de diciembre de 2012). "Fallos reales del sistema" . DASHlink . NASA . Archivado desde el original el 2 de abril de 2015 . Consultado el 2 de marzo de 2015 .
- ^ 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. S2CID 21468069 .
- ^ 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 5 de marzo de 2016 . Consultado el 14 de junio de 2012 .
- ^ 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 ultradependientes". 2005 Conferencia internacional sobre redes y sistemas fiables (DSN'05) . págs. 346–355. doi : 10.1109 / DSN.2005.31 . ISBN 978-0-7695-2282-1. S2CID 14096385 .
- ^ Hopkins, Albert L .; Lala, Jaynarayan H .; Smith, T. Basil (1987). "La evolución de la informática tolerante a fallas en el laboratorio Charles Stark Draper, 1955-1985". La evolución de la informática tolerante a fallos . Computación confiable y sistemas tolerantes a fallas. 1 . págs. 121–140. doi : 10.1007 / 978-3-7091-8871-2_6 . ISBN 978-3-7091-8873-6. ISSN 0932-5581 .
- ^ Driscoll, Kevin; Papadopoulos, Gregory; Nelson, Scott; Hartmann, Gary; Ramohalli, Gautham (1984), Multi-Microprocessor Flight Control System (Technical Report), Wright-Patterson Air Force Base, OH 45433, USA: AFWAL / FIGL US Air Force Systems Command, AFWAL-TR-84-3076Mantenimiento de CS1: ubicación ( enlace )
- ^ Castro, M .; Liskov, B. (2002). "Práctica tolerancia a fallos bizantinos y recuperación proactiva". Transacciones ACM en sistemas informáticos . Asociación de Maquinaria Informática . 20 (4): 398–461. CiteSeerX 10.1.1.127.6130 . doi : 10.1145 / 571637.571640 . S2CID 18793794 .
- ^ Abd-El-Malek, M .; Ganger, G .; Buena canción.; Reiter, M .; Wylie, J. (2005). "Servicios tolerantes a fallos bizantinos escalables a fallos". Revisión de sistemas operativos ACM SIGOPS . Asociación de Maquinaria Informática . 39 (5): 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 fallas bizantinas . Actas del 7º Simposio USENIX sobre Diseño e Implementación de Sistemas Operativos. págs. 177–190. ISBN 1-931971-47-1.
- ^ Kotla, Ramakrishna; Alvisi, Lorenzo; Dahlin, Mike; Clemente, Allen; Wong, Edmund (diciembre de 2009). "Zyzzyva: tolerancia a fallas bizantinas especulativas". Transacciones ACM en sistemas informáticos . Asociación de Maquinaria Informática . 27 (4): 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 a 24 de abril de 2009). Hacer que los sistemas bizantinos tolerantes a fallas toleren fallas bizantinas (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 al 11 de julio de 2013). RBFT: tolerancia a fallos bizantinos redundantes . 33ª Conferencia Internacional IEEE sobre Sistemas de Computación Distribuida. Congreso Internacional de Sistemas de Computación Distribuida . Archivado desde el original el 5 de agosto de 2013.
- ^ Bahsoun, JP; Guerraoui, R .; Shoker, A. (1 de mayo de 2015). "Hacer protocolos BFT realmente adaptables" . Simposio de procesamiento paralelo y distribuido (IPDPS), 2015 IEEE International : 904–913. doi : 10.1109 / IPDPS.2015.21 . ISBN 978-1-4799-8649-1. S2CID 16310807 .
- ^ Chun, Byung-Gon; Maniatis, Petros; Shenker, Scott; Kubiatowicz, John (1 de enero de 2007). "Memoria atestiguada solo para agregar: hacer que los adversarios se apeguen a su palabra". Actas del vigésimo primer simposio de ACM SIGOPS sobre principios de sistemas operativos . SOSP '07. Nueva York, NY, EE. UU .: ACM: 189–204. doi : 10.1145 / 1294261.1294280 . ISBN 9781595935915. S2CID 6685352 .
- ^ Veronese, GS; Correia, M .; Bessani, AN; Pulmón, LC; Verissimo, P. (1 de enero de 2013). "Tolerancia a fallos bizantinos eficiente". Transacciones IEEE en computadoras . 62 (1): 16–30. CiteSeerX 10.1.1.408.9972 . doi : 10.1109 / TC.2011.221 . ISSN 0018-9340 . S2CID 8157723 .
- ^ Buchman, E .; Kwon, J .; Milosevic, Z. (2018). "El último chisme sobre el consenso de BFT". arXiv : 1807.04938 [ cs.DC ].
- ^ "Bitcoin - Dinero P2P de código abierto" . bitcoin.org . Consultado el 18 de agosto de 2019 .
- ^ M., Paulitsch; Driscoll, K. (9 de enero de 2015). "Capítulo 48: SAFEbus" . En Zurawski, Richard (ed.). Manual de tecnología de la comunicación industrial, segunda edición . Prensa CRC. págs. 48–1–48–26. ISBN 978-1-4822-0733-0.
- ^ Thomas A. Henzinger; Christoph M. Kirsch (26 de septiembre de 2001). Software integrado: Primer taller internacional, EMSOFT 2001, Tahoe City, CA, EE. UU., 8 al 10 de octubre de 2001. Actas (PDF) . Springer Science & Business Media. págs. 307–. ISBN 978-3-540-42673-8. Archivado (PDF) desde el original el 22 de septiembre de 2015 . Consultado el 5 de marzo de 2015 .
- ^ Sí, YC (2001). "Aviónica crítica de seguridad para el sistema de controles de vuelo primario 777". 20º DASC. 20ª Conferencia de Sistemas de Aviónica Digital (Cat. No 01CH37219) . 1 . págs. 1C2 / 1–1C2 / 11. doi : 10.1109 / DASC.2001.963311 . ISBN 978-0-7803-7034-0. S2CID 61489128 .
- ^ "ELC: lecciones aprendidas de SpaceX [LWN.net]" . Archivado desde el original el 5 de agosto de 2016 . Consultado el 21 de julio de 2016 .
- ^ Nanya, T .; Goosen, HA (1989). "El modelo de falla de hardware bizantino". Transacciones IEEE sobre diseño asistido por computadora de circuitos y sistemas integrados . 8 (11): 1226-1231. doi : 10.1109 / 43.41508 . ISSN 0278-0070 .
- ^ Martins, Rolando; Gandhi, Rajeev; Narasimhan, Priya; Pertet, Soila; Casimiro, António; Kreutz, Diego; Veríssimo, Paulo (2013). "Experiencias con inyección de fallas en un protocolo tolerante a fallas bizantino". Middleware 2013 . Apuntes de conferencias en Ciencias de la Computación. 8275 . págs. 41–61. doi : 10.1007 / 978-3-642-45065-5_3 . ISBN 978-3-642-45064-8. ISSN 0302-9743 .
- ^ Patente estadounidense 7475318 , Kevin R. Driscoll, "Método para probar el rango de entrada sensible de los filtros bizantinos", emitida el 6 de enero de 2009 , asignada a Honeywell International Inc.
- ^ "Repositorio de código de Google para la biblioteca de replicación de UpRight" . Archivado desde el original el 15 de abril de 2016.
- ^ "Repositorio de la biblioteca de replicación BFT-SMaRt" .
- ^ "repositorio de github para el proyecto Archistar" . 2019-05-28. Archivado desde el original el 4 de febrero de 2015.
- ^ "repositorio de github para el proyecto Archistar" . 2019-04-28. Archivado desde el original el 13 de junio de 2017.
- ^ "Página de inicio de Askemos" . Archivado desde el original el 3 de mayo de 2016.
enlaces externos
- Tolerancia a fallas bizantinas en RKBExplorer