Hispanopedia Wiki
Articulo de referencia

falla bizantina

Una falla bizantina es una condición de un sistema, particularmente un sistema de computación distribuida , donde ocurre una falla de tal manera que se presentan diferentes sínt...

Hispanopedia WikiContenido en espanolLectura gratuita

Una falla bizantina es una condición de un sistema, particularmente un sistema de computación distribuida , donde ocurre una falla de tal manera que se presentan diferentes síntomas a diferentes observadores, incluyendo 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 ] , desarrollada para describir una situación en la que, para evitar una falla catastrófica de un sistema, los actores del sistema deben ponerse de acuerdo en una estrategia, pero algunos de estos actores no son confiables de tal manera que hacen que otros actores (buenos) discrepen sobre la estrategia y pueden no ser conscientes de la discrepancia.

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

La tolerancia a fallos bizantinos ( BFT , por sus siglas en inglés) es la capacidad de un sistema informático tolerante a fallos o un sistema similar para resistir este tipo de condiciones.

Definición

Una falla bizantina es cualquier falla que presenta síntomas diferentes a distintos 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 de forma coordinada, se gana la batalla (izquierda). Si dos generales declaran falsamente su intención de atacar, pero en cambio se retiran, se pierde la batalla (derecha).

La alegoría bizantina presenta a varios generales que atacan una fortaleza. Deben decidir en grupo si atacar o retirarse; algunos prefieren atacar, mientras que otros optan por la retirada. Lo importante es que todos los generales lleguen a un acuerdo, pues un ataque tibio de unos pocos se convertiría en una derrota aplastante , peor que un ataque o una retirada coordinados.

El problema se complica por la presencia de generales traicioneros que no solo pueden votar por una estrategia subóptima, sino que además pueden hacerlo de forma selectiva. Por ejemplo, si nueve generales votan, cuatro de los cuales apoyan el ataque y otros cuatro la retirada, el noveno general podría enviar un voto de retirada a los generales que la apoyan y un voto de ataque al resto. Quienes reciban el voto de retirada del noveno general se retirarán, mientras que el resto atacará (lo que podría resultar desfavorable para los atacantes). El problema se complica aún más por la separación física de los generales y la necesidad de enviar sus votos a través de mensajeros que podrían no entregarlos o falsificar votos.

Sin firma de mensajes, la tolerancia a fallos bizantinos solo se puede lograr si el número total de generales es mayor que tres veces el número de generales desleales (defectuosos). Se puede asignar un valor de voto predeterminado a los mensajes faltantes. Por ejemplo, a los mensajes faltantes se les puede asignar un valor "nulo" . Además, si se acuerda que los votos nulos son mayoría, se puede utilizar una estrategia predeterminada preasignada (por ejemplo, la retirada). [ 4 ]

La aplicación típica de esta alegoría a los sistemas informáticos consiste en que los ordenadores son los generales y sus enlaces de comunicación digital son los mensajeros. Si bien el problema se formula en la alegoría como un problema de toma de decisiones y seguridad, en electrónica no puede resolverse únicamente con firmas digitales criptográficas , ya que fallos como voltajes incorrectos pueden propagarse a través del proceso de cifrado. Así, podría enviarse un mensaje defectuoso de tal manera que algunos destinatarios lo detecten como defectuoso (firma incorrecta), otros lo vean como una firma válida, y un tercer grupo también vea una firma válida, pero con un contenido de mensaje diferente al del segundo grupo. [ 2 ]

Historia

El problema de obtener consenso bizantino fue concebido y formalizado por Robert Shostak , quien lo denominó problema de 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) fue una idea original de John Wensley y se basó en el uso de múltiples computadoras de propósito general que se comunicarían mediante mensajes por pares para alcanzar un consenso, incluso si algunas de ellas presentaban fallas.

