tolerancia a falhas bizantinas em protocolos deˆ replicac ......cap´ıtulo 1 introduc¸ao˜ h oje...

Tolerância a Falhas Bizantinas em Protocolos deReplicação Epidémicos

André Limão Galo Nunes(Licenciado em Engenharia Informática e de Computadores)

Dissertação para obtenção do grau:

Mestre em Engenharia Informática e de Computadores

Comité de Avaliação

Presidente: Prof. Doutor Nuno João Neves MamedeOrientador: Prof. Doutor João Pedro BarretoVogáis: Prof. Doutor Alysson Neves Bessani

Maio de 2012

placeholder

Sumário

Os protocolos epidémicos de quóruns são protocolos descentralizados de replicação de da-

dos que, mesmo perante a existência de partições de rede, garantem consistência forte

dos dados e disponibilidade dos serviços do sistema. Estas caracterı́sticas tornam este tipo de

protocolos numa excelente ferramenta para replicação de dados em sistemas que funcionam em

redes móveis e fracamente ligadas. No entanto, este tipo de protocolos não tolera falhas bizan-

tinas, apesar dos estudos que mostram que falhas bizantinas são comuns e perigosas para os

sistemas replicados.

Nesta tese de mestrado propõe-se um protocolo de replicação inovador, chamado de eBFT, que

é tanto quanto sabemos o primeiro protocolo epidémico de quóruns a tolerar falhas bizantinas.

O protocolo eBFT é analisado num simulador e quantifica-se o custo adicional de adicionar to-

lerância a falhas bizantinas a protocolos epidémicos de quóruns em eBFT. O eBFT necessita de

trocar cerca de o dobro das mensagens para executar um pedido de um cliente comparativa-

mente a um protocolo epidémico de quóruns sem tolerância a falhas bizantinas.

Keywords: replicação , quórum , bizantinas

As contribuições desta dissertação foram parcialmente publicadas em:

• André Nunes and João Barreto, ”eBFT: Tolerância a Falhas Bizantinas em Protocolos de

Replicação Epidémicos”, in Proceedings of INFORUM 2011, 2011, Coimbra, Portugal.

v

placeholder

Agradecimentos

Tenho muito que agradecer ao meu orientador, Professor João Pedro Barreto, por todaa ajuda, paciência e disponibilidade oferecida ao longo do tempo em que elaborei estadissertação.

Gostaria ainda de agradecer o suporte financeiro na ida ao INFORUM 2011 da Fundação

para a Ciência e Tecnologia (FCT), através do programa PIDDAC e do projecto Byzantium

(PTDC/EIA/74325/2006).

ix

placeholder

Conteúdo

Sumário v

Agradecimentos ix

1 Introdução 3

2 Conceitos e Trabalho Relacionado 7

2.1 Modelos de Sistemas Distribuı́dos . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Modelos Sı́ncrono vs. Assı́ncrono . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Modelo de Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Coordenação em Sistemas Distribuı́dos . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Problema do Consenso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Problema da Consistência em Sistemas Replicados . . . . . . . . . . . . . 11

2.2.3 Replicação Activa com Partições de Rede . . . . . . . . . . . . . . . . . . . 17

2.3 Protocolos Epidémicos de Quóruns . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1 Keleher et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.2 Holliday et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Tolerância a Falhas Bizantinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.1 Protocolos com Abordagem de Máquina de Estados . . . . . . . . . . . . . 27

2.4.2 Survivable Consensus Objects . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.3 Turquois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

xi

3 Contribuições 35

3.1 Modelo do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 eBFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Votação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2 Propagação Epidémica de Informação . . . . . . . . . . . . . . . . . . . . . 40

3.2.3 Detecção de Réplicas Bizantinas . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.4 Clientes Bizantinos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.5 Número Mı́nimo Total de Réplicas no Sistema . . . . . . . . . . . . . . . . 42

3.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Validação 47

4.1 Metodologia de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Conclusões e Trabalho Futuro 55

Bibliografia 58

xii

placeholder

Lista de Figuras

2.1 Modelo de arquitectura genérica de um sistema replicado . . . . . . . . . . . . . . 12

2.2 Modelo de Replicação Passiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Modelo de Replicação Activa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Exemplo protocolo Deno, parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23



2.7 Exemplo protocolo Deno com réplica bizantina, parte 1 . . . . . . . . . . . . . . . 24

2.8 Exemplo protocolo Deno com réplica bizantina, parte 2 . . . . . . . . . . . . . . . 24

3.9 Exemplo de voto falso, parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.10 Exemplo de voto falso, parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.11 Detecção de réplica bizantina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.12 Votação de cada réplica após proposta do candidato r . . . . . . . . . . . . . . . . 44

4.13 Número médio de intervalos necessários para a primeira réplica finalizar versus N 50

4.14 Número médio de intervalos necessários para todas as replicas finalizarem versus N 50

4.15 Número médio de intervalos necessários para enésima réplica finalizar com N = 10 51

4.16 Número médio de intervalos necessários para enésima réplica finalizar com N =

100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.17 Número médio de intervalos necessários para todas as réplicas finalizarem versus

N com 2 partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.18 Número médio de intervalos necessários para todas as réplicas finalizarem versus

N com 20 partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

1

2

4.19 Percentagem de finalização versus o número de operações concorrentes com N

= 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Capı́tulo 1

Introdução

Hoje em dia cada vez mais se utilizam dispositivos portáteis para executar aplicações dis-tribuı́das, que fazem uso de redes sem fios fracamente ligadas. Muitas aplicações re-plicam os seus dados por vários dispositivos móveis ou réplicas para uma maior disponibili-

dade. Desta forma, a aplicação pode ler/escrever os dados partilhados por simples acessos

às réplicas locais. Ocasionalmente, a aplicação sincroniza as réplicas de forma a assegu-

rar consistência. Exemplos dessas aplicações incluem sistemas colaborativos de desenvolvi-

mento de software (Cederqvist (1993)), ficheiros distribuı́dos (Nowicki (1989)) ou wikis colabora-

tivos (B. Leuf (2001)).

As redes móveis e fracamente ligadas são caracterizadas pela existência de partições de rede

que impossibilitam a comunicação entre réplicas que pertencem a diferentes partições. Esta

possibilidade deve-se ao ambiente severo de comunicação das redes móveis, no qual pode ocor-

rer (Sterbenz et al. (2002)): (i) atenuação rápida do sinal com a distância; (ii) desvanecimento

do sinal por múltiplos caminhos (multipath fading (Puccinelli & Haenggi (2006))); (iii) condições

climatéricas adversas; (iv) gaiolas de Faraday; (v) obstruções do terreno. No pior caso poderão

existir réplicas isoladas nas suas partições, o que impossibilita essas réplicas de comunicarem

com qualquer outra réplica.

Os protocolos de replicação que mais se adequam às caracterı́sticas das redes sem fios fraca-

mente ligadas são os protocolos de replicação descentralizados (Keleher (1999)). Idealmente,

os sistemas replicados que funcionam em ambientes fracamente ligados devem permitir que

sejam emitidas operações em qualquer réplica independentemente da disponibilidade das res-

tantes réplicas do sistema. Estes protocolos descentralizados proporcionam alta disponibilidade

no acesso aos objectos partilhados.

3

4 CAPÍTULO 1. INTRODUÇÃO

Estes sistemas replicados necessitam de consistência mesmo quando parte das réplicas estão

inacessı́veis. Para assegurar consistência nessas situações, é comum recorrer a protocolos de

quóruns (Jajodia & Mutchler (1990)). Este tipo de protocolos divide o conjunto total de réplicas

do sistema em vários subconjuntos (quóruns), onde cada par de subconjuntos se intercepta em

pelo menos uma réplica. Através da construção de quóruns é possı́vel a um quórum executar

operações propostas pelo cliente, sem comunicar com outros quóruns, e através da proprie-

dade de intersecção garantir que as operações executadas por quóruns distintos preservam a

consistência do sistema (Malkhi & Reiter (1998b)).

Os protocolos de quóruns dividem-se em dois tipos: protocolos clássicos de quóruns e proto-

colos epidémicos de quóruns. Os protocolos clássicos de quóruns (Jajodia & Mutchler (1990);

Peleg & Wool (1995)) funcionam com um coordenador (tipicamente a réplica que propõe um

pedido, ou seja, uma operação invocada pelo cliente) que executa um protocolo de confirmação

atómica distribuı́da (e.g. em 2 fases) para obter um quórum de réplicas, que aceita votar no

pedido proposto pelo coordenador. Caso o coordenador obtenha um quórum de votos para o

pedido então esse pedido é executado por esse quórum. O quórum que aceita votar no pedido

para ser confirmado é um grupo de réplicas vivas, que são tipicamente consideradas como es-

tando simultaneamente ligadas e na mesma partição de rede. Este requisito não é adequado

a redes sem fios fracamente ligadas, onde a existência de partições é comum, o que torna a

existência de grupos de réplicas ligadas improvável.

Holliday et al. (2003); Keleher (1999) propuseram protocolos epidémicos de quóruns (PEQ) que

permitem a quóruns desconectados acordarem num pedido para ser confirmado por todas as

réplicas. Isto é feito correndo um número finito de eleições, onde em cada eleição cada réplica

pode votar num único candidato, sendo que cada candidato corresponde à réplica que rece-

beu um pedido do cliente ou o próprio pedido proposto pelo cliente. Através da propagação

epidémica de votos, algures no tempo cada réplica deverá ser capaz de determinar, com base

na sua informação local, se pode decidir num candidato, ou se a eleição actual atingiu um estado

