Académique Documents
Professionnel Documents
Culture Documents
INSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
Salvador
2008
Murilo Santos de Lima
Salvador
2008
“Eu te louvarei, porque de um modo terrível, e tão maravilhoso fui formado;
maravilhosas são as tuas obras, e a minha alma o sabe muito bem.” Salmo 139:14
AGRADECIMENTOS
Ao Deus eterno e triuno, por sua presença e operação constante em minha vida. Em especial
por ter preparado momento tão oportuno para me apresentar Seu projeto de vida. O mérito deste
trabalho (e de toda a minha existência) é dEle, não meu. A Ele atribuo todas as vitórias que
tenho conquistado em todos os aspectos, em especial as mais recentes, principalmente a alegria
que goza meu coração e que todas as riquezas, glórias e conhecimento deste mundo passageiro
não podem proporcionar. A Ele seja toda a glória, honra e poder para todo o sempre.
À minha mãe Maria, por todo seu amor e dedicação, pelos valores que me instruiu e pela
conscientização desde cedo sobre a responsabilidade das minhas decisões e atitudes. Esta vitó-
ria com certeza também é dela. À minha irmã Malu e a seu esposo Thiago pelo apoio, e às suas
filhas Júlia e Lara pela alegria que me têm proporcionado. Aos meus avós Euzébio e Hilda, pelo
carinho. A meu pai Wilson, com quem pude retomar o convívio neste período, pelos poucos
mas valiosos conselhos. À prima Daniela, que foi canal de tal encontro com uma família que
me recebeu tão carinhosamente.
Aos irmãos da Igreja Cristã Maranata e do corpo de Cristo como um todo, mas em especial
da ICM da Pituba, pelo suporte. Sua companhia foi indispensável neste período. Menciono em
especial os nomes de Taíse Campos, Ilton Serafim e pastor Koji, pelos conselhos nos momentos
difíceis. Àqueles que oraram por mim, por esta vitória, mas principalmente para que meus pés
não resvalassem.
Aos sete colegas que me acompanharam mais de perto, denominados “iluminados”: Isa-
que, Ruth, Hugo, José Souza, José Augusto, Waltemir e Antonio Marcos. A Lorena, Jerônimo,
Daniel Couto, André Pacheco, André Fonseca, Caio Tiago e Alexandre “top” pela companhia e
pelas conversas jogadas fora. A veteranos como Amadeu, Charles e Orivaldo, que me mostra-
ram o lado humano dessa profissão de maluco.
Àqueles que conviveram comigo em um dos sete locais diferentes onde morei neste período;
em especial a Andréia Mendes, Iuri Castro, Rafael Chepote e Sílvia Letícia, pela amizade.
Àqueles cujos nomes não foram citados, mas que fazem parte da minha vida, ficam a grati-
dão e as desculpas por minhas limitações de memória.
Fault-tolerant protocols are a fundamental part of the reliable distributed systems project.
In a dynamic distributed system, in which nodes may join and leave the network randomly, at
any moment of the system execution, these services are even harder to provide. Moreover, due
to the large participant scale and the common use of wireless communication, it is not possible
to provide the processes with a global view of the network topology, so that each node only has
a partial knowledge of the system composition.
A specially alarming factor is the security, as the dynamism of the node population furthers
the action of malicious agents over the system. The Byzantine failure model tries to deal with
such insecurity by supposing the existence of corrupted processes, which may behave in an
arbitrary manner, trying to hinder the system to work accordingly to its specification. The
system tolerates those faults if, despite the malicious behavior of some of its processes, it keeps
a correct functioning.
The failure detector abstraction proposed by Chandra and Toueg provides a modular ap-
proach to deal with failures on asynchronous systems, separating such task from the distributed
protocol that uses it. Recent work has proposed the failure detection implementation on dyna-
mic distributed systems, though the occurrence of Byzantine failures is not dealt with. In this
work, we present an asynchronous Byzantine failure detector for dynamic distributed systems.
It is based on the asynchronous detector proposed by Sens et al. and on the Byzantine failure
detection approach described by Kihlstrom et al..
Keywords: failure detectors, Byzantine failures, dynamic distributed systems, self-organizing
systems, asynchronous failure detectors.
LISTA DE SÍMBOLOS
5.9 Processo corrupto que envia mensagens com valores diferentes para processos
diferentes (supor x 6= y, y 6= z ou x 6= z) . . . . . . . . . . . . . . . . . . . . . . 48
1 Introdução 14
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Problema do Consenso 26
3.1 Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Conclusão 59
Referências Bibliográficas 61
14
1 INTRODUÇÃO
É cada vez maior nos dias atuais a demanda por aplicações com requisitos de alta dispo-
nibilidade e confiabilidade. Em aplicações críticas, como no controle de transações bancárias,
uma operação incorreta pode levar a prejuízos financeiros enormes. Uma vez que é impossí-
vel construir sistemas computacionais que nunca falhem (VERISSIMO; RODRIGUES, 2001),
tais requisitos só podem ser atendidos pelo uso de redundância e de distribuição, seja física ou
lógica, dos recursos computacionais (SCHNEIDER, 1993a). Se um componente falhar, uma
réplica assume seu lugar, de forma que o sistema como um todo continua sua operação normal.
Uma etapa fundamental desse processo é o desenvolvimento de protocolos tolerantes a faltas
(GREVE, 2005), necessários para coordenar as ações dos diversos componentes do sistema.
o sistema funcione conforme a sua especificação. Um processo bizantino pode, por exemplo,
tentar assumir a identidade de outro, enviar mensagens com valores incorretos, duplicar men-
sagens ou simplesmente não enviar mensagens que o protocolo especificar. O desenvolvimento
de sistemas tolerantes a faltas bizantinas, isto é, que mantenham o seu funcionamento correto
apesar do comportamento maligno de alguns de seus processos, é portanto de especial interesse.
Este trabalho apresenta então um detector assíncrono de falhas bizantinas para sistemas dis-
tribuídos dinâmicos. O protocolo proposto baseia-se no detector assíncrono para sistemas com
participantes desconhecidos de Sens et al. (SENS et al., 2008). O tratamento das falhas bizan-
tinas segue a abordagem descrita por (KIHLSTROM; MOSER; MELLIAR-SMITH, 2003).
1.1 OBJETIVO
Detectores de falhas que lidem com questões inerentes a sistemas dinâmicos incluem (GUPTA;
CHANDRA; GOLDSZMIDT, 2001; FRIEDMAN; TCHARNY, 2005), o primeiro tratando de
populações de nós dinâmicas, o segundo de mobilidade nos nós. Ambos utilizam o mecanismo
de temporização para detecção das falhas. (MOSTEFAOUI; MOURGAYA; RAYNAL, 2003)
apresenta detectores de falhas assíncronos, no entanto para redes com composição conhecida e
estática. Em (SENS et al., 2008) propõe-se, então, a implementação assíncrona de um detector
de falhas que trata tanto a dinamicidade da composição da rede quanto a mobilidade dos nós,
sendo utilizado como base para o desenvolvimento deste trabalho.
2 MODELOS DE SISTEMAS
DISTRIBUÍDOS
Define-se, por conseguinte, falha como o desvio do sistema como um todo de sua especifi-
cação. A causa original das falhas é denominada falta, que no entanto pode passar desaperce-
bida até que um erro ocorra. Caso o erro reflita em um comportamento incorreto que possa ser
percebido pelo usuário, o sistema apresentou uma falha. Em sistemas formados por diversos
componentes, a falha de um componente pode ser vista como uma falta no sistema, levando a
uma aplicação recursiva das definições apresentadas. Adota-se neste trabalho a tradução falta
para fault, erro para error e falha para failure. Alguns autores, no entanto, traduzem fault como
falha e failure como defeito (COULOURIS; DOLLIMORE; KINDBERG, 2007).
18
Existem diversos problemas que não podem ser resolvidos em sistemas assíncronos, como
por exemplo o problema do consenso (ver Capítulo 3). Para contornar tal limitação sem apelar
para o uso de suposições fortes de sincronia, foram propostos modelos de sincronia parcial
(DWORK; LYNCH; STOCKMEYER, 1988). Nesse tipo de sistema, existem limites no tempo
de processamento e nas transmissões das mensagens, mas os mesmos não são conhecidos. O
sistema pode ainda passar por períodos de instabilidade, isto é, períodos em que os limites tem-
porais não são respeitados, desde que em algum momento no futuro apresente comportamento
19
Os tipos de falhas que um processo em um sistema distribuído pode cometer são (HADZI-
LACOS; TOUEG, 1993; SCHNEIDER, 1993a):
• Parada (failstop): quando um processo p falha ele pára; os demais processos têm conhe-
cimento de que p falhou. Na prática este modelo é pouco utilizado, uma vez que só pode
ser implementado em um sistema completamente síncrono (SCHNEIDER, 1993a).
20
• Colapso (crash): quando um processo p falha ele pára; os demais processos não têm
conhecimento de que p falhou.
• Omissão na recepção: um processo pode falhar por colapso ou por não receber mensa-
gens que lhe foram enviadas.
• Omissão no envio: um processo pode falhar por colapso ou por não enviar mensagens
que supostamente deveria. Isto é, a especificação do algoritmo determina que o processo
deveria enviar uma mensagem, mas ele falha por não enviá-la.
• Omissão temporal: (aplicável apenas a sistemas síncronos) um processo falha por não
executar sua tarefa dentro do limite de tempo especificado.
Evidencia-se uma hierarquia de “gravidade” das falhas, de forma que uma classe de falhas
A é mais grave que outra B se o conjunto de comportamentos faltosos permitidos em B é um
subconjunto próprio daqueles permitidos por A. Neste caso, um algoritmo que tolere falhas do
tipo A também tolerará falhas do tipo B (HADZILACOS; TOUEG, 1993). Observa-se ainda
transitividade nessa relação de gravidade. Na Figura 2.1, mostra-se tal hierarquia entre as clas-
ses de falhas descritas como um grafo direcionado, no qual uma aresta saindo de A para B indica
que A é menos grave que B. A classe das falhas bizantinas é, portanto, a mais grave, de forma
que um algoritmo tolerante a faltas bizantinas tolera qualquer tipo de falta. A figura eviden-
cia ainda a noção de falhas benignas, que incluem todas as classes nas quais não se apresenta
comportamento arbitrário.
Figura 2.1: Hierarquia de gravidade das classes de falhas de processos (adaptado de (HADZI-
LACOS; TOUEG, 1993))
• Colapso (crash): o canal pára de funcionar, não transmitindo mais mensagens que lhe
são submetidas.
• Omissão: o canal não entrega parte das mensagens que lhe são submetidas.
tema. Neste trabalho, para efeito de simplicidade dos algoritmos propostos, adota-se o modelo
de canais confiáveis. Outros modelos incluem canais com perda de mensagens e canais expirá-
veis (AGUILERA et al., 2001).
• Não perda: se p envia m a q então q recebe m de p em algum momento futuro, desde que
q não falhe.
O modelo de falhas bizantinas supõe que os processos podem falhar de maneira arbitrária,
inclusive maliciosa. Tal suposição na prática é bastante realista, tendo em vista os problemas
de segurança enfrentados em sistemas distribuídos e redes de computadores em geral. Situa-
ções que podem levar os processos a se comportarem de maneira arbitrária incluem a ação de
invasores, a corrupção de um programa por um cavalo de Tróia ou ainda situações não intencio-
nais, como erros na programação do software e interferências físicas no hardware, comuns por
exemplo em aplicações espaciais (KIHLSTROM; MOSER; MELLIAR-SMITH, 2003).
• Cada mensagem correta enviada é entregue corretamente. Isto leva à suposição de canais
confiáveis (ver Seção 2.2.2) ou de uma camada de roteamento seguro.
• A ausência de uma mensagem pode ser detectada pelos processos corretos. Em sistemas
parcialmente síncronos, tal serviço não é fácil de implementar, sendo na verdade abordado
adiante como um dos tipos de falhas que devem ser tratadas quando se deseja lidar com
falhas bizantinas.
No trabalho de Lamport et al., evidenciam-se duas formas de lidar com a presença de pro-
cessos maliciosos: a redundância da informação e o uso de assinaturas digitais não-forjáveis.
Ambas buscam prover aos processos corretos uma visão coerente das mensagens enviadas por
cada processo Estas técnicas, no entanto, não garantem que as mensagens enviadas pelos pro-
cessos faltosos sejam consistentes com os requisitos do algoritmo sendo executado. Uma forma
de lidar com tal situação é a adição de informação adicional às mensagens, na forma de certi-
ficados, que possam ser utilizados para validar o conteúdo sendo transmitido (KIHLSTROM;
MOSER; MELLIAR-SMITH, 2003).
A seguir apresenta-se uma caracterização dos tipos de falhas bizantinas que podem ocorrer,
descrita em (KIHLSTROM; MOSER; MELLIAR-SMITH, 2003). Outras abordagens neste
sentido incluem (BALDONI et al., 1999).
As falhas detectáveis são classificadas em falhas por omissão e por comissão, sendo análo-
gas às falhas de progresso e segurança definidas em (BALDONI; HÉLARY; PIERGIOVANNI,
2007), respectivamente. Falhas de progresso atrapalham a terminação da computação, uma vez
que o processo faltoso não envia mensagens requeridas por sua especificação ou as envia a ape-
nas parte dos processos do sistema, enquanto que as falhas de segurança violam propriedades
invariantes às quais os processos devem atender. Falhas por comissão podem ser definidas como
o não-cumprimento de uma das seguintes restrições:
• Um processo deve enviar as mesmas mensagens para todos os outros. Um processo fal-
24
toso poderia, portanto, enviar a mesma mensagem com valores distintos para processos
distintos.
3. Conectividade parcial, isto é, cada nó está conectado diretamente a apenas parte da po-
pulação dos nós. Em uma rede sem fio, por exemplo, cada nó só se comunica diretamente
com os nós dentro do seu alcance de transmissão. A suposição de uma rede comple-
tamente conectada, comum na abordagem clássica de sistemas distribuídos, não é mais
adequada;
4. Mobilidade dos nós: os nós podem alterar sua localização, sem entretanto modificar sua
identidade ou estado interno, levando a mudanças na topologia da rede.
Algoritmos projetados para ambientes clássicos, que supõem uma rede com topologia es-
tática e conhecida, não são mais adequados nesta nova abordagem. São necessárias, portanto,
adaptações que levem em consideração as propriedades acima levantadas.
3 PROBLEMA DO CONSENSO
3.1 DEFINIÇÃO
A definição clássica do problema para um modelo de falhas benignas pode ser especificada
formalmente através das seguintes propriedades1 (GREVE, 2005; MARTIN; ALVISI, 2006):
1Aterminologia e a definição destas propriedades varia na literatura. Ver, por exemplo, a definição em (HAD-
ZILACOS; TOUEG, 1993), na qual a propriedade de Validade, por exemplo, mistura aspectos da propriedade de
Terminação.
27
• Terminação: em algum momento no futuro, todo processo correto decide por um valor
v ∈ V;
• Irrevogabilidade: uma vez que um processo tenha decido por um valor v, sua decisão não
poderá ser alterada;
• Validade: se algum processo correto decide por um valor v, então v foi proposto por
algum processo p ∈ Π.
Algumas definições permitem ainda que um processo correto decida por um valor v = ⊥ ∈
/V
(HADZILACOS; TOUEG, 1993), indicando que não houve consenso entre os processos.
Trata-se da variante do consenso num cenário em que os processos estão sujeitos a falhas
bizantinas. Nessa situação, adota-se a convenção de que, se p é um processo faltoso, “p propõe
v” é um predicado verdadeiro, qualquer que seja v ∈ V (HADZILACOS; TOUEG, 1993). De
outra forma, a propriedade de Validade definida anteriormente não faria sentido, uma vez que
um processo malicioso pode propor valores diferentes para processos diferentes.
Estas propriedades especificam que os processos faltosos também devem atender a restri-
ções de segurança (safety). Assim, em alguns cenários, como em (CAVIN; SASSON; SCHI-
PER, 2005), pode-se resolver o consenso, mas não o consenso uniforme. O mesmo se aplica a
um contexto bizantino, já que, uma vez que os processos falham de maneira arbitrária (inclu-
sive maliciosamente), é impossível prover qualquer garantia a respeito do comportamento dos
processos faltosos.
No consenso vetorial, os processos decidem sobre um vetor de n valores com pelo menos
f + 1 entradas provenientes de processos corretos. Essa variante é utilizada especificamente no
29
modelo bizantino, por permitir que os processos avaliem a relevância de cada entrada do vetor.
Outra vantagem em relação ao consenso forte é que alguns problemas de acordo, como a difusão
atômica, podem ser reduzidos ao consenso vetorial, mas não ao consenso forte (BALDONI et
al., 1999).
do oráculo de detecção. Detectores de falhas são o foco deste trabalho, sendo abordados
em maior detalhe no Capítulo 4.
Modelo de Canais e
Falhas versus Canais Processos Processos
Sincronia Síncrono Assíncrono Parcialmente Parcialmente Parcialmente
do Sistema Síncronos Síncronos Síncronos
Parada ou f ∞ 2f +1 2f +1 f
Colapso
Omissão f ∞ 2f +1 2f +1 2f +1
Bizantino com f ∞ 3f +1 3f +1 2f +1
Autenticação
Bizantino 3f +1 ∞ 3f +1 3f +1 3f +1
Tabela 3.1: Número mínimo de processos necessários para resolver consenso em sistemas está-
ticos tolerando f processos faltosos (DWORK; LYNCH; STOCKMEYER, 1988)
Tabela 3.2: Condições para realização do consenso em sistemas com participantes desconheci-
dos (ALCHIERI et al., 2008) (adaptada)
A versão tolerante a faltas do CUP (denominada FT-CUP, de fault-tolerant CUP - CUP tole-
rante a faltas) foi apresentada inicialmente em (CAVIN; SASSON; SCHIPER, 2005). Verificou-
se que se apenas a condição de conectividade mínima for satisfeita, é necessário enriquecer o
32
sistema com um detector perfeito (da classe P), que não comete erros e só pode ser implemen-
tado em um sistema completamente síncrono (ver Seção 4.1). Além disso, sob tais condições
não é possível resolver o consenso uniforme (ver Seção 3.1.2). Entretanto, qualquer número de
faltas é tolerado, desde que o grafo de conhecimento remanescente permaneça redutível a um
único poço.
• Conectividade;
2 Um grafo G(V, E) é k-fortemente conexo se entre quaisquer dois vértices vi , v j ∈ V existem pelo menos k
caminhos de vi para v j disjuntos nos vértices.
33
4 DETECTORES DE FALHAS
NÃO-CONFIÁVEIS
Detectores de falhas (FD) não-confiáveis (CHANDRA; TOUEG, 1996) são oráculos dis-
tribuídos que fornecem “dicas” aos processos sobre a ocorrência de falhas no sistema. A cada
invocação, o FD retorna um conjunto com as identidades dos processos que suspeita de terem
falhado. O termo não-confiável refere-se ao fato de tais entidades poderem cometer erros, seja
por não detectar processos incorretos ou por suspeitar de processos corretos.
A garantia de determinadas propriedades sobre os erros que podem ser cometidos possibilita
a solução de diversos problemas, dentre eles o consenso. Os algoritmos de consenso que se
utilizam de tais abstrações são denominados indulgentes (GUERRAOUI; RAYNAL, 2004),
uma vez que os erros do detector de falhas não acarretam em desrespeito às propriedades de
segurança do consenso. Uma vez que a impossibilidade FLP diz respeito à incapacidade de
se distinguir, em um modelo de falhas por colapso, entre um processo faltoso e um processo
ou canal lento (GREVE, 2005), o uso de FDs simplifica o desenvolvimento de algoritmos de
consenso assíncronos. O detector de falhas isola o tratamento da detecção das falhas e das
necessidades de sincronia, provendo uma abstração ao algoritmo de tais requisitos.
4.1 DEFINIÇÃO
• Completude forte: existe um tempo após o qual todo processo correto suspeita perma-
34
• Completude fraca: existe um tempo após o qual algum processo correto suspeita perma-
nentemente de todo processo faltoso;
• Precisão forte após um tempo: em algum momento no futuro, todo processo correto
não será suspeito por qualquer processo;
• Precisão fraca após um tempo: em algum momento no futuro, um processo correto não
será suspeito por qualquer processo.
Precisão
Completude Forte Fraca Forte após um tempo Fraca após um tempo
Forte Perfeito Forte Perfeito Forte
(P) (S ) Após um Tempo Após um Tempo
(♦P) (♦S )
Fraca Quase-perfeito Fraco Quase-perfeito Fraco
(Q) (W ) Após um Tempo Após um Tempo
(♦Q) (♦W )
Tabela 4.1: Classes de detectores de falhas obtidas pela combinação das propriedades de com-
pletude e precisão (CHANDRA; TOUEG, 1996)
A classe de detectores de falhas P, que não comete erros, só pode ser implementada em um
sistema completamente síncrono. A classe ♦W , que provê completude fraca e precisão fraca
após um tempo consiste na classe mais fraca de detectores de falhas na qual é possível reali-
zar consenso num sistema com processos conhecidos (CHANDRA; HADZILACOS; TOUEG,
1996). Em (CHANDRA; TOUEG, 1996) mostra-se como resolver consenso utilizando detec-
tores de falhas das classes S e ♦S (completude forte e precisão fraca e fraca após um tempo,
respectivamente), desde que exista uma maioria de processos corretos no sistema. Mostra-se
também a equivalência entre as classes de detectores com completude forte e completude fraca.
Este trabalho terá seu foco nos detectores de falhas da classe ♦S , por serem, juntamente
com os da classe ♦W , aqueles que requerem a sincronia mínima necessária para resolver o
consenso assíncrono.
35
• Liderança após um tempo: Existe um tempo após o qual todo processo correto confia no
mesmo processo correto.
Dentre os trabalhos que propõem resolver consenso utilizando uma abstração de detecção
de líder como base, destaca-se o algoritmo Paxos de Lamport (LAMPORT, 1998). Outro tra-
balho neste sentido é (MOSTEFAOUI; RAYNAL, 2001). Além disso, pode-se também utilizar
detecção de líder para melhorar a eficiência da solução de um conjunto de tarefas distribuídas
(AGUILERA et al., 2001).
Num sistema sujeito a falhas bizantinas, não é possível detectar todos os tipos de falha que
podem ocorrer (ver Seção 2.2.3). Assim, a propriedade de completude forte é redefinida para o
modelo de falhas bizantinas como sendo (KIHLSTROM; MOSER; MELLIAR-SMITH, 2003):
Precisão
Completude para
o algoritmo A Forte após um tempo Fraca após um tempo
Forte bizantina Perfeito Após um Forte Após um
Tempo (♦P(Byz, A )) Tempo (♦S (Byz, A ))
(k + 1)-fraca bizantina Quase-perfeito Após Fraco Após um
um Tempo (♦Q(Byz, A )) Tempo (♦W (Byz, A ))
IMPLEMENTAÇÃO
Trabalhos que propõem detectores de falhas por colapso para populações dinâmicas e par-
cialmente conhecidas incluem (LARREA; FERNÁNDEZ; ARÉVALO, 2000; GUPTA; CHAN-
DRA; GOLDSZMIDT, 2001). Em (FRIEDMAN; TCHARNY, 2005) apresentam-se detectores
tolerantes à mobilidade dos nós. Todos estes baseiam-se, no entanto, no uso de temporizadores
(timeouts), o que não é adequado para redes com alta instabilidade, características de sistemas
dinâmicos (SENS et al., 2008).
O trabalho (SENS et al., 2008) destaca-se por propor uma implementação assíncrona de
detectores de falhas para populações dinâmicas. Utiliza-se, ao invés de mensagens do tipo “eu
estou vivo” temporizadas, um mecanismo de perguntas e respostas (query/response). Garante-
se que, se o sistema atender a determinadas propriedades comportamentais, as falhas dos pro-
cessos serão detectadas. Com pequenas alterações adicionais, mostra-se ser possível tolerar a
39
5 DETECTOR ASSÍNCRONO DE
FALHAS BIZANTINAS COM
PARTICIPANTES
DESCONHECIDOS
Cada processo é identificado unicamente e processos faltosos não podem obter mais de
um identificador, de forma que é impossível a ocorrência de ataques sybil (DOUCEUR, 2002).
Um ataque sybil consiste na obtenção por um processo malicioso de diversas identidades. Tal
41
Os processos trocam mensagens por difusão (broadcast) através de uma rede de comunica-
ção sem fio. Supõe-se a existência de canais confiáveis, de forma que as mensagens difundidas
são recebidas em algum momento no futuro por todos os processos dentro da área de cobertura
(range) do transmissor que não falharem. Na Figura 5.1, destaca-se a área de cobertura de dois
processos em uma rede de comunicação sem fio. Os canais são confiáveis, isto é, não dupli-
cam, alteram ou inserem novas mensagens e todo processo correto autentica suas mensagens de
forma incorruptível.
O sistema pode ser representado por um grafo não-direcionado G(V, E), sendo V = Π e
(pi , p j ) ∈ E se pi e p j encontram-se no range um do outro (pi e p j são denominados vizinhos).
A Figura 5.2 exibe uma possível representação da rede de comunicação da Figura 5.1 através
de um grafo.
Adotam-se neste trabalho as definições de range (ou área de cobertura de difusão), densi-
dade da área de cobertura e rede com f -cobertura propostas em (SENS et al., 2008):
Isto é, rangei consiste nos vizinhos de pi , além de pi . Note-se que |rangei | equivale ao grau
de pi em G mais 1 e que pi ∈ range j ⇔ p j ∈ rangei . Ou seja, a comunicação entre os processos
é simétrica.
42
Definição 3 (Rede com f -cobertura) Uma rede de comunicação representada pelo grafo G(V, E)
tem f -cobertura se e somente se G é ( f + 1)-conexo.
Definição 4 (Rede com f -cobertura bizantina) Uma rede de comunicação representada pelo
grafo G(V, E) tem f -cobertura bizantina se e somente se G é (2 f + 1)-conexo.
Exibe-se na Figura 5.3 o grafo de uma rede com f -cobertura bizantina, supondo f = 1.
Um grafo k-conexo possui k caminhos distintos nos vértices entre qualquer par de vértices
(BONDY; MURTY, 1976), o que leva à seguinte observação:
Observação 1 Em uma rede com f -cobertura bizantina, apesar da ocorrência de f < n falhas,
existirão pelo menos f + 1 caminhos distintos entre cada par de nós.
De forma similar ao apontado em (SENS et al., 2008), verifica-se que uma rede com f -
cobertura bizantina apresenta d > 2 f + 1 .
43
Em (SENS et al., 2008), obtém-se um protocolo assíncrono de detecção de falhas por co-
lapso por meio de um mecanismo de perguntas e respostas (mensagens do tipo QUERY / RE -
A cada rodada, um processo que não falhou envia uma mensagem QUERY a seus vizi-
nhos. Ao receber uma mensagem QUERY , confirma-se a recepção enviando uma mensagem
44
RESPONSE ao remetente. O processo que enviou a mensagem QUERY espera então receber
mensagens RESPONSE de pelo menos d − f processos, incluindo a si mesmo. A suposição de
uma rede com f -cobertura garante a recepção de um tal número de mensagens RESPONSE . O
processo que enviou a mensagem QUERY suspeita então dos nós que não enviaram uma men-
sagem RESPONSE (cada par QUERY - RESPONSE é identificado unicamente). Ao receber uma
mensagem QUERY com uma suspeita sobre si mesmo, um processo inclui um equívoco mais
recente que a suspeita em seu conjunto mistake. O mecanismo de QUERY / RESPONSE garante a
difusão das suspeitas e equívocos por toda a rede, de forma que o detector de falhas resultante
atende às propriedades de completude forte e precisão fraca após um tempo (classe ♦S ).
Além disso, para garantir a precisão forte após um tempo, um processo correto deve atender
à propriedade de receptividade, definida como:
Neste trabalho, de forma semelhante ao proposto em (SENS et al., 2008) (ver Seção 5.2), a
detecção assíncrona das falhas é feita aguardando-se a recepção de determinada mensagem de
d − f remetentes distintos. Entretanto, semelhantemente ao mecanismo de mensagens do tipo
“eu estou vivo” (I’m alive), o padrão de mensagens QUERY - RESPONSE no qual (SENS et al.,
2008) se fundamenta não é adequado ao modelo bizantino, pois um processo faltoso pode en-
viar mensagens RESPONSE sem no entanto atender aos requisitos de progresso de A . Propõe-se
aqui, portanto, que os processos aguardem a recepção das mensagens requeridas por A a partir
de pelo menos (d − f ) remetentes distintos, suspeitando-se de omissão dos demais processos
(ver Figura 5.5). Isso leva ao requisito de que o padrão de comunicação do algoritmo A seja
distribuído (ou seja, n → n), isto é, que a cada passo todos os processos troquem mensagens en-
tre si. Um algoritmo de consenso desse tipo que utiliza um detector de falhas ♦S é apresentado
em (GUERRAOUI; RAYNAL, 2004).
Com base nessa consideração, conjectura-se ser impossível realizar a detecção de falhas por
omissão, caso o padrão de troca de mensagens seja do tipo 1 → n, pois nesse caso não haveria
como diferenciar uma falha por omissão de um retardo na recepção da mensagem, pelo fato de
o sistema ser assíncrono. Portanto, conjectura-se que:
46
Para ser possível a detecção das falhas de comissão, um formato de mensagens deve ser
estabelecido. Cada mensagem deve também incluir um certificado que possibilite aos demais
processos verificar a coerência da mesma com o algoritmo A . Caso um processo detecte a
invalidade de uma mensagem recebida, seja por não atender ao formato ou por não estar devi-
47
tectar quando um processo encaminha duas versões diferentes da mesma mensagem, como a
situação ilustrada na Figura 5.9. Para isto requer-se que os processos corretos reencaminhem
para todos os demais cada mensagem recebida, além de que seja gerado um histórico das men-
sagens provenientes de cada processo. Supõe-se no entanto que os processos podem realizar
comunicação entre pares. No modelo aqui proposto, em que os processos se comunicam apenas
por difusão local em canais confiáveis, é natural supor que uma mensagem transmitida será re-
cebida com conteúdo idêntico por todos os processos corretos, de forma que este tipo de falhas
não pode ocorrer. Chega-se portanto à seguinte observação:
Figura 5.9: Processo corrupto que envia mensagens com valores diferentes para processos dife-
rentes (supor x 6= y, y 6= z ou x 6= z)
Para que o protocolo proposto neste trabalho funcione corretamente, é necessário que os
processos atendam à propriedade de inclusão bizantina, definida como:
49
Figura 5.10: Inclusão de um processo novo no sistema com base na propriedade ByzM P
( f = 1)
Esta propriedade garante que um processo novo pi no sistema em algum momento no futuro
será conhecido por pelo menos 2 f + 1 processos, dos quais pelo menos f + 1 serão corretos.
Para tanto, é necessário que pi se comunique com pelo menos 2 f + 1 processos dentro de sua
área de cobertura, enviando-lhes uma mensagem SUSPICION por difusão. Dessa forma, se pi
falhar, em algum momento no futuro pelo menos f + 1 processos corretos suspeitarão de pi e
transmitirão a suspeita para o restante do sistema, de forma que a propriedade de completude
forte bizantina do detector ♦S (Byz, A ) seja atendida. Se um processo novo não se comunicar
com nenhum outro, é impossível atender à propriedade de completude fraca (FERNÁNDEZ;
JIMÉNEZ; ARÉVALO, 2006). A inclusão de um processo novo no sistema com base nessa
propriedade é ilustrada na Figura 5.10.
Para que a propriedade de precisão fraca após um tempo da classe ♦S (Byz, A ) seja ante-
dida, é necessário que exista um processo correto cujas mensagens a partir de algum momento
estejam sempre entre as d − f primeiras recebidas pelos seus vizinhos, a cada requisição de A .
Assim sendo, após um tempo pi não será mais suspeito por nenhum processo e terá quaisquer
suspeitas anteriores revogadas através de equívocos. Logo, a rede deve possuir um nó correto
que atenda à propriedade de receptividade bizantina, definida como:
5.5 IMPLEMENTAÇÃO
• out puti : armazena a saída do detector de falhas, isto é, o conjunto de identificadores dos
processos de que pi suspeita terem falhado;
• knowni : armazena o conjunto dos processos que se comunicaram com pi , isto é, sua
suposta vizinhança. É atualizada a cada recepção de mensagem m, seja m do tipo SUSPI -
CION ou uma mensagem inerente a A ;
51
• changed_state: variável booleana que indica que houve mudança no estado interno do
processo; utilizada para otimizar o envio de mensagens SUSPICION . É inicializada com
true para que, ao se integrar ao sistema, um processo novo difunda uma mensagem SUS -
PICION à sua vizinhança;
• external_suspi : matriz que armazena suspeitas externas (geradas por outros processos).
A matriz é indexada por um identificador de processo q e por um identificador de mensa-
gem idm. Cada entrada armazena o conjunto de processos dos quais pi recebeu suspeitas
de q não ter enviado a mensagem com identificador idm;
• internal_suspi : vetor de suspeitas internas. Uma suspeita interna é gerada pela não-
recepção de uma mensagem requerida por A ou pela existência de pelo menos f + 1
suspeitas externas sobre um mesmo par processo-mensagem;
• mistakei : vetor que armazena, para cada processo aplicável p j , o conjunto de equívo-
cos relacionados a p j , na forma de mensagens requeridas por A sobre as quais foram
levantadas suspeitas;
• rec_ f romi : conjunto de processos dos quais pi recebeu a mensagem requisitada por A ;
• byzantine: variável booleana utilizado pela tarefa T4 para verificar se o processo que
enviou a mensagem SUSPICION apresentou comportamento bizantino.
• AddExternalSusp(q, idm, ps ) (linhas 9-13 do Algoritmo 1): adiciona uma suspeita externa
ao processo q proveniente do processo ps em relação à mensagem com identificado idm.
Adicionalmente, caso existam f + 1 ou mais suspeitas externas sobre q em relação a
message(idm), gera-se uma suspeita interna equivalente, caso ainda não exista;
• Verify(m, procedure) (linhas 1-6 do Algoritmo 3, utilizado pela tarefa T4): verifica se a
mensagem/informação m está devidamente assinada. Caso verdadeiro, avalia e executa
a chamada de procedimento procedure; caso contrário, marca o processo que enviou a
mensagem SUSPICION atual como malicioso.
1. Geração de novas suspeitas (linhas 1-11 do Algoritmo 2). Quando o algoritmo A requer
que os processos troquem entre si uma mensagem m (linha 2), cada processo pi aguarda
receber m de pelo menos d − f processos, cujos identificadores são armazenados no con-
junto rec_ f romi (linhas 3-4). Para os demais processos conhecidos por pi , é adicionada
53
uma suspeita interna de falha por omissão (linhas 5-7). Cada mensagem é então verificada
quanto à sua formação e certificação (linhas 8-11 do Algoritmo 2 e 28-33 do Algoritmo
1). Mensagens incorretas levam a suspeitas de falhas por comissão (linhas 29-30 do
Algoritmo 1), atualizando os conjuntos byzantinei e a saída do detector de falhas; mensa-
gens corretas levam à geração de equívocos de possíveis suspeitas de falhas por omissão
(linhas 31-32 do Algoritmo 1).
2. Recepção de mensagens de processos lentos (linhas 13-16 do Algoritmo 2). Uma vez
que as mensagens enviadas por um processo lento podem ser recebidas após a geração
das suspeitas pelos seus vizinhos, é necessário que estes identifiquem tais eventos sepa-
radamente, o que é feito por esta tarefa. As mensagens são tratadas de forma similar à
tarefa T1.
4. Atualização do estado interno (linhas 8-44 do Algoritmo 3). Ao receber uma mensagem
SUSPICION de um vizinho p j (linha 9), um processo pi atualiza seu estado interno com
novas informações. Provas de comportamento comissivo e informações de equívoco são
tratadas de forma similar às mensagens recebidas diretamente do remetente (linhas 16 e
33-40). Suspeitas internas e externas a p j são adicionadas ao conjunto de suspeitas exter-
nas de pi (linhas 21-31), possivelmente gerando novas suspeitas internas (linhas 11-13 do
Algoritmo 1). Adicionalmente, suspeita-se de falha por comissão do processo p j (linhas
42-44) caso a mensagem SUSPICION m esteja mal-formada ou não justificada (linhas 12-
13), caso uma mensagem correta esteja no conjunto byzantine j (linhas 17-19) ou uma
mensagem incorreta esteja no conjunto mistake j (linhas 36-38), ou ainda caso provas de
comportamento malicioso (linha 16), suspeitas reencaminhadas (linhas 24) ou provas de
equívocos (linha 35) contidas em m não estejam devidamente assinadas (tal verificação
é feita no procedimento Verify, linhas 1-6 do Algoritmo 3). A informação válida, no
entanto, é aproveitada. Neste caso, não se configura uma falha não-diagnosticável, pois
processos corretos devem descartar mensagens não assinadas e conseqüentemente não
reencaminhá-las.
54
1. Completude forte bizantina. Se um processo pi falhar por omissão, não enviando uma
mensagem m requerida pelo algoritmo A , os demais processos em rangei suspeitarão de
pi com base no mecanismo de espera de d − f mensagens descrito na Seção 5.3 (linhas
2-7 do Algoritmo 2). Devido às propriedades de f -cobertura bizantina e ByzM P, pelo
menos f + 1 processos corretos suspeitarão corretamente de pi , armazenando a suspeita
em seus conjuntos internal_state e atualizando a variável changed_state (linhas 5-7 do
Algoritmo 1), de forma que as suspeitas serão divulgadas aos seus vizinhos em uma
mensagem SUSPICION na próxima execução da tarefa T3 (linhas 18-24 do Algoritmo 2).
A propagação das suspeitas na rede é garantida pela tarefa T4. Seja p j um vizinho correto
de um processo falho pi . Ao receber uma mensagem SUSPICION de p j , um processo cor-
reto pk armazena as suspeitas de p j como suspeitas externas (linhas 28-32 do Algoritmo
3), no caso de falhas por omissão. Como as suspeitas externas são re-encaminhadas pelos
processos que as recebem (linhas 21 do Algoritmo 2 e 21-27 do Algoritmo 3), devido à
propriedade de f -cobertura bizantina, por indução, em algum momento futuro pk rece-
berá mais f suspeitas externas associadas ao par (pi , m), adotando assim essa suspeita
(linhas 11-13 do Algoritmo 1). Por indução, verifica-se que todos os processos corretos
da rede acabarão por suspeitar de pi não ter enviado m.
Da mesma forma, se pi cometer uma falha por comissão, a mesma será identificada por
seus vizinhos na chamada ao procedimento ValidateReceived da linha 10 do Algoritmo
2, nas linhas 12-13, 17-19 e 36-38 do Algoritmo 3 ou nas chamadas ao procedimento
Verify (linhas 1-6 do Algoritmo 3) nas linhas 16, 24 e 35 do Algoritmo 3. Por argumento
semelhante ao exibido para falha por omissão, a mensagem associada m é armazenada no
conjunto byzantine e transmitida aos vizinhos dos processos em rangei em uma mensa-
gem SUSPICION . Ao receber a mensagem SUSPICION de um processo p j vizinho a pi ,
um processo pk vizinho a p j analisará a mensagem m (linhas 15-20 do Algoritmo 3) e,
uma vez que as mensagens são autenticadas, poderá constatar a falha do processo pi . Por
indução, em algum momento futuro todo processo correto na rede recebe a evidência da
falha.
55
2. Precisão fraca após um tempo. Seja pi um processo que nunca falhe e que atenda à pro-
priedade ByzRP. Como as mensagens são autenticadas e pi é correto, nenhum processo
malicioso poderá divulgar que pi cometeu uma falha por comissão. Pela propriedade
ByzRP, existirá um instante t após o qual as mensagens de pi requeridas por A serão
sempre recebidas pelos processos em rangei na linha 3 do Algoritmo 2. Desta forma, os
processos corretos em rangei nunca mais suspeitarão de pi . Haverá ainda um instante
u > t após o qual toda suspeita sobre pi anterior a t será revogada pelos vizinhos de pi
(linhas 8-11 e 13-16 do Algoritmo 2 e 15-22 do Algoritmo 1) e divulgada por toda a rede,
por argumento semelhante ao feito quanto à divulgação das suspeitas e pela atualização
feita nas linhas 33-40 do Algoritmo 3, de forma que nenhum processo correto suspeitará
de pi após u. Se um ou mais processos maliciosos levantarem uma suspeita sobre pi após
t, como existem no máximo f processos faltosos no sistema, não seria possível conven-
cer os processos corretos de adotarem tal suspeita, visto que seriam necessárias suspeitas
provenientes de f + 1 processos distintos.
56
6 CONCLUSÃO
Este trabalho apresenta um detector de falhas bizantinas para sistemas distribuídos com
participantes desconhecidos. O detector é assíncrono, isto é, não se utiliza de temporizadores
(timeouts) para a detecção das falhas de progresso. Verifica-se assim a viabilidade da detecção
de falhas bizantinas em sistemas dinâmicos. No entanto, para que a detecção seja realizada de
forma assíncrona, acredita-se ser necessário que o padrão de comunicação do algoritmo que
utiliza o detector de falhas seja do tipo n → n, isto é, que a cada passo todos os processos
troquem mensagens entre si.
Verifica-se ainda que a suposição de comunicação apenas por difusão (broadcast) e de ca-
nais confiáveis simplifica o tratamento de falhas bizantinas, uma vez que os processos vizinhos
de um remetente têm uma visão uniforme das mensagens por ele enviadas. Especificamente,
não é necessário tratar a ocorrência de mensagens mutantes, isto é, quando um mesmo processo
envia a mesma mensagem com conteúdos diferentes para diferentes processos.
Foi apresentada também uma revisão teórica dos modelos de sistemas distribuídos presentes
na literatura, em especial do modelo de falhas bizantinas e dos sistemas distribuídos dinâmicos;
do conceito de detectores de falhas e do problema do consenso, como motivação para o uso
dessa abstração.
Além de ser uma área de pesquisa muito teórica, a quantidade de considerações necessárias
para o desenvolvimento de algoritmos distribuídos torna este tipo de trabalho muitas vezes
exaustivo, o que, muitas vezes, não fica claro devido à simplicidade dos protocolos resultantes.
Demanda-se um tempo relativamente grande de leitura para que se tenha uma visão clara e
abrangente do domínio dos problemas abordados (o que pode ser verificado pela quantidade de
referências citadas).
• Divulgação do trabalho em conferências e/ou periódicos, com vistas a verificar sua acei-
tação pela comunidade científica.
61
REFERÊNCIAS BIBLIOGRÁFICAS
AGUILERA, M. K. A Pleasant Stroll through the Land of Infinitely Many Creatures. ACM
SIGACT News, v. 35, n. 2, p. 36–59, June 2004.
AGUILERA, M. K. et al. Stable Leader Election. In: DISC ’01: Proceedings of the 15th
International Conference on Distributed Computing. London, UK: Springer-Verlag, 2001. p.
108–122. ISBN 3-540-42605-1.
AGUILERA, M. K. et al. Consensus with Byzantine Failures and Little System Synchrony.
In: International Conference on Dependable Systems and Networks 2006 (DSN’06). Los
Alamitos, CA, USA: IEEE Computer Society, 2006. p. 147–155.
BONDY, J. A.; MURTY, U. S. R. Graph Theory with Applications. New York, NY:
MacMillan/Elsevier, 1976. ISBN 0-444-19451-7.
CAVIN, D.; SASSON, Y.; SCHIPER, A. Reaching Agreement with Unknown Participants in
Mobile Self-Organized Networks in Spite of Process Crashes. Ecole Polytechnique Federale de
Lausanne, France, 2005.
CHANDRA, T. D.; HADZILACOS, V.; TOUEG, S. The weakest failure detector for solving
consensus. J. ACM, ACM, New York, NY, USA, v. 43, n. 4, p. 685–722, 1996. ISSN
0004-5411.
CHANDRA, T. D.; TOUEG, S. Unreliable failure detectors for reliable distributed systems. J.
ACM, ACM, New York, NY, USA, v. 43, n. 2, p. 225–267, 1996. ISSN 0004-5411.
62
DOLEV, D.; DWORK, C.; STOCKMEYER, L. On the minimal synchronism needed for
distributed consensus. J. ACM, ACM, New York, NY, USA, v. 34, n. 1, p. 77–97, 1987. ISSN
0004-5411.
DOUCEUR, J. R. The sybil attack. In: IPTPS ’01: Revised Papers from the First International
Workshop on Peer-to-Peer Systems. London, UK: Springer-Verlag, 2002. p. 251–260. ISBN
3-540-44179-4.
DOUDOU, A.; SCHIPER, A. Muteness detectors for consensus with byzantine processes.
In: PODC ’98: Proceedings of the seventeenth annual ACM symposium on Principles of
distributed computing. New York, NY, USA: ACM, 1998. p. 315. ISBN 0-89791-977-7.
DWORK, C.; LYNCH, N.; STOCKMEYER, L. Consensus in the presence of partial synchrony.
J. ACM, ACM, New York, NY, USA, v. 35, n. 2, p. 288–323, 1988. ISSN 0004-5411.
FERNÁNDEZ, A.; JIMÉNEZ, E.; RAYNAL, M. Eventual Leader Election with Weak
Assumptions on Initial Knowledge, Communication Reliability, and Synchrony. In:
Proceedings of the 2006 International Conference on Dependable Systems and Networks
(DSN’06). Los Alamitos, CA, USA: IEEE Computer Society, 2006. p. 166–178. ISBN
0-7695-2607-1.
FRIEDMAN, R.; TCHARNY, G. Evaluating failure detection in mobile ad-hoc networks. Int.
Journal of Wireless and Mobile Computing, v. 1, n. 8, 2005.
GREVE, F.; TIXEUIL, S. Knowledge Connectivity vs. Synchrony Requirements for Fault-
Tolerant Agreement in Unknown Networks. In: DSN ’07: Proceedings of the 37th Annual
IEEE/IFIP International Conference on Dependable Systems and Networks. Washington, DC,
USA: IEEE Computer Society, 2007. p. 82–91. ISBN 0-7695-2855-4.
HURFIN, M. et al. A General Framework to Solve Agreement Problems. In: SRDS ’99:
Proceedings of the 18th IEEE Symposium on Reliable Distributed Systems. Washington, DC,
USA: IEEE Computer Society, 1999. p. 56. ISBN 0-7695-0290-3.
LAMPORT, L. Time, clocks, and the ordering of events in a distributed system. Commun.
ACM, ACM, New York, NY, USA, v. 21, n. 7, p. 558–565, 1978. ISSN 0001-0782.
LAMPORT, L. The part-time parliament. ACM Trans. Comput. Syst., ACM, New York, NY,
USA, v. 16, n. 2, p. 133–169, 1998. ISSN 0734-2071.
LAMPORT, L.; SHOSTAK, R.; PEASE, M. The byzantine generals problem. ACM Trans.
Program. Lang. Syst., ACM, New York, NY, USA, v. 4, n. 3, p. 382–401, 1982. ISSN
0164-0925.
MARTIN, J.-P.; ALVISI, L. Fast Byzantine Consensus. IEEE Trans. Dependable Secur.
Comput., IEEE Computer Society Press, Los Alamitos, CA, USA, v. 3, n. 3, p. 202–215, 2006.
ISSN 1545-5971.
MOSTEFAOUI, A. et al. From Failure Detectors with Limited Scope Accuracy to System-wide
Leadership. In: AINA ’06: Proceedings of the 20th International Conference on Advanced
Information Networking and Applications - Volume 1 (AINA’06). Washington, DC, USA: IEEE
Computer Society, 2006. p. 81–86. ISBN 0-7695-2466-4-01.
PEASE, M.; SHOSTAK, R.; LAMPORT, L. Reaching Agreement in the Presence of Faults. J.
ACM, ACM, New York, NY, USA, v. 27, n. 2, p. 228–234, 1980. ISSN 0004-5411.
RIVEST, R. L.; SHAMIR, A.; ADLEMAN, L. A method for obtaining digital signatures and
public-key cryptosystems. Commun. ACM, v. 21, p. 120–126, 1978.
SCHNEIDER, F. B. What good are models and what models are good? In: Distributed systems
(2nd Ed.). New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 1993. p. 17–26.
ISBN 0-201-62427-3.
VERISSIMO, P.; RODRIGUES, L. Distributed Systems for System Architects. Norwell, MA,
USA: Kluwer Academic Publishers, 2001. ISBN 0792372662.