Al inicio del proyecto, no estaba claro cuántos ordenadores se necesitaban en total 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 necesitaba un mínimo de 3n + 1 y diseñó un protocolo de mensajería de dos rondas de 3n +1 que funcionaría para n =1. Su colega Marshall Pease generalizó el algoritmo para cualquier n > 0, demostrando que 3n + 1 es necesario y suficiente. Estos resultados, junto con una demostración posterior de Leslie Lamport sobre la suficiencia de 3n utilizando firmas digitales, se publicaron en el artículo fundamental " Reaching Agreement in the Presence of Faults" [ 6 ] . Los autores recibieron el Premio Edsger W. Dijkstra de 2005 por este artículo.

Para facilitar la comprensión del problema de la consistencia interactiva, 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ó, optando finalmente por « Bizantino », a sugerencia de Jack Goldberg para evitar posibles ofensas futuras. [ 7 ] Esta formulación del problema, junto con algunos resultados adicionales, fue presentada 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 protegerse contra fallos de los componentes del sistema, con o sin síntomas, que impidan que otros componentes del sistema lleguen a un acuerdo entre sí, cuando dicho acuerdo sea necesario para el correcto funcionamiento del sistema.

Los componentes que sigan funcionando correctamente en un sistema tolerante a fallos bizantinos podrán continuar prestando el servicio del sistema según lo previsto originalmente, siempre que haya un número suficiente de componentes que funcionen correctamente para mantener el servicio.

Al considerar la propagación de fallos únicamente a través de errores, los fallos bizantinos se consideran la clase de fallos más general y compleja entre los modos de fallo . El modo de fallo denominado "fail-stop" ocupa el extremo más simple del espectro. Mientras que este modo simplemente implica que la única forma de fallo es la caída de un nodo , detectada por otros nodos, los fallos bizantinos no implican restricciones sobre los errores que se pueden generar, lo que significa que un nodo que falla puede generar datos arbitrarios, incluyendo datos que lo hacen parecer un nodo funcional para 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 interferencia humana hostil: puede surgir simplemente de fallos físicos o de software.

Los términos fallo y error se utilizan aquí de acuerdo con las definiciones estándar [ 8 ] creadas originalmente por un comité conjunto sobre "Conceptos Fundamentales y Terminología" formado por el Comité Técnico de Computación Confiable y Tolerancia a Fallos de la IEEE Computer Society y el Grupo de Trabajo 10.4 de IFIP sobre Computación Confiable y Tolerancia a Fallos. [ 9 ] Véase también confiabilidad .

La tolerancia a fallos bizantinos se centra únicamente en la consistencia de la difusión, es decir, la propiedad de que cuando un componente difunde un valor a todos los demás, todos reciben exactamente ese mismo valor. En caso de que el emisor no sea consistente, los demás componentes acuerdan un valor común. Este tipo de tolerancia a fallos no abarca la corrección del valor en sí; por ejemplo, un componente malicioso que envía deliberadamente un valor incorrecto, pero que lo envía de forma consistente a todos los componentes, no será detectado por el esquema de tolerancia a fallos bizantinos.

Soluciones