inconclusivo e uma nova eleição necessita de ser feita. Se uma réplica decide num candidato,

então executa o pedido correspondente ao candidato. Desta forma, os PEQs são uma ferra-

menta forte para a coordenação em redes fracamente ligadas.

As réplicas que fazem parte de protocolos de quóruns podem sofrer ataques maliciosos ou er-

ros de software, que podem provocar o comportamento arbitrário ou bizantino dessas réplicas.

Estudos recentes (Gashi et al. (2007)) mostram que a maioria de erros de software de IT detec-

tados em bases de dados comerciais podem provocar o comportamento bizantino ou arbitrário

dos mesmos. Além disso, os ataques maliciosos a sistemas de base de dados podem resultar

na perda de integridade de dados (DISA (2004)). Para tolerar este tipo de ataques ou erros nas

5

réplicas, foram criados vários protocolos (Lamport et al. (1982a)). No entanto, tanto quanto é do

nosso conhecimento, nenhum PEQ proposto até este momento tolera falhas bizantinas.

A principal contribuição desta tese é um novo protocolo de replicação, chamado eBFT(epidemic

Byzantine Fault Tolerance), que é o primeiro PEQ a suportar falhas bizantinas. O eBFT permite

o acordo num valor para ser aceite em quóruns desligados apesar da existência de um número

limitado de réplicas com comportamento bizantino. Este protocolo usa eleições e a propagação

epidémica de votos de forma semelhante aos PEQs e tolera réplicas bizantinas com quóruns de

maior dimensão e através da assinatura digital de mensagens.

A outra contribuição desta tese é o estudo do custo adicional do eBFT em relação a um PEQ

existente, Deno (Keleher (1999)). Esse estudo mostra que, com o eBFT, o custo adicional inferido

pela tolerância de falhas bizantinas em PEQs corresponde a um aumento do número total de

mensagens trocadas para cerca do dobro.

Os restantes conteúdos da dissertação estão organizados da seguinte forma. O Capı́tulo 2

apresenta alguns conceitos básicos e discute trabalhos relacionados. O Capı́tulo 3 detalha o

modelo proposto. O Capı́tulo 4 apresenta os estudos efectuados no contexto da validação da

hipótese da tese. Finalmente, o Capı́tulo 5 conclui o trabalho e discute possı́veis caminhos para

trabalho futuro.

placeholder

Capı́tulo 2

Conceitos e Trabalho Relacionado

Este capı́tulo apresenta os conceitos principais das áreas cientı́ficas onde o trabalho seinsere, assim como os trabalhos relacionados mais relevantes. Nas secções 2.1 e 2.2apresentam-se os conceitos mais importantes relacionados com tolerância a falhas e coordenação

em sistemas distribuı́dos. Nas secções 2.3 e 2.4 apresentam-se os trabalhos relacionados mais

importantes nas áreas de protocolos epidémicos de quóruns e de tolerância a falhas bizantinas.

2.1 Modelos de Sistemas Distribuı́dos

Um sistema distribuı́do é composto por um conjunto de componentes de hardware ou software

de computadores ligados em rede, que comunicam e coordenam as suas acções entre si através

da troca de mensagens (Couloris et al. (2005)). Como consequência, surgem os seguintes

desafios na construção deste tipo de sistemas (Couloris et al. (2005)):

• Heterogeneidade: cada componente do sistema distribuı́do pode utilizar diferentes siste-

mas operativos, hardware, linguagem de programação e tipo de rede;

• Abertura: sistemas distribuı́dos devem ser expansı́veis, sendo para isso necessário a ca-

pacidade de integrar novos componentes;

• Segurança: a segurança de dados partilhados tem três componentes: confidencialidade

da informação, integridade da informação e disponibilidade dos serviços que permitem

aceder a informação.

• Escalabilidade: um sistema distribuı́do é escalável se o custo em recursos para adicionar

um novo componente é constante;

7

8 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO

• Tratamento de falhas: qualquer componente do sistema distribuı́do, incluindo a rede, pode

falhar independentemente dos restantes componentes. Cada componente necessita de

estar preparada para as várias possibilidades de falha dos componentes dos quais de-

pende e ser designada para tratar essas falhas;

• Concorrência: a presença de múltiplos utilizadores no sistema distribuı́do pode originar

pedidos concorrentes para os recursos do sistema. Assim, torna-se necessário que cada

recurso do sistema seja construı́do de forma a funcionar de forma segura num ambiente

com concorrência;

• Transparência: os programadores das aplicações precisam apenas de se preocupar com

o desenho da sua aplicação, abstraindo-se dos aspectos ligados à distribuição da sua

aplicação.

Dos desafios mencionados, esta tese abordará os desafios de tratamento de falhas e con-

corrência. Desta forma, as secções seguintes serão focadas apenas em técnicas para lidar

com estes dois desafios.

Na secção 2.1.1 serão descritos modelos relacionados com o desempenho dos processos e

canais de comunicação, e com a inexistência de um relógio global. Na secção 2.1.2 são classi-

ficadas as possı́veis falhas dos processos e canais de comunicação.

2.1.1 Modelos Sı́ncrono vs. Assı́ncrono

Num sistema distribuı́do é comum adoptar-se um de três modelos relativamente à imposição ou

não de limites temporais para: execução de processos, entrega de mensagens, e desvios de

tempo de relógios locais de processos com o tempo real.

O modelo de sistema distribuı́do sı́ncrono é definido com os seguintes limites temporais (Hadzi-

lacos & Toueg (1994)):

• tempo máximo e mı́nimo de execução para cada passo de um processo;

• tempo máximo de transmissão de uma mensagem por um canal;

• tempo máximo de desvio de um relógio local de um processo com o tempo real.

No entanto, em muitos sistemas distribuı́dos não é possı́vel qualificá-los como sistemas sı́ncronos,

como por exemplo a Internet. Assim surge o modelo de sistemas distribuı́dos assı́ncronos onde

os limites temporais acima não são garantidos.

2.1. MODELOS DE SISTEMAS DISTRIBUÍDOS 9

Por fim, foi ainda proposto o modelo de sistemas distribuı́dos com sincronia parcial (Dwork et al.

(1988)). Neste sistema existem os limites temporais usados no modelo de sistemas distribuı́dos

sı́ncronos, mas estes limites não são conhecidos.

2.1.2 Modelo de Falhas

Num sistema distribuı́do os processos e os canais de comunicação podem falhar, i.e., o seu

comportamento pode não ser o correcto. Hadzilacos & Toueg (1994) criaram uma taxonomia

que classifica falhas em três classes: omissão, bizantinas e temporais. Além desta classificação,

é feita a distinção dentro de cada classe, se a falha é de um processo ou de um canal de

comunicação.

2.1.2.1 Falhas de Omissão

As falhas de omissão referem-se a casos onde um processo ou canal de comunicação não

executa as acções esperadas.

Falha de omissão de um processo ocorre quando um processo deixou de responder ao exterior.

Poderá ser possı́vel detectar uma falha deste tipo se considerarmos um sistema sı́ncrono. Para

tal, basta verificar se o processo alvo não responde a mensagens dentro do tempo limite especi-

ficado. Por exemplo, considerando um sistema sı́ncrono com garantia de entrega de mensagens,

dois processos p e q programados tais que um processo que receba uma mensagem, responde

sempre ao processo emissor da mensagem recebida. Assim se p envia uma mensagem para q

e não recebe a resposta dentro de um determinado limite máximo de tempo conhecido, então p

concluı́ que q sofreu uma falha de omissão.

No entanto, no caso de um sistema assı́ncrono não se considera limites temporais e como tal não

é possı́vel detectar este tipo de falha de processos. O facto de um processo não responder num

sistema assı́ncrono poderá dever-se, por exemplo, ao atraso de entrega do pedido ao processo.

Falha de omissão de um canal de comunicação ocorre quando um processo envia uma mensa-

gem a outro processo, mas a mensagem é perdida pelo canal de comunicação.

2.1.2.2 Falhas Bizantinas

As falhas bizantinas referem-se a casos onde qualquer tipo de comportamento não especificado

pode ocorrer.

Falha bizantina de um processo faz com que um processo execute operações erradas ou sem


lógica. Desta forma, este tipo de falhas em processos não pode ser detectado verificando se

um processo responde ou não a um pedido, porque o processo pode omitir respostas arbi-

trariamente. Por exemplo um processo ao sofrer uma falha deste tipo pode actualizar dados

persistentes com os valores errados, apesar dos valores de entrada serem correctos.

Falha bizantina de um canal de comunicação ocorre quando este corrompe as mensagens que

transmite para processos. Existem vários mecanismos para detectar este tipo de falhas, como

por exemplo o uso da técnica de resumos criptográficos de mensagens (Rivest (1992)). Nesta

técnica, o processo que envia a mensagem cria um resumo da mensagem, através de um algo-

ritmo de criação de resumos e envia a mensagem em conjunto com o resumo. Quando outro

processo recebe essa mensagem, utiliza o mesmo algoritmo de criação de resumos para criar

um resumo da mensagem recebida e verifica se o resumo criado é igual ao recebido.

2.1.2.3 Falhas de Temporização

Falhas de temporização ocorrem apenas em sistemas sı́ncronos. Surgem quando algum dos

limites temporais estipulados nesse tipo de sistemas é ultrapassado.

Falha de temporização de um processo pode ocorrer em duas situações. Quando o relógio local

de um processo tem uma diferença maior do que o limite temporal estipulado em relação tempo