Varias soluciones iniciales fueron descritas por Lamport, Shostak y Pease en 1982. [ 4 ] Comenzaron señalando que el Problema de los Generales puede reducirse a resolver 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 el Comandante ordenó en caso de que el Comandante sea leal:

  • Una solución contempla escenarios en los que los mensajes pueden ser falsificados, pero que serán tolerantes a fallos bizantinos siempre que el número de generales desleales sea inferior a un tercio del total. La imposibilidad de lidiar con un tercio o más de traidores se reduce, en última instancia, a demostrar que el problema de un comandante y dos tenientes no puede resolverse si el comandante es traidor. Para ver esto, supongamos que tenemos un comandante traidor A y dos tenientes, B y C: cuando A ordena a B atacar y a C retirarse, y B y C se envían mensajes entre sí, reenviando el mensaje de A, ni B ni C pueden determinar quién es el traidor, ya que no necesariamente es A; el otro teniente podría haber falsificado el mensaje supuestamente de A. Se puede demostrar que si n es el número total de generales y t es el número de traidores en ese n , entonces existen soluciones al problema solo cuando n > 3 t y la comunicación es síncrona (retardo limitado). [ 10 ] El conjunto completo de requisitos de BFT son: Para un número F de fallas bizantinas, se necesitan al menos 3 F +1 jugadores (zonas de contención de fallas), 2 F +1 rutas de comunicación independientes y F +1 rondas de comunicación. Pueden existir modelos de fallas híbridos en los que fallas benignas (no bizantinas) y fallas bizantinas pueden coexistir. Por cada falla benigna adicional que deba tolerarse, los números anteriores deben incrementarse en uno. Si no existen las rondas de comunicación de BFT, las fallas bizantinas pueden ocurrir incluso sin hardware defectuoso.
  • Una segunda solución requiere firmas de mensajes infalsificables. Las firmas digitales pueden proporcionar tolerancia a fallos bizantinos en presencia de un número arbitrario de generales traidores, siempre que n > F + 1 (de lo contrario, el problema se vuelve trivial). En particular, un comandante y dos tenientes pueden llegar a un consenso en presencia de un solo traidor, ya que este no puede suplantar la identidad de otros. Posteriormente se desarrollaron soluciones basadas en otras primitivas criptográficas, como los códigos de autenticación de mensajes (MAC) [ 11 ] .
  • También se presenta una variación de las dos primeras soluciones que permite un comportamiento tolerante a fallos bizantinos en algunas situaciones en las que no todos los generales pueden comunicarse directamente entre sí. [ 1 ]

Existen muchos sistemas que afirman cumplir con los requisitos mínimos mencionados anteriormente (por ejemplo, blockchain). Dado que existen pruebas matemáticas de que esto es imposible, dichas afirmaciones deben incluir una advertencia: su definición de BFT se desvía de la original. Es decir, sistemas como blockchain no garantizan el acuerdo. Utilizan mecanismos que consumen muchos recursos, lo que dificulta la gestión de los desacuerdos.

Se diseñaron varias arquitecturas de sistemas alrededor de 1980 que implementaban tolerancia a fallos bizantinos. Estas incluyen: FTMP de Draper, [ 12 ] MMFCS de Honeywell, [ 13 ] y SIFT de SRI. [ 5 ]

En 1999, Miguel Castro y Barbara Liskov introdujeron el algoritmo "Tolerancia práctica a fallos bizantinos" (PBFT) [ 11 ] , que proporciona replicación de máquinas de estado bizantinos de alto rendimiento , procesando miles de solicitudes por segundo con incrementos de latencia de submilisegundos.

Después de PBFT, se introdujeron varios protocolos BFT para mejorar su robustez y rendimiento. Por ejemplo, Q/U, [ 14 ] HQ, [ 15 ] Zyzzyva, [ 16 ] y ABsTRACTs, [ 17 ] abordaron los problemas de rendimiento y costo; mientras que otros protocolos, como Aardvark [ 18 ] y RBFT, [ 19 ] abordaron sus problemas de robustez. Además, Adapt [ 20 ] intentó utilizar protocolos BFT existentes, alternando entre ellos de forma 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 componentes confiables para reducir el número de réplicas, por ejemplo, A2M-PBFT-EA [ 21 ] y MinBFT. [ 22 ]

Investigaciones recientes abordan los límites de escalabilidad de las implementaciones tradicionales de BFT (que a menudo incurrenO(norte2){\displaystyle O(n^{2})}complejidad de la comunicación ) mediante la paralelización del consenso. Por ejemplo, el protocolo Cerberus asigna datos a un espacio de estados fijo y amplio para acoplar instancias de consenso con conjuntos de transacciones específicos. Esto permite que los procesos BFT se ejecuten de forma independiente en paralelo, lo que posibilita una escalabilidad lineal en relación con el tamaño de la red. [ 23 ]

Aplicaciones

En dos artículos de revistas equivalentes se dan varios ejemplos de fallos bizantinos que han ocurrido. [ 2 ] [ 3 ] Estos y otros ejemplos se describen en las páginas web de NASA DASHlink. [ 24 ]

Aplicaciones en informática

Los mecanismos de tolerancia a fallos bizantinos utilizan componentes que repiten un mensaje entrante (o simplemente su firma, que puede reducirse a un solo bit de información si se utilizan pares de autocomprobación para los nodos) a otros receptores de dicho mensaje. Todos estos mecanismos parten del supuesto de que la repetición de un mensaje bloquea la propagación de síntomas bizantinos. Para sistemas con un alto grado de criticidad en materia de seguridad, estos supuestos deben demostrarse con un nivel aceptable de cobertura de fallos . Al proporcionar pruebas, una dificultad reside en generar un rango suficientemente amplio de señales con síntomas bizantinos. [ 25 ] Es probable que dichas pruebas requieran inyectores de fallos especializados . [ 26 ] [ 27 ]

Aplicaciones militares

Se observaron errores bizantinos de forma infrecuente y en puntos irregulares durante las pruebas de resistencia del submarino de nueva construcción de la clase Virginia , al menos hasta 2005 (cuando se hicieron públicos los problemas). [ 28 ]

Aplicaciones de criptomonedas

La red Bitcoin funciona en paralelo para generar una cadena de bloques con prueba de trabajo, lo que permite al sistema superar fallos bizantinos y alcanzar una visión global coherente del estado del sistema. [ 29 ] [ 30 ] Algunas cadenas de bloques de prueba de participación también utilizan algoritmos BFT. [ 31 ]

Blockchain

La tolerancia a fallos bizantinos es un concepto crucial en la tecnología blockchain , ya que garantiza que una red pueda seguir funcionando incluso cuando algunos nodos [ 32 ] (participantes) fallan o actúan de forma maliciosa. Esta tolerancia es necesaria porque las blockchains son sistemas descentralizados sin autoridad central, lo que hace esencial lograr el consenso entre los nodos, incluso si algunos intentan interrumpir el proceso.

Inteligencia artificial

Garantizar que un sistema de IA se comporte de forma fiable y según lo previsto, especialmente ante fallos inesperados o condiciones adversas, es un desafío complejo. Al aceptar que los componentes pueden fallar, y además que los modelos de IA de vanguardia pueden engañar, se ha propuesto la tolerancia a fallos bizantinos como un enfoque para la seguridad de la IA . [ 33 ] Estructurar los sistemas de IA como conjuntos de artefactos o módulos de IA que se controlan y equilibran entre sí proporciona sólidas garantías de que ningún componente erróneo o engañoso pueda fácilmente llevar al sistema a un estado inseguro.

Aplicaciones y ejemplos

Mecanismos de seguridad
Las distintas cadenas de bloques utilizan diversos mecanismos de consenso basados ​​en la tolerancia a fallos bizantinos (BFT, por sus siglas en inglés), como la Tolerancia Práctica a Fallos Bizantinos (PBFT), Tendermint y la Prueba de Participación Delegada (DPoS, por sus siglas en inglés), para gestionar los fallos bizantinos. Estos protocolos garantizan que la mayoría de los nodos honestos puedan ponerse de acuerdo sobre el siguiente bloque de la cadena, protegiendo así la red contra ataques y previniendo el doble gasto y otros tipos de fraude. Algunos ejemplos prácticos de redes son Hyperledger Fabric , Cosmos y Klever, en este orden.
51% de mitigación de ataques
Mientras que las cadenas de bloques tradicionales como Bitcoin utilizan la 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 para superar en número y maniobrar contra los nodos maliciosos.
Cadenas de bloques privadas y con permisos
BFT es especialmente importante en cadenas de bloques privadas o con permisos, donde un número limitado de participantes conocidos necesita alcanzar un consenso de forma rápida y segura. Estas redes suelen utilizar protocolos BFT para mejorar el rendimiento y la seguridad.