real, ou quando um processo ultrapassa o limite temporal estipulado para um passo do processo.

Falha de temporização de um canal de comunicação ocorre quando o tempo limite estipulado

para a transmissão de mensagens entre dois processos é quebrado.

2.2 Coordenação em Sistemas Distribuı́dos

Nesta secção descreve-se dois problemas fundamentais de coordenação de sistemas distribuı́dos

cuja a análise é essencial para a construção de sistemas com consistência. Na secção 2.2.1

descreve-se o problema de consenso que visa a coordenação das acções dos processos. Na

secção seguinte 2.2.2 descreve-se o problema de consistência que visa a replicação de dados.

2.2.1 Problema do Consenso

Nesta secção introduz-se o problema do consenso (Lamport et al. (1982b); Pease et al. (1980)).

Na visão geral deste problema um ou mais processos propõem um conjunto de valores e de

seguida o conjunto total de processos do sistema acorda num único valor do conjunto de valores

2.2. COORDENAÇÃO EM SISTEMAS DISTRIBUÍDOS 11

propostos. Exemplos de aplicações deste problema incluem:

• Exclusão mútua distribuı́da: esta aplicação tem como objectivo prevenir a interferência

entre processos no acesso a dados partilhados, e assegurar a consistência dos mesmos

dados.

• Eleições: esta aplicação tem como objectivo escolher de um conjunto de processos um

único processo para executar um determinado papel. Para tal, é necessário que todos os

processos acordem na escolha do processo.

• Comunicação multicast: esta aplicação tem o objectivo de assegurar que um grupo de pro-

cessos acorde as mensagens que irá receber e a ordem na qual esse grupo de processos

irá receber as mesmas mensagens.

Um requisito importante para muitas aplicações (B. Leuf (2001); Cederqvist (1993); Nowicki

(1989)) é o de atingir consenso mesmo na presença de falhas. Desta forma, soluções para

o problema devem tolerar falhas de omissão ou bizantinas nos processos. Entre as várias

formulações para o problema do consenso, a formulação que adoptei tem as seguintes pro-

priedades (Couloris et al. (2005)):

• Terminação: Algures no tempo cada processo correcto decide um valor;

• Acordo: O valor decidido por todos os processos correctos é o mesmo;

• Integridade: O valor decidido por um processo correcto foi obrigatoriamente proposto por

algum processo correcto.

Na definição apresentada para o problema de consenso podem ocorrer apenas falhas de omissão

ou bizantinas nos processos e os canais de comunicação são considerados fiáveis, ou seja, ga-

rantem a entrega de mensagens.

Se considerarmos sistemas assı́ncronos, segundo Fischer et al. (1985), não é possı́vel construir-

se protocolos que garantam consenso. Isto deve-se à inexistência de limites temporais para

sistemas assı́ncronos, e como tal é impossı́vel distinguir um processo lento de um processo que

sofreu uma falha de omissão.

2.2.2 Problema da Consistência em Sistemas Replicados

Replicação de dados consiste em manter múltiplas cópias de objectos lógicos (ficheiros, base

de dados, etc), chamadas réplicas, em computadores separados. A replicação é um técnica


fundamental para melhorar: o desempenho, a disponibilidade e a tolerância a falhas dos serviços

disponibilizados por sistemas distribuı́dos (Saito & Shapiro (2005)).

Aquando a utilização da técnica de replicação surgem dois requisitos: transparência da replicação

e consistência.

Segundo o requisito de transparência da replicação, os clientes não devem ter a noção da

existência de múltiplas cópias fı́sicas de objectos lógicos. Se este requisito for cumprido, os

clientes terão a perspectiva de que os dados são organizados em objectos lógicos individuais.

Como tal, quando os clientes fazem um pedido identificam apenas um item, i.e., o objecto lógico.

O requisito de consistência varia a sua força de acordo com as aplicações em causa. O objectivo

deste requisito é de que os pedidos executados numa colecção de cópias fı́sicas de um objecto

lógico produzam resultados que estejam de acordo com a especificação de correcção para esse

objecto lógico.

2.2.2.1 Arquitectura Genérica de Sistema Replicado

Apesar de haver uma grande diversidade de arquitecturas de sistemas replicados, uma grande

maioria pode ser vista como adoptada da arquitectura na Figura 2.1 (Couloris et al. (2005)). Em

particular, todos os sistemas de replicação que descreverei neste documento poderão ser vistos

como instâncias desta arquitectura genérica.

Figura 2.1: Modelo de arquitectura genérica de um sistema replicado

Nesta arquitectura genérica, as componentes que contêm as réplicas num dado computador são

definidas como Replica Managers (RM). Estas componentes são também responsáveis por exe-

cutar operações nas réplicas directamente. As operações executam-se de forma recuperável,

i.e., no caso de uma RM sofrer uma falha de omissão, as réplicas sobre as quais estava a exe-

cutar operações não ficam num estado inconsistente, ou seja, não existe nenhuma réplica com

um estado diferente das restastes. As RM são assumidas como máquinas de estado (Lam-

port (1978); Schneider (1990)) de forma a que o estado das suas réplicas é uma função deter-

minı́stica do seu estado inicial com a sequência de operações executadas pela RM. O conjunto


de RM pode ser estático ou dinâmico. No primeiro caso o conjunto de RM é fixo, enquanto que

no segundo caso podem entrar ou sair RM.

Segundo a arquitectura na Figura 2.1 as RM disponibilizam um serviço aos clientes, que permite

aos clientes aceder aos objectos lógicos replicados nas RM. Assim, os clientes podem invocar

uma sequência de operações, ou seja, uma transacção. Uma transacção ou pedido de um

cliente pode ser de dois tipos: leitura de dados ou actualização de dados. O primeiro tipo de

pedido envolve apenas operações de leitura, enquanto que o segundo tipo de pedido contém

operações que alteram o estado de objectos, podendo também conter operações de leitura.

A função do componente Front End (FE) é receber os pedidos dos clientes directamente e depois

difundi-los pelas RM. O objectivo da utilização dos FE é o de assegurar que os clientes não

têm de executar a função dos FE, ou seja, difundir os seus pedidos pelas RM, e dessa forma

assegurar transparência de replicação.

2.2.2.2 Consistência

Não existe a possibilidade de o FE propagar pedidos para as RM de forma instantânea, o que

implica a possibilidade da existência de perı́odos em que o estado das RM é inconsistente entre

si. Logo, é necessário impor critérios de correcção. Nesta secção serão descritos critérios de

correcção que garantem consistência forte, tais como, a linearidade e a consistência sequencial.

Um sistema com consistência forte implica que em nenhum perı́odo de tempo exista réplicas

com estado inconsistente. Por fim, será também descrito o critério de correcção definido como

eventual consistency que garante consistência fraca. Neste tipo de consistência é possı́vel que

em certos perı́odos de tempo existam réplicas com estado inconsistente.

O critério mais restrito que os sistemas podem usar chama-se linearidade (Herlihy & Wing

(1987)).

Um sistema de replicação diz-se linearizável se, para qualquer execução, existe uma intercalação

de pedidos executados que satisfaz duas condições:

• A sequência intercalada de pedidos está de acordo com a especificação de uma (única)

cópia correcta dos objectos. Ou seja, todas réplicas executam sequências intercaladas de

pedidos que produzem o mesmo resultado.

• A ordem dos pedidos na intercalação é consistente com o tempo real em que ocorreram na

execução real. Ou seja, um cliente A que invoque um pedido X, depois de um cliente B ter

recebido a resposta de um pedido Y, terá o seu pedido X executado em todas as réplicas

depois da execução do pedido Y.


A segunda condição impõe o requisito do uso de tempo real, o que muitas vezes é impraticável

devido à dificuldade em sincronizar relógios em sistemas assı́ncronos.

Um outro tipo de critério de correcção, mais fraco que a linearidade, é a consistência sequencial.

A primeira condição da linearidade mantém-se. No entanto, a segunda condição altera-se para:

• A ordem dos pedidos na intercalação é consistente com a ordem de programa executada

por cada cliente, i.e., a ordem de eventos em cada cliente. Como exemplo, suponha-se

que um cliente A invoca a sequência de pedidos X, W e , de seguida, um cliente B invoca

a sequência de pedidos Y, H. Com este critério, a sequência intercalada de pedidos dos

clientes A e B teria de respeitar a ordem de invocação dos pedidos em cada cliente (X-

>W e Y->H), mas o tempo de invocação entre os dois clientes pode não ser respeitado.

Por exemplo, poderia se ter como sequência intercalada de pedidos Y,X,H,W, onde Y é o

primeiro pedido a ser executado da sequência.

O requisito de tempo real utilizado pela linearidade faz com que a sua implementação seja

impraticável em muitos casos porque nem sempre é possı́vel sincronizar os relógios com o nı́vel

de precisão necessária (Couloris et al. (2005)). O critério de consistência sequencial continua a

ser um critério que garante consistência forte, mas não utiliza o requisito de tempo real. Pelas

condições já referidas para cada critério de correcção, é possı́vel verificar que qualquer serviço

linearizável é também sequencialmente consistente.

Existem outras variantes de critérios de correcção fortes ( Gray & Reuter (1992)) que, devido ao

âmbito desta tese, não serão analisados.

Outro critério de correcção é o de eventual consistency. Neste critério, apenas se garante que,

se apartir de um determinado instante não ocorrerem mais pedidos, algures no tempo, todas

as réplicas convergem para o mesmo estado e todos os acessos a qualquer réplica retornam o

valor mais actual (Vogels (2008)). Os sistemas que utilizam este tipo de critério de correcção