En aviación

Algunos sistemas de aeronaves, como el Sistema de Gestión de Información de Aeronaves del Boeing 777 (a través de su red SAFEbus ARINC 659), el sistema de control de vuelo del Boeing 777 y los sistemas de control de vuelo del Boeing 787, utilizan tolerancia a fallos bizantinos; dado que se trata de sistemas en tiempo real, sus soluciones de tolerancia a fallos bizantinos deben tener una latencia muy baja. Por ejemplo, SAFEbus puede lograr la tolerancia a fallos bizantinos con una latencia añadida del orden de un microsegundo. [ 34 ] [ 35 ] [ 36 ]

En los sistemas espaciales

El SpaceX Dragon considera la tolerancia a fallas bizantinas en su diseño. [ 37 ] La aviónica del cohete Ares , ahora el Sistema de Lanzamiento Espacial (SLS), utiliza un triplex con una etapa intermedia para lograr la resiliencia bizantina. [ 38 ] [ 39 ] La nave espacial Orion utiliza pares de autocomprobación para detectar y enmascarar fallas bizantinas. [ 40 ]

En la democracia y las sociedades civiles

En las legislaturas , las organizaciones de la sociedad civil , las encuestas , los estudios estadísticos , etc., los sistemas que requieren un umbral mínimo de mayoría cualificada superior a dos tercios se asemejan al consenso, reflejando características similares a la tolerancia a fallos bizantinos. Por el contrario, los sistemas que operan sobre la base de mayorías menores o gobiernos minoritarios podrían ser vulnerables a un comportamiento similar al de la tolerancia a fallos bizantinos.

Véase también

Referencias

  1. 1 2 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) del original el 13 de junio de 2018.  
  2. 1 2 3 Driscoll, K.; Hall, B.; Paulitsch, M.; Zumsteg, P.; Sivencrona, H. (2004). "Los verdaderos generales bizantinos". XXIII 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. 1 2 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 . Notas de clase en ciencias de la computación. 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. 1 2 3 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 del original (PDF) el 7 de febrero de 2017.  
  5. 1 2 "SIFT: diseño y análisis de una computadora tolerante a fallas para el 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). "Alcanzando un acuerdo en presencia de fallos". Journal of the Association for Computing Machinery . 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 confiable y segura". IEEE Transactions on Dependable and Secure Computing . 1 (1): 11– 33. Bibcode : 2004ITDSC...1...11A . doi : 10.1109/TDSC.2004.2 . hdl : 1903/6459 . ISSN 1545-5971 . S2CID 215753451 .  
  9. ↑ "Computación confiable y tolerancia a fallas" . IEEE Computer Society. Archivado del 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 síncrono" (PDF) . SIAM Journal on Computing . 26 (4): 873– 933. doi : 10.1137/s0097539790187084 . Archivado (PDF) del original el 5 de marzo de 2016. Recuperado el 14 de junio de 2012 .
  11. 1 2 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 .  
  12. ↑ 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-1985". 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-6ISSN 0932-5581​​ 
  13. ↑ Driscoll, Kevin; Papadopoulos, Gregory; Nelson, Scott; Hartmann, Gary; Ramohalli, Gautham (1984), Sistema de control de vuelo multimicroprocesador (Informe técnico), Base de la Fuerza Aérea Wright-Patterson, Ohio: AFWAL/FIGL Comando de Sistemas de la Fuerza Aérea de EE. UU., AFWAL-TR-84-3076
  14. ↑ Abd-El-Malek, M.; Ganger, G.; Goodson, G.; Reiter, M.; Wylie, J. (2005). "Servicios tolerantes a fallos bizantinos escalables". ACM SIGOPS Operating Systems Review . 39 (5). Association for Computing Machinery : 59. doi : 10.1145/1095809.1095817 .
  15. ↑ Cowling, James; Myers, Daniel; Liskov, Barbara ; Rodrigues, Rodrigo; Shrira, Liuba (2006). HQ Replication: A Hybrid Quorum Protocol for Byzantine Fault Tolerance . Actas del 7.º Simposio USENIX sobre Diseño e Implementación de Sistemas Operativos. págs. 177–190 . ISBN  1-931971-47-1.
  16. ↑ 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 .
  17. ↑ 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 del original el 2 de octubre de 2011. Consultado el 4 de octubre de 2011 .
  18. ↑ Clement, A.; Wong, E.; Alvisi, L.; Dahlin, M.; Marchetti, M. (22–24 de abril de 2009). Cómo lograr que los sistemas tolerantes a fallos bizantinos toleren fallos bizantinos (PDF) . Simposio sobre diseño e implementación de sistemas en red. USENIX . Archivado (PDF) del original el 25 de diciembre de 2010. Consultado el 17 de febrero de 2010 .
  19. ↑ 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 de Computación Distribuida. Conferencia Internacional sobre Sistemas de Computación Distribuida . Archivado del original el 5 de agosto de 2013.
  20. ↑ Bahsoun, JP; Guerraoui, R.; Shoker, A. (1 de mayo de 2015). "Haciendo que los protocolos BFT sean realmente adaptativos" . Simposio Internacional de Procesamiento Paralelo y Distribuido IEEE 2015. págs. 904–913 . doi : 10.1109/IPDPS.2015.21 . ISBN  978-1-4799-8649-1. S2CID 16310807 . 
  21. ↑ Chun, Byung-Gon; Maniatis, Petros; Shenker, Scott; Kubiatowicz, John (1 de enero de 2007). "Memoria de solo escritura atestiguada". Actas del vigésimo primer simposio ACM SIGOPS sobre principios de sistemas operativos . SOSP '07. Ciudad de Nueva York: ACM. págs. 189–204 . doi : 10.1145/1294261.1294280 . ISBN  9781595935915. S2CID 6685352 . 
  22. ↑ Veronese, GS; Correia, M.; Bessani, AN; Lung, LC; Verissimo, P. (2013-01-01). "Tolerancia eficiente a fallos bizantinos". IEEE Transactions on Computers . 62 (1): 16– 30. Bibcode : 2013ITCmp..62...16V . CiteSeerX 10.1.1.408.9972 . doi : 10.1109/TC.2011.221 . ISSN 0018-9340 . S2CID 8157723 .   
  23. ↑ Hellings, Jelle; Sadoghi, Mohammad (2021). "ByShard: sharding in a byzantine environment" (PDF) . Proceedings of the VLDB Endowment . 14 (11): 2230– 2243. doi : 10.14778/3476249.3476275 .
  24. ↑ Driscoll, Kevin (11 de diciembre de 2012). "Fallos reales del sistema" . DASHlink . NASA . Archivado del original el 2 de abril de 2015. Recuperado el 2 de marzo de 2015 .
  25. ↑ Nanya, T.; Goosen, HA (1989). "El modelo de fallas de hardware bizantinas". IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems . 8 (11): 1226– 1231. Bibcode : 1989ITCAD...8.1226N . doi : 10.1109/43.41508 . ISSN 0278-0070 . 
  26. ^ 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 .  
  27. ↑ 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. 
  28. ↑ Walter, C.; Ellis, P.; LaValley, B. (2005). «The Reliable Platform Service: A Property-Based Fault Tolerant Service Architecture». Noveno Simposio Internacional IEEE sobre Ingeniería de Sistemas de Alta Confiabilidad (HASE'05) . págs. 34–43 . doi : 10.1109/HASE.2005.23 . ISBN  978-0-7695-2377-4. S2CID 21468069 . 
  29. ↑ Rubby, Matt (20 de enero de 2024). "Cómo el problema de los generales bizantinos se relaciona con usted en 2024" . Swan Bitcoin . Recuperado el 27 de enero de 2024 .
  30. ↑ Tholoniat, Pierre; Gramoli, Vincent (2022), "Verificación formal de la tolerancia a fallos bizantinos de blockchain" , en Tran, Duc A.; Thai, My T.; Krishnamachari, Bhaskar (eds.), Manual sobre blockchain , Springer Optimization and Its Applications, Cham: Springer, pp. 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
  31. ↑ Deirmentzoglou, Papakyriakopoulos y Patsakis 2019 , p. 28716.
  32. ↑ "Operaciones de nodo" .
  33. ↑ deVadoss, John (2025). "Un enfoque de tolerancia a fallos bizantinos para la seguridad de la IA". arXiv : 2504.14668 [ cs.DC ].
  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 (2.ª ed.). CRC Press. págs. 48-1-48-26. ISBN   978-1-4822-0733-0.
  35. ↑ Rushby, John (26 de septiembre de 2001). Henzinger, Thomas A.; Kirsch, Christoph M. (eds.). Arquitecturas de bus para sistemas embebidos críticos para la seguridad (PDF) . Software embebido: Primer taller internacional, 8-10 de octubre de 2001. Tahoe City, California: Springer Science & Business Media. págs. 307–. ISBN  978-3-540-42673-8. Archivado (PDF) del original el 22-09-2015 . Recuperado el 05-03-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 de Sistemas de Aviónica Digital (Cat. n.º 01CH37219). Vol. 1. pp. 1C2/1–1C2/11. doi : 10.1109/DASC.2001.963311 . ISBN   978-0-7803-7034-0. S2CID 61489128 . 
  37. ↑ "ELC: Lecciones aprendidas de SpaceX" . LWN . Archivado del original el 5 de agosto de 2016. Consultado el 21 de julio de 2016 .
  38. ↑ "Sistema de Lanzamiento Espacial (SLS): Aviónica: El "cerebro" del SLS" (PDF) . nasa.gov . MSFS-12-2024-SLS-4964.
  39. ↑ Loveless, Andrew (7 de noviembre de 2016). "Arquitectura de votación 1FT nocional con Ethernet activada por tiempo" (PDF) . nasa.gov .
  40. ↑ Baggerman, Clint (2 de agosto de 2013). "Arquitectura del sistema de aviónica para el vehículo Orion de la NASA" . ntrs.nasa.gov .

Fuentes

  • Deirmentzoglou, Evangelos; Papakyriakopoulos, Georgios; Patsakis, Constantinos (2019). "Un estudio 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 en Blockchain". Blockchain Consensus - Una introducción a los protocolos de consenso clásicos, de blockchain y cuánticos . ISBN 978-1-4842-8178-9Apress, Berkeley, CA, 2022. doi : 10.1007/978-1-4842-8179-6
  • Tolerancia a fallos bizantinos en RKBExplorer
Lecturas relacionadas
6 articulos
Computación distribuidaComputación distribuidaLa computación distribuida es un campo de la informática que estudia los sistemas distribuidos , definidos como sistemas informáticos cuyos compone...AlegoríaAlegoríaComo recurso literario o forma artística, una alegoría es una representación narrativa o visual en la que un personaje, lugar o acontecimiento pued...Tolerancia a fallosTolerancia a fallosLa tolerancia a fallos es la capacidad de un sistema para contener la propagación de fallos (por ejemplo, un transistor averiado, un conector en co...{\estilo de visualización v}Consenso (informática)Un problema fundamental en la computación distribuida y los sistemas multiagente es lograr la confiabilidad general del sistema en presencia de una...DerrotaDerrotaUna derrota / r aʊ t / es una retirada de tropas en pánico , desordenada e indisciplinada de un campo de batalla, después de un colapso en la autor...Variable no inicializadaVariable no inicializadaEn informática , una variable no inicializada es una variable que se declara pero no se le asigna un valor conocido definido antes de su uso. Tendr...