têm como benefı́cio uma maior disponibilidade dos serviços oferecidos pelo sistema, em relação

aos sistemas com consistência forte. No entanto, a maior disponibilidade dos serviços tem como

custo a possibilidade da existência de perı́odos de inconsistência dos dados.

Um grande número de sistemas em que os clientes invocam transacções, i.e., sequências de

uma ou mais operações ordenadas de forma a que cumpram as propriedades ACID (Gray &

Reuter (1992)), cumprem a propriedade de one-copy serializability (Papadimitriou (1979); Sch-

neider (1990)) para garantir consistência forte. Segundo esta propriedade, do ponto de vista

do cliente, uma transacção aplicada num objecto replicado deve ter os mesmos efeitos de uma

transacção aplicada num único objecto não replicado. A propriedade de one-copy serializability


é semelhante à propriedade de consistência sequencial. A diferença entre as duas proprieda-

des é de que a segunda propriedade não contempla o conceito de agregação de operações em

transacções.

2.2.2.3 Abordagens para Replicação

Nesta secção apresentam-se duas abordagens distintas para replicação. A primeira abordagem

designa-se como replicação passiva, na qual os clientes comunicam com uma réplica distinta.

Pelo contrário, na segunda abordagem, replicação activa, os clientes comunicam por difusão

com múltiplas réplicas.

2.2.2.3.1 Replicação Passiva

Figura 2.2: Modelo de Replicação Passiva

No modelo de replicação passiva existe uma RM primária e as restantes RM funcionam como

cópias de segurança. Os FE comunicam apenas com a RM primária para enviar um pedido.

Por sua vez, a RM primária executa o serviço e envia a informação actualizada para as cópias

de segurança. No caso de falha da RM primária, uma das cópias de segurança assume o seu

papel.

Em geral, o procedimento executado após um pedido dum cliente contém cinco fases (Couloris

et al. (2005)):

1. Pedido: o FE envia o pedido, contendo um identificador único, para a RM primária.

2. Coordenação: a RM primária processa cada pedido atomicamente, na ordem pela qual os

recebeu. Verifica para cada um deles, através do identificador, se já tinha executado esse

pedido anteriormente e em caso positivo reenvia imediatamente a resposta previamente

memorizada para o FE.

3. Execução: a RM primária executa o pedido e guarda o resultado.


4. Acordo: Se o pedido é um operação de modificação dos dados, então a RM primária en-

via o estado modificado, a resposta e o identificador do pedido para todas as cópias de

segurança. Após receberem a mensagem, as cópias de segurança enviam uma mensa-

gem de confirmação.

5. Resposta: a RM primária responde para o FE, que envia a resposta para o cliente.

Este modelo cumpre a propriedade de linearidade se a RM primária for correcto (Couloris et al.

(2005)). No caso de a RM primária falhar, o sistema mantém a linearidade se a RM primária

for substituı́do por uma única cópia de segurança, e as RM que não falharam chegarem a um

acordo sobre quais operações foram executadas até ao momento de falha da RM primária.

Este modelo de replicação consegue tolerar f falhas de omissão se no total tiver f+1 RM. No

entanto, não consegue tolerar falhas bizantinas porque os FE recebem a resposta apenas da

RM primária, que pode sofrer falhas bizantinas. Para se tolerar falhas bizantinas, os FE teriam

receber a resposta directamente de 2f+1 RM (Couloris et al. (2005)). O modelo de replicação

activa usa essa abordagem.

2.2.2.3.2 Replicação Activa

Figura 2.3: Modelo de Replicação Activa

Neste modelo de replicação as RM funcionam como máquinas de estado, tal como na abor-

dagem do modelo de replicação passiva. Ao contrário da replicação passiva, onde se tem um

RM com papel primário, todos as RM têm o mesmo papel.

Em relação aos FE, assume-se que apenas podem sofrer apenas falhas de omissão. Os FE

difundem os pedidos dos clientes para o grupo das RM através de um mecanismo de difusão de

fiável com ordem total. Todas as RM processam o pedido independentemente e devolvem a sua


resposta para o FE. Os FE apenas enviam um pedido quando recebem a resposta do pedido

anterior.

O momento em que o FE envia a resposta para o cliente, depende das falhas que se pretende

tolerar segundo o modelo de falhas. No caso de se pretender tolerar apenas falhas de omissão,

o FE envia a primeira resposta que receber de uma RM para o cliente. Para tolerar falhas

bizantinas, o FE espera por f+1 respostas iguais das RM e só depois envia essa resposta para o

cliente. A primeira opção permite o sistema obter um melhor desempenho em relação à segunda

opção.

O procedimento executado após o pedido de um cliente é constituı́do por quatro fases:

1. Pedido: O FE atribui um identificador único ao pedido e difunde-o para o grupo de RM.

2. Coordenação: O pedido é entregue, através da primitiva de difusão, a todos as RM correc-

tos na mesma ordem total.

3. Execução: Todos as RM executam o pedido. Todos os pedidos são processados da mesma

forma, devido ao facto das RM funcionarem como máquinas de estado e os pedidos serem

entregues com a mesma ordem total.

4. Resposta: Cada RM envia a resposta, que contém o identificador do pedido, para o FE.

Com este modelo é possı́vel tolerar tanto falhas de omissão, desde que existam pelo menos um

RM funcional, assim como falhas bizantinas. Para tolerar f falhas bizantinas é necessário que

existam no mı́nimo 2f+1 RM no total.

Este modelo implementa consistência sequencial. Isto deve-se ao facto de que o mecanismo de

difusão fiável com ordem total garante que todos as RM correctos processam o mesmo conjunto

de pedidos da mesma forma que uma única cópia correcta faria.

Schneider (1990) descreve um sistema sı́ncrono, no qual, as RM processam pedidos numa

ordem total baseada em carimbos temporais fı́sicos atribuı́dos pelos FE que processaram esses

pedidos. No entanto, este sistema continua a não ser linearizável porque os carimbos temporais

fı́sicos atribuı́dos aos pedidos não têm uma precisão perfeita.

2.2.3 Replicação Activa com Partições de Rede

Os sistemas de replicação que sejam usados em ambientes móveis fracamente ligados devem

considerar a possibilidade da existência de partições de rede, que são comuns nesses cenários.


Uma partição de rede separa o grupo de RM em dois ou mais subgrupos, de forma a que

elementos do mesmo subgrupo possam comunicar entre si, mas elementos de diferentes sub-

grupos não possam comunicar entre si.

Algures no tempo as partições serão reparadas. Assim, as RM de uma partição ao executarem

um pedido necessitam de garantir que quando essa partição for reparada, o conjunto total de

RM não ficará inconsistente.

Davidson et al. (1985) discute diferentes abordagens para resolver este problema. Estas abor-

dagens são categorizadas como sendo optimistas ou pessimistas.

As abordagens optimistas permitem a execução de pedidos em todas as partições, o que pode

levar a inconsistências entre partições. A maior disponibilidade para a execução de pedidos tem

como custo a oferta de apenas garantias de consistência fraca através da utilização de critérios

de correcção, tais como, eventual consistency.

As inconsistências entre partições são resolvidas quando as partições são reparadas.

As abordagens pessimistas limitam a disponibilidade do sistema mesmo quando não existem

partições. No entanto, conseguem prevenir inconsistências entre partições.

De seguida, abordarei dois esquemas de replicação (2.2.3.1 Cópias Disponı́veis com Validação

e 2.2.3.2 Métodos de Consenso através de Quóruns) que funcionam correctamente quando o

conjunto total de RM é dividido em subgrupos, devido à existência de partições de rede. O pri-

meiro esquema utiliza uma estratégia de replicação optimista, enquanto que o segundo esquema

utiliza uma estratégia de replicação pessimista.

2.2.3.1 Cópias Disponı́veis com Validação

O algoritmo de cópias disponı́veis com validação (Couloris et al. (2005); Saito & Shapiro (2005))

utiliza a abordagem de replicação optimista. Esta abordagem permite que sejam executados

pedidos de clientes em qualquer partição independentemente do número de RM na partição.

A execução de pedidos em qualquer partição pode originar inconsistências entre as várias

partições, que são resolvidas quando uma partição é recuperada.

Quando uma partição é recuperada, os possı́veis pedidos que ocorreram em partições distintas

são validados. No caso de pares de pedidos conflituosos terem sido confirmados em diferen-

tes partições, um dos pedidos terá de ser abortado. Quando o pedido que foi confirmado é

abortado, são necessárias alterações no estado dos objectos. Este algoritmo permite que, em

certos perı́odos de tempo, o estado das réplicas esteja inconsistente, e com a recuperação das

partições o estado dessas réplicas passe ser consistente. A utilização deste algoritmo garante


consistência fraca nos dados do sistema replicado e cumpre o critério de correcção de eventual

consistency.

Esta abordagem não é aplicável em muitas situações reais, como por exemplo o caso de con-

tas bancárias, onde a replicação optimista pode levar a saldos negativos. Nestas situações é

necessário garantir consistência forte nos dados do sistema replicado.

2.2.3.2 Métodos de Consenso através de Quóruns

O algoritmo de consenso através de quóruns utiliza a abordagem pessimista. Este algoritmo

permite que partições com número suficiente de RM possam tomar tomar decisões mantendo a

consistência forte do sistema.

RM em diferentes partições de rede não podem comunicar com outras RM de outras partições.

Como tal necessitam de conseguir tomar decisões quanto à possibilidade de execução de pedi-

dos apenas com as RM da sua partição. Uma partição com um número suficiente de RM para

poder executar operações chama-se quórum.

Os pedidos só devem ser executados em réplicas frescas, ou seja, com o estado actual. Para

determinar a frescura de uma réplica aplica-se carimbos temporais ou números de versão (Cou-

loris et al. (2005)).

Gifford (1979) desenvolveu um sistema de replicação de ficheiros onde um número de votos é

atribuı́do a cada cópia fı́sica de um RM de um único ficheiro lógico. Cada operação de leitura

precisa de obter um quórum de R votos antes de ser executada. O mesmo se aplica a operações

de escrita que necessitam de um quórum de W votos para serem executadas. R e W são um

conjunto de votos tal que:

• W > metade do total de votos;

• R + W > total de número de votos para o grupo;

Esta construção assegura que qualquer par de quóruns W e R, ou qualquer par de quóruns W,

contêm obrigatoriamente cópias fı́sicas em comum. Existem outras distribuições possı́veis de

quóruns (Peleg & Wool (1995)), que não abordaremos neste documento.

Para executar um operação de leitura, ao obter um quórum R, obrigatoriamente se obtém um

quórum que intersecta com todos os quóruns W e desta forma é assegurado que R contém pelo

menos uma cópia com o valor mais actual.

Quando se executa uma operação de escrita, ao obter um quórum W, copia-se o estado da

cópia mais actual do quórum para as cópias com estado desactualizado e de seguida aplica-se


a operação de escrita a todas as cópias.

As operações de leitura/escrita podem ser feitas com o uso de trincos, de forma a controlar a

concorrência. Sempre que se obtém um quórum R ou W é efectuado um trinco a todos as RM

do quórum. A libertação dos trincos e a execução de pedidos são feitos segundo um protocolo

de confirmação atómica (e.g. em 2 fases).

2.3 Protocolos Epidémicos de Quóruns

Os protocolos de quóruns clássicos descritos na secção anterior têm limitações quando aplica-

dos em redes móveis e fracamente ligadas. Essas limitações devem-se ao facto de este tipo de

protocolos necessitarem de um quórum de réplicas vivas, simultaneamente conectadas numa

mesma partição de rede. No fundo os protocolos clássicos consideram que as partições são

possı́veis mas raras e curtas. Estes requisitos são inadequados para redes móveis e fracamente

ligadas porque neste tipo de redes é comum a existência de partições e a inacessibilidade de

parte dos processos.

Os protocolos epidémicos de quóruns adequam-se às caracterı́sticas de redes móveis e fraca-

mente ligadas porque funcionam com quóruns desconectados.

Nas próximas duas secções irei descrever dois protocolos epidémicos de quóruns que utilizam

como técnica base a propagação epidémica de informação e assumem um sistema assı́ncrono.

2.3.1 Keleher et al.

Em Keleher (1999) é descrito um protocolo, Deno, onde a propagação da informação é feita

de forma epidémica. Esta caracterı́stica faz com que a existência de um quórum simultanea-

mente ligado deixe de ser requisito para o sistema, o que é desejável para ambientes móveis e

fracamente ligados.

Neste protocolo o cliente envia o seu pedido (operação de escrita ou leitura) para qualquer

réplica que encontre acessı́vel. Na eventualidade de pedidos concorrentes, Deno decide qual

pedido será confirmado, i.e., aplicado ao objecto lógico, através de eleições. Os candidatos de

uma eleição são as réplicas que receberam um pedido directamente de um cliente. Uma réplica

torna-se num candidato ao votar nela própria. Todas as réplicas podem votar num candidato e

os votos não são revogáveis. O candidato que ganhar a eleição terá o pedido que recebeu de um

cliente confirmado, enquanto que os candidatos que perdem terão os seus pedidos abortados.

O objecto lógico tem um peso fixo de 1, que é distribuı́do pelas suas réplicas. A percentagem

2.3. PROTOCOLOS EPIDÉMICOS DE QUÓRUNS 21

de peso que é alocado para cada réplica constitui o poder de voto da réplica. O peso de voto de

cada réplica é variável, o que permite que existam réplicas com maior poder de voto em relação

a outras réplicas. A soma do peso variável de todas as réplicas neste protocolo é sempre igual

a 1.

As eleições são feitas de forma descentralizada. Através da propagação epidémica da informação

relativa ao voto de cada réplica, cada réplica decidirá qual candidato ganha a eleição assim que

tomar conhecimento de votos suficientes. Para uma réplica decidir que um candidato ganhou

a eleição é necessário que este tenha a maioria relativa dos votos, i.e., com os votos que esse

candidato tem é impossı́vel que outro candidato possa obter maioria relativa. Mais precisamente,

para que uma réplica A decida eleger um candidato C1 necessita de que a seguinte condição

seja verdadeira:

∀Ci 6=C1 votosA(C1) > votosA(Ci) + desconhecidosA

• votosA(Ci): peso total de votos conhecidos pela réplica A no candidato i;

• desconhecidosA: peso total de votos cujo o seu valor (candidato) é desconhecido pela

réplica A;

A determinação do candidato que ganha a eleição é feita individualmente por cada réplica, tendo

por base apenas os votos que essa réplica tomou conhecimento, através da troca de informação

com outras réplicas.

Este protocolo assegura consistência sequencial. Todas as réplicas confirmam a mesma sequência

de pedidos e os clientes apenas podem propor novos pedidos quando obtêm resposta sobre a

confirmação ou não do seu último pedido. Logo será impossı́vel confirmar os pedidos numa

ordem que não respeite a ordem com que o cliente propôs os seus pedidos.

A propagação epidémica de informação assegura que todas réplicas tomarão as mesmas de-

cisões para todas as eleições. As réplicas propagam para outras réplicas informações que

incluem:

• Resultados de eleições já terminadas;

• Votos conhecidos para a eleição actual. No caso de uma réplica ainda não ter votado na

eleição actual, copia o voto da réplica que lhe enviou a informação.

No Algorithm 1 apresenta-se o pseudocódigo de Deno com apenas uma eleição. Cada réplica

mantém como estado:


• voto votos[]: cada posição votos[Rn] contém o voto conhecido da réplica n num candidato

j, Rj .

• N: número total de réplicas.

Algorithm 1 Pseudocódigo de Deno

1: Executado quando cliente c propõe o pedido op2: function propor(pedido op)3: while true do4: Escolher uma réplica Ri acessı́vel5: if clienteEnvia(Ri, op) then6: break;7: end if8: end while9: ————————————————————————————————————————–

10: Executado por Ri11: function clienteEnvia(replica Ri, pedido op)12: if Ri.votos[Ri] != ⊥ then13: return false;14: else15: Ri.votos[Ri] = Ri;16: return true;17: end if18: ————————————————————————————————————————–

19: Executado por todas as réplicas para trocarem informação com outra réplica20: function envioInfo()21: Réplica Rj escolhe uma réplica acessı́vel Ri22: replicaEnvia(Ri, Rj .votos[]);23: ————————————————————————————————————————–

24: Réplica Ri recebe votos conhecidos pela réplica Rj25: function replicaEnvia(réplica Ri, list votos[])26: for all votos[Rw] != ⊥ in votos[] do27: if Ri.votos[Rw] == ⊥ then28: Ri.votos[Rw] = votos[Rw];29: end if30: end for31: if Ri.votos[Ri]==⊥

∧votos[Rj ]!=⊥ then

32: Ri.votos[Ri]= votos[Rj ]33: end if34: pedido op = maioria relativa(Ri.votos[]);35: if if(op != ⊥) then36: commit(op);37: end if

Nas Figuras 2.4 a 2.6 ilustra-se um exemplo do funcionamento do protocolo de Deno com apenas

uma eleição e com o peso de voto de cada réplica igual. Neste exemplo tem-se dois clientes, 1

e 2, e três réplicas, R1, R2 e R3.


Na Figura 2.4 o cliente 1 envia o seu pedido para R1 e o cliente 2 envia o seu pedido para R2.

Ambas as réplicas não votaram em nenhum pedido e como tal tornam-se candidatas votando

nelas próprias.

Cliente1 R1

R1

Cliente2R2

R2

R3

x y

Figura 2.4: Exemplo protocolo Deno, parte 1

Supondo que a R1 encontra R3 acessı́vel, R1 envia os votos que conhece para R3. R3 como

ainda não votou em nenhum candidato, copia o voto de R1 e actualiza o voto conhecido de R1,

tal como na Figura 2.5. Neste momento, R3 conclui que o candidato R1 tem a maioria relativa

dos votos e como tal pode confirmar localmente o pedido de R1.

Cliente1 R1

R1

Cliente2R2

R2

R3 R1 R1


A Figura 2.6 ilustra o estado final de todas as réplicas após trocarem informação entre si. Como

se pode verificar, todas as réplicas elegem o mesmo candidato, R1. Logo, confirmam localmente

o pedido proposto por R1, e abortam o pedido proposto por R2.

Cliente1 R1

R1 R2 R1

Cliente2R2

R1 R2 R1

R3 R1 R2 R1


Suponha-se agora que R3 é uma réplica bizantina. R3 poderia comunicar informações falsas

às restantes réplicas. No exemplo da Figura 2.7, R3 comunica a R1 que R3 e R2 votaram no


candidato R2 e R3 comunica a R2 que R3 e R1 votaram no candidato R1. Suponha-se ainda

que R1 e R3 não comunicavam entre si.

Cliente1 R1

R1

Cliente2R2 R2

R3 R2 R2

R1 R1

Figura 2.7: Exemplo protocolo Deno com réplica bizantina, parte 1

Após as réplicas R1 e R2 receberem as informações falsas de R3, R1 e R2 actualizam os

seus votos conhecidos. Como se pode verificar pela Figura 2.8, R1 e R2 elegem candidatos

diferentes, o que provocaria um estado inconsistente do sistema.

Cliente1 R1

R1 R2 R2

Cliente2R2

R1 R2 R1

R3 R2 R2

R1 R1

Figura 2.8: Exemplo protocolo Deno com réplica bizantina, parte 2

Como se pode verificar com o exemplo anterior, o protocolo Deno não tolera a existência de

réplicas bizantinas, cuja existência das mesmas põe em causa a consistência do sistema.

2.3.2 Holliday et al.

Em Holliday et al. (2003) é descrito um protocolo que segue a mesma abordagem de Deno.

Ambos os protocolos usam a técnica de propagação epidémica de informação. No entanto,

no caso de Holliday et al. (2003) assegura-se serialização de transacções enquanto em Deno

apenas é assegurado serialização de operações individuais.

No protocolo epidémico de Holliday et al. (2003) as transacções são serializadas segundo a

ordem causal entre elas e é garantido que, para cada par de transacções conflituantes, no

máximo uma é confirmada (e a outra abortada). Cada réplica poderá votar sim ou não para


cada transacção e nunca vota sim para duas transacções conflituantes.

A definição de quórum usada neste protocolo considera que um quórum é constituı́do por uma

maioria do total de réplicas no sistema e todos os quóruns se intersectam entre si. Desta forma,

quando uma transacção recebe um quórum de votos sim é confirmada.

Um novo conceito introduzido em Holliday et al. (2003) é o de antiquorum. Um antiquorum con-

siste num conjunto de réplicas que intersecta com todos os quóruns. Como consequência, basta

uma transacção adquirir um voto não de um antiquórum e essa transacção será abortada por-

que já não será possı́vel adquirir um quórum de votos sim. Adicionalmente, se uma transacção

ganhar a maioria dos votos e for confirmada, então as restantes transacções conflituantes com

ela são abortadas.

Uma transacção sobre a qual ainda não foi tomada a decisão de ser abortada ou confirmada

diz-se incerta. Para preservar a causalidade, quando uma transacção t é processada por uma

réplica, essa réplica atribui trincos de escrita aos dados que t precisa de escrever e t executa

a operação sobre os dados da réplica antes de ser processada outra transacção posterior. No

entanto, uma transacção conflituante de t poderia ser processada noutra réplica e ter modificado

os mesmos dados que t alterou. Estando essas transacções incertas, nenhuma delas pode

ser confirmada até que alguma delas obtenha um quórum. A solução para este caso passa por

garantir que nenhuma das transacções incertas aplica as suas operações nos dados, e nenhuma

transacção posterior acede a esses mesmos dados, até que uma das transacções incertas seja

confirmada e as restantes abortadas. Para ser possı́vel transacções incertas obterem trincos

de escrita nos mesmos dados é usado um tipo especial de trincos definido como trincos de

intenção de escrita, IW (Bernstein & Newcomer (1997)). Este tipo de trinco tem conflito com

todos os outros tipos de trincos excepto com trincos IW.

Quando um transacção t é recebida por uma réplica r, r inicia uma transacção remota que ad-

quire IW em todos os dados que t iria escrever e faz uma pré-confirmação. Com este procedi-

mento, todas as transacções posteriores não podem aceder a esses dados protegidos por um

IW. No entanto, transacções incertas podem adquirir IW nos mesmo dados e também fazer uma

pré-confirmação. Por fim, no momento em que uma transacção incerta obtiver um quórum de

votos, essa transacção é confirmada. Consequentemente converte todos os seus IW em trincos

de escrita, aplica as suas operações nos dados e liberta todo os seus trincos.

Um ponto negativo de Holliday et al. (2003) é o de não garantir a propriedade de one-copy

serializability. Isto deve-se à possibilidade de transacções de apenas leitura serem processadas

em diferentes réplicas e poderem observar dados que são inconsistentes com a ordem global

de serialização. Ou seja, existe a possibilidade de um cliente obter dados inconsistentes com


uma operação de leitura.

Por fim, outro ponto negativo de Holliday et al. (2003) é o de não tolerar falhas bizantinas. Como

no exemplo dado para Deno, uma réplica bizantina pode votar sim em duas transacções confli-

tuantes. Como consequência, podem ser confirmadas duas transacções conflituantes e originar

réplicas com um estado inconsistente.

2.4 Tolerância a Falhas Bizantinas

Em todos os protocolos que serão descritos, assume-se: um número limitado de servidores

ou réplicas com falhas bizantinas, um número ilimitado de clientes com falhas bizantinas e um

sistema assı́ncrono.

Em todos os protocolos descritos nesta área, com excepção de Martin & Alvisi (2006), é usada

a técnica de assinatura digital de mensagens (Rivest et al. (1983)). Todos os servidores correc-

tos possuem uma chave privada apenas conhecida pelo próprio servidor e conhecem todas as

chaves públicas de cada servidor. Um servidor para assinar uma mensagem: (i) cria um resumo

criptográfico da mensagem usando um algoritmo de criação de resumos (ex. Rivest (1992)); (ii)

cifra o resumo com a sua chave privada usando um algoritmo de criptografia assimétrica (Rivest

et al. (1983)); (iii) junta à mensagem original o resumo cifrado. Quando um servidor recebe

uma mensagem assinada, usa a chave pública do servidor emissor da mensagem, para decifrar

o resumo cifrado, e depois usa o mesmo algoritmo de criação de resumos, para criar um re-

sumo criptográfico da mensagem recebida. Se o resumo criptográfico obtido for igual ao resumo

recebido, significa que o conteúdo da mensagem não foi alterado. Desta forma é garantida a

integridade da mensagem. A autenticidade da mensagem é garantida porque a chave privada

apenas é conhecida pela réplica emissora da mensagem e a correspondente chave pública

apenas decifra mensagens cifradas por uma única chave privada. Em Martin & Alvisi (2006)

são usadas ligações autenticadas, ou seja, o receptor de uma mensagem sabe quem emitiu a

mensagem.

Todos os protocolos que serão descritos nesta secção não utilizam a técnica de propagação

epidémica de informação utilizada pelos protocolos epidémicos de quoruns.

Na próxima secção 2.4.1 será descrita a abordagem de máquina de estados para tolerância

de falhas bizantinas. Na secção 2.4.2 será descrito um protocolo que segue a abordagem de

quóruns para tolerância a falhas bizantinas. Por fim, na secção 2.4.3 será descrito um protocolo

de consenso binário com tolerância a falhas bizantinas.

2.4. TOLERÂNCIA A FALHAS BIZANTINAS 27

2.4.1 Protocolos com Abordagem de Máquina de Estados

Os protocolos que seguem a abordagem de máquina de estados (Lamport (1978); Schneider

(1990)) permitem modelar um serviço como uma máquina de estados e replicá-la emn réplicas.

Essas réplicas mantêm o estado do serviço e implementam as operações do serviço. Adicional-

mente, este tipo de protocolos tolera a existência de um número limitado de réplicas com falhas

bizantinas.

As propriedades que a maioria dos protocolos deste tipo garantem são: (i)linearidade ,i.e., o

serviço replicado comporta-se como uma implementação centralizada que executa operações

atomicamente, tal como na Replicação Passiva; (ii) terminação, i.e., os clientes recebem algures

no tempo a resposta de execução do seu pedido.

Para garantir a propriedade de linearidade é necessário que uma parte do total das réplicas do

sistema esteja contactável durante as operações de cada protocolo. Em Castro & Liskov (2002);

Kotla et al. (2010) é necessário que mais de 2/3 das réplicas do sistema estejam simultanea-

mente acessı́veis e em Martin & Alvisi (2006) é necessário que mais de 4/5 das réplicas estejam

simultaneamente acessı́veis em algumas das operações. Este requisito de acessibilidade si-

multânea de parte das réplicas não é adequado para ambientes móveis e fracamente ligados.

A razão deste facto é a de que a mobilidade das réplicas pode provocar partições de rede que

impossibilitam a comunicação com parte das réplicas.

Os protocolos que se descrevem de seguida conseguem tolerar até f falhas bizantinas de réplicas,

desde que existam no total n, um mı́nimo de 3f+1 réplicas. A razão para este número total de

réplicas é a de ser necessário que o sistema possa evoluir depois de comunicar com n-f réplicas,

porque f réplicas podem ser faltosas e não estar a responder. No entanto, existe a possibilidade

de que as f réplicas referidas sejam correctas e apenas estejam atrasadas no envio da sua

resposta. Neste caso, as f réplicas bizantinas encontram-se no conjunto de réplicas n-f. As-

sim torna-se necessário que exista um número suficiente de réplicas correctas a responder no

conjunto de n-(f+f). Desta forma obtemos que n-2f>f, ou seja, n> 3f.

2.4.1.1 Pratical Byzantine Fault Tolerance

Em Castro & Liskov (2002) é descrito um protocolo de replicação com tolerância a falhas bizan-

tinas, PBFT, que evolui segundo uma sucessão de vistas. Uma vista identifica qual réplica é

considerada primária e considera as restantes réplicas como secundárias. A mudança de vista

ocorre quando a réplica primária é suspeita de ter uma falha bizantina.

Este protocolo usa três fases para que as réplicas executem um pedido do cliente:


1. Cliente envia pedido m, assinado com a sua chave privada, para a réplica primária. De

seguida, a réplica primária atribui um número de sequência n ao pedido e difunde-o junta-

mente com o número de vista actual, v, pelas réplicas secundárias;

2. Após receberem a mensagem da réplica primária, as réplicas secundárias difundem a

mensagem pelas restantes réplicas secundárias. As réplicas secundárias reúnem mensa-

gens provenientes de outras réplicas secundárias, até terem um conjunto de 2f+1 mensa-

gens iguais provenientes de réplicas diferentes. O PBFT garante que não poderá coexistir

outro conjunto de mensagens com o mesmo tamanho, 2f+1, número de sequência, n, e

vista, v, mas com m diferente. Supondo que cada elemento das f réplicas bizantinas en-

via duas mensagens diferentes, m e m’, com o mesmo n e v, e que f réplicas correctas

(3f+1 - (2f+1)) enviam também m’ com n e v, no máximo m’ irá ter um conjunto total de 2f

mensagens iguais provenientes de réplicas diferentes.

3. Todas as réplicas (incluindo a primária) difundem uma mensagem de confirmação con-

tendo o número de sequência e o pedido. Cada réplica após receber essa mensagem

de 2f+1 réplicas, incluindo a própria réplica, executa o pedido e enviam a resposta para

o cliente. Quando uma réplica tem um conjunto de 2f+1 mensagens de confirmação, tal

significa que pelo menos f+1 réplicas correctas vão executar o pedido.

No caso de o cliente não receber respostas suficientes ao seu pedido, f+1, dentro de um determi-

nado perı́odo de tempo, este reenvia as mensagens para todas as réplicas, em vez de enviar só

para o primário. Desta forma as réplicas podem suspeitar do comportamento da réplica primária

e proceder a uma mudança de vista que utilizará uma réplica diferente como primária.

2.4.1.2 Zyzzyva

Em Kotla et al. (2010), tal como em PBFT descreve-se um protocolo de replicação tolerante

a falhas bizantinas para um sistema assı́ncrono, chamado Zyzzyva. Em relação a PBFT, a

principal diferença é a de conseguir acordo na ordem de execução de um pedido nas réplicas

correctas em duas fases de comunicação no pior caso e em uma fase de comunicação no melhor

caso (Singh et al. (2008)), enquanto que o PBFT exige sempre duas fases de comunicação.

Para este protocolo não precisar das três fases já referidas, as réplicas ao receberem o pedido

da réplica primária aceitam optimisticamente a ordem proposta pelo primário. Assim, as réplicas

quando recebem um pedido do cliente, executam o pedido de forma especulativa e enviam a

resposta para o cliente. Como consequência, uma réplica primária bizantina pode, por exemplo,

enviar pedidos diferentes para diferentes réplicas secundárias e fazer com que o estado das


réplicas secundárias correctas possa divergir e como resultado as respostas enviadas para o

cliente serem inconsistentes. A solução usada para resolver este problema passa por incluir

nas respostas informação acerca da execução (inclui número de sequência, identificador cliente

e pedido), que o cliente usará posteriormente para decidir se essa execução especulativa é

correcta ou não. Em caso positivo, o cliente aceita a resposta que recebeu. Em caso negativo,

o cliente reúne provas do comportamento errado da réplica primária, por exemplo dois pedidos

diferentes com o mesmo número de sequência, e envia para todas as réplicas para mudarem de

réplica primária.

A grande diferença de Zyzzyva em relação aos restantes protocolos de tolerância a falhas bizan-

tinas é o uso da técnica de execução especulativa. Nesta técnica o cliente tem as responsabili-

dades de detectar estados inconsistentes nas réplicas secundárias. O detector de falhas usado

que reúne provas sobre o comportamento de uma réplica bizantina, foi útil para a construção do

novo protocolo.

2.4.1.3 Fast Byzantine Paxos

Em Martin & Alvisi (2006) é descrito um protocolo de replicação tolerante a falhas bizantinas,

Fast Byzantine Paxos, para um sistema assı́ncrono tal como em Castro & Liskov (2002); Kotla

et al. (2010). Este protocolo foi o primeiro protocolo proposto a conseguir acordo na ordem de

execução de um pedido em uma fase de comunicação no melhor caso (Martin & Alvisi (2006)).

O que diferencia este protocolo dos restantes é a utilização de uma arquitectura que separa

fisicamente o grupo de réplicas responsável por ordenar os pedidos dos clientes do grupo de

réplicas que executa os pedidos já ordenados.

Este protocolo define três classes de réplicas, sendo que uma réplica poderá ter várias classes:

(i) proponentes, responsáveis por propor valores; (ii) aceitadoras, responsáveis por escolher um

único valor dos propostos; (iii) aprendizes, responsáveis por aprender o valor escolhido. Cada

classe pode conter no máximo f réplicas com falhas bizantinas. Para essas f falhas bizantinas

serem toleradas, deverão existir nas classes de proponentes e aprendizes 3f+1 réplicas, e na

classe de aceitadores 5f+1 réplicas.

Tal como nos restantes protocolos de replicação com tolerância a falhas bizantinas, neste pro-

tocolo também é definida uma réplica primária (ou lı́der). Neste caso a réplica primária é eleita

de entre a classe de réplicas proponentes, tendo a função de propor valores para a classe de

réplicas aceitadoras. No caso da réplica lı́der ser correcta e as mensagens enviadas por cada

réplica não serem perdidas, o protocolo consegue que as réplicas aprendizes correctas apren-

dam o valor proposto pelo lı́der correcto. Tal acontece em duas fases:


1. A réplica lı́der envia a sua proposta para as réplicas aceitadoras. A proposta é conside-

rada escolhida quando pelo menos 3f+1 réplicas aceitadoras aceitarem esse valor. Estas

réplicas aceitam o primeiro valor que lhes é proposto.

2. As réplicas aceitadoras enviam o valor aceite para as réplicas aprendizes. As réplicas

aprendizes aprendem o valor recebido se receberem esse valor de pelo menos 4f+1 réplicas

aceitadoras. Outra forma de as réplicas aprendizes aprenderem valores consiste em en-

contrar um valor aprendido por f+1 aprendizes. Desta forma têm a garantia que é um valor

aprendido por réplicas correctas e por isso podem aprender esse valor também.

O Fast Byzantine Paxos usa um mecanismo de retransmissão para os caso de perda de men-

sagens. Este mecanismo consiste em enviar mensagens de confirmação de aprendizagem, por

parte das réplicas aprendizes, para as réplicas proponentes (incluindo a réplica lı́der). O com-

portamento por parte da réplica lı́der é a de reenviar a sua proposta até receber no mı́nimo

2f+1 mensagens de confirmação, porque ao receber 2f+1 mensagens tem a garantia de que f+1

réplicas aprendizes correctas aprenderam o valor. Em relação às restantes réplicas proponen-

tes, se não receberem suficientes mensagens de confirmação até um determinado perı́odo de

tempo, suspeitam do comportamento da réplica lı́der e procedem à mudança de lı́der.

Quando uma réplica proponente é eleita para lı́der, três casos podem ter ocorrido:

1. O conjunto de réplicas aceitadoras escolheu algum valor através do lı́der anterior. Nesse

caso o novo lı́der propõe esse valor até ser aprendido;

2. O lı́der anterior era bizantino e realizou uma escrita venenosa (Castro & Liskov (2002)). No

caso da escrita venenosa, o novo lı́der reúne provas dessa escrita e envia para as réplicas

aceitadoras juntamente com o novo valor a propor.

O ponto negativo deste protocolo é o requisito da utilização de 5f+1 réplicas para a classe de

aceitadores para permitir que no melhor caso seja apenas necessário uma fase de comunicação.

2.4.2 Survivable Consensus Objects

Em Malkhi & Reiter (1998b) é descrito um protocolo que decide quais operações, solicitadas por

um número desconhecido de clientes, deverão ser aplicadas a um objecto lógico, na presença

de um número máximo de b réplicas bizantinas. O objecto lógico é replicado por um conjunto de

réplicas que pertencem a um sistema definido como um b-masking quórum Q (Malkhi & Reiter

(1998a)) conhecido por todas as réplicas e clientes. Q é constituı́do por subconjuntos de réplicas

qi (i=1, ... , n) definidas como quóruns que cumprem as seguintes condições:


• ∀q1,q2 ∈ Q :| q1 ∩ q2 |≥ 2b+ 1;

• ∃qi ∈ Q, tal que : ∀conjunto de réplicas bizantinas ∩ qi = ∅;

A primeira condição permite que seja possı́vel ao cliente inferir as respostas provenientes de

réplicas correctas. Esta condição obriga a que todos os quóruns se intersectem em pelo menos

2b+1 réplicas o que implica que no mı́nimo um quórum tenha 2b+1 réplicas. Por consequência,

sempre que se obtém respostas de um quórum é possı́vel distinguir as respostas provenientes

de réplicas correctas, escolhendo respostas repetidas b+1 vezes (existem no máximo b réplicas

bizantinas).

A segunda condição impede que exista algum conjunto de servidores com falhas bizantinas que

intersecte com todos os quóruns. Com esta restrição o cliente conseguirá sempre contactar um

quórum sem servidores bizantinos (Malkhi & Reiter (1998a)).

Numa visão geral do funcionamento deste protocolo, os clientes propõem valores inserindo-os

em vectores lógicos que estão associados a cada cliente e replicados em cada servidor. Após

a execução do protocolo de consenso é retornado um único valor decidido a todos os clientes.

Cada cliente apenas pode inserir valores no seu vector lógico e todos os clientes podem ler

todos os valores de todos os vectores lógicos. Intuitivamente, estes vectores lógicos funcionam

como um método de comunicação seguro entre clientes.

Durante a execução do protocolo, cada cliente vai inserindo valores no seu vector lógico em

posições consecutivas, até que o protocolo decida que a sua última inserção contém o valor

decidido. Desta forma, o cliente inicia o protocolo inserindo na primeira posição do seu vector

lógico o seu valor pretendido. De seguida, o cliente faz uma leitura dos vectores de todos os

clientes e verifica qual é o maior número de inserção existente. Para esse número de inserção

máximo verifica quantos valores diferentes existem. Se existir apenas um valor, então esse valor

é o decidido. No caso de existir mais que um valor, o protocolo escolhe aleatoriamente um dos

valores que será posteriormente lido pelos clientes.

Para um cliente verificar qual foi o número de inserção máximo no sistema e de seguida obter

o conjunto de valores para esse número de inserção, o cliente contacta todos os elementos de

um quórum pedindo esses valores. Após receber os valores, o cliente apenas aceita aqueles

que forem repetidos pelo menos f+1 vezes, de forma a ter garantia que se tratam de valores

correctos.

Um cliente bizantino, neste sistema, não consegue fazer com que o protocolo de consenso

não funcione correctamente. A justificação é a de que não é possı́vel a um cliente bizantino

reconfigurar os valores dos seus vectores, de forma a que dois clientes correctos decidam em


valores diferentes. A caracterı́stica deste protocolo que previne esse ataque é o facto de nenhum

cliente poder modificar ou apagar valores do seu vector. Um cliente apenas pode inserir valores

no seu vector.

Este protocolo não garante que o algoritmo de consenso termina sempre, porque um cliente

bizantino pode fazer um ataque de negação de serviço. Para tal, basta um cliente bizantino

inserir constantemente valores diferentes, de forma a que o protocolo de consenso não termine.

Este protocolo de consenso tem a caracterı́stica muito interessante de ser possı́vel decidir um

valor sem que todos os clientes do sistema tenham de participar no protocolo. Essa carac-

terı́stica é muito importante em redes móveis porque grande parte do tempo muitos clientes

estão inacessı́veis.

2.4.3 Turquois

Em Malkhi & Reiter (1998b) é definido um assumido que dois processos comunicam através de

canais fiáveis ponto a ponto. Ou seja, as mensagens enviadas por processos correctos, para

processos correctos, são garantidamente entregues usando mecanismos de retransmissão (Malkhi

& Reiter (1998a)). No PBFT e Fast Byzantine Paxos é assumido que se um processo correcto

q envia uma mensagem m para outro processo correcto p um número infinito de vezes, então

m é recebida infinitamente vezes por p. Na prática esta caracterı́stica tem o mesmo efeito que

através de canais fiáveis ponto a ponto. Na perspectiva de ambientes móveis e fracamente li-

gados, a desvantagem destas abordagens é de forçarem a implementação de mecanismos de

entrega end-to-end (Saltzer et al. (1984)) (e.g., TCP). A construção deste tipo de mecanismos

sobre um meio de comunicação partilhada é ineficiente porque não permite a utilização do meio

de difusão das redes sem fios (Moniz et al. (2010)). Neste meio de comunicação, o custo de

transmitir uma mensagem para múltiplas réplicas é o mesmo de enviar para uma única réplica,

desde que essas réplicas estejam dentro do alcance de comunicação.

Em Moniz et al. (2010) é utilizado o modelo de falhas de comunicação de Santoro & Widmayer

(1989). Este modelo assume a existência de falhas de omissão de canais de comunicação

dinâmicas e transitórias. Ou seja, o conjunto de ligações com falhas de omissão pode mudar

a cada instante. Esta é uma caracterı́stica própria das redes de comunicação sem fios. Este

protocolo faz difusão de mensagens para todas as réplicas ao alcance aproveitando o meio de

difusão das redes sem fios.

O protocolo descrito em Moniz et al. (2010), Turquois, permite um conjunto de processos deci-

direm num valor binário 0 ou 1 igual para todos os processos desse conjunto. Adicionalmente

toleram a existência do seguinte número de falhas:

2.5. CONSIDERAÇÕES FINAIS 33

• f falhas bizantinas em processos num total de 3f+1 processos;

• σ falhas de omissão de canais ≤ d(n−t)/2e(n-k-t)+k-2 , onde k é o nº mı́nimo de processos

do total n que decidem um valor comum, e t o nº de processos que estão com falhas

bizantinas nesse momento.

Em cada tick do relógio de cada processo, o processo faz a difusão de uma mensagem que

contem o seu estado para todos os processos ao alcance . Quando um processo recebe uma

mensagem verifica a validade dessa mensagem. São feitos dois tipos de validação: autenti-

cidade e semântica. A primeira validação garante que alguns dos campos da mensagem são

realmente do processo identificado na mensagem. A segunda validação verifica se o conteúdo

da mensagem é congruente com a execução do algoritmo.

Quando um processo recebe uma mensagem válida, guarda essa mensagem. Depois com base

no seu estado e nas mensagem recebidas verifica se é possı́vel decidir num valor ou não.

O Turquois garante as seguintes propriedades:

• Validade: Se todos os processos propõem o mesmo valor v, então qualquer processo que

decida, decide em v.

• Acordo: Não é possı́vel existir dois processos correctos que decidam valores diferentes.

• Terminação: No mı́nimo k processos correctos decidem eventualmente com probabilidade

1.

Neste protocolo a difusão de mensagens ao longo das operações do protocolo é apenas para as

réplicas ao alcance da réplica, o que é apropriado para ambientes móveis e fracamente ligados.

2.5 Considerações Finais

Neste capı́tulo começou-se por introduzir os conceitos principais relacionados tolerância a falhas

e coordenação em

O protocolo Deno foi bom ponto de partida para atingir o consenso para ambientes móveis e

fracamente ligados relativo

No próximo capı́tulo será descrito em detalhe o funcionamento do protocolo eBFT, desenvolvido

durante a realização desta tese.

placeholder

Capı́tulo 3

Contribuições

Este capı́tulo apresenta o protocolo desenvolvido durante a realização desta tese de dissertação,epidemic Byzantine Fault Tolerance(eBFT). Este protocolo tolera um número limitado defalhas bizantinas nas réplicas. No caso de ocorrerem pedidos de clientes concorrentes, o eBFT

tenta decidir, através de eleições, um único pedido para ser confirmado em todas as réplicas,

sendo os restantes pedidos concorrentes abortados. O eBFT propaga informação sobre votos

e réplicas bizantinas detectadas de forma epidémica, i.e., sempre que uma réplica A encontra

outra réplica acessı́vel B, A envia o seu estado para B.

Por simplicidade, o protocolo eBFT é descrito como funcionando em apenas uma eleição. Para

estender o protocolo descrito para múltiplas eleições poderá ser seguido uma abordagem se-

melhante à proposta por Deno. Esta funcionalidade está fora do âmbito desta tese e poderá ser

desenvolvida como trabalho futuro.

Na Secção 3.1 é descrito o modelo de sistema assumido para o protocolo e na Secção 3.2 são

apresentadas de forma pormenorizada as caracterı́sticas do protocolo.

3.1 Modelo do Sistema

Por simplicidade e sem perda de generalidade nós assumimos que o sistema replica um único

objecto lógico. Este sistema pode ser estendido para um modelo onde mais que um objecto

é replicado por um determinado grupo de réplicas. Neste modelo é também assumido que a

comunicação é assı́ncrona.

Neste sistema são garantidas as seguintes propriedades do problema do consenso (Secção

2.2.1):

35

36 CAPÍTULO 3. CONTRIBUIÇÕES

• Acordo: O pedido(valor) decidido por todas as réplicas(processos) correctas é o mesmo;

• Integridade: O pedido decidido por uma réplica correcta foi obrigatoriamente proposto por

algum cliente.

O problema da consistência em sistemas replicados (Secção 2.2.2) está fora do âmbito deste

sistema.

O número mı́nimo total de réplicas, N, utilizado é de 3f+1, o que corresponde a um total mı́nimo

de 2f+1 réplicas correctas e a um total máximo de f réplicas bizantinas. Este N permite que

numa situação em que todas as réplicas correctas votam num candidato C1 e todas as réplicas

bizantinas votam num candidato diferente das correctas C2, seja possı́vel o candidato C1 ganhar

a eleição nas réplicas correctas, garantindo as propriedades referidas acima.

No instante de tempo em que o eBFT se inicia, todas as réplicas do sistema conhecem o número

total de réplicas do sistema. Esse valor poderá decrescer durante o funcionamento do eBFT com

a detecção de réplicas bizantinas, mas nunca poderá aumentar.

3.2 eBFT

Cada pedido proposto por um cliente(operação) é um candidato na eleição e cada réplica cor-

recta vota apenas num único candidato. Considerando o peso total de todos os votos igual a 1,

o peso de voto de cada réplica é igual a 1/N, onde N é o número total de réplicas. Tal como nos

PEQs existentes, cada réplica do eBFT pode votar em apenas um candidato e esse voto não

pode ser revogado. Através da propagação epidémica do estado de cada réplica, cada réplica

irá gradualmente ter conhecimento dos votos das restantes réplicas (tanto réplicas correctas

como réplicas bizantinas) e das réplicas bizantinas detectadas. Com base na informac�

tolerancia a falhas bizantinas em protocolos deˆ replicac ......cap´ıtulo 1 introduc¸ao˜ h oje...

Documents