Limitando Operac¸˜oes out de Clientes Faltosos

Os protocolos do BTS e do LBTS descritos neste cap´ıtulo permitem que clientes maliciosos insi- ram um n´umero ilimitado de tuplas fantasma no espac¸o. No caso do BTS n˜ao existe alterac¸˜ao poss´ıvel no protocolo que elimine esta limitac¸˜ao e mantenha as mesmas complexidade de mensagens e passos de comunicac¸˜ao do protocolo out (ver sec¸˜ao 4.5). Para o LBTS, no entanto, podemos utilizar justifi- cativas de escritas, de forma similar a usada em [80], para modificar o protocolo out visando limitar em 1 o n´umero de inserc¸˜oes incompletas que um cliente pode fazer.

O ponto central desta modificac¸˜ao ´e o uso de justificativas na inserc¸˜ao, de maneira similar `a usada nas reescritas. Uma justificativa de inserc¸˜ao ´e um conjunto contendo mensagens ACK-OUT assinadas provenientes de um qu´orum de servidores. Estas mensagens correspondem as respostas de uma requisic¸˜ao OUT para inserc¸˜ao de uma tupla. Cada inserc¸˜ao deve ter um n´umero de seq¨uˆencia provido pelo cliente. Cada servidor armazena o maior n´umero de seq¨uˆencia enviado por cada cliente em um vetor de contadores out count, com uma entrada para cada cliente. Para inserir uma nova tupla, o cliente precisa enviar uma mensagem OUT com um n´umero de seq¨uˆencia maior que o ´ultimo usado por ele, juntamente com uma justificativa de escrita contendo as respostas da ´ultima escrita completada (se essa n˜ao for a primeira). Um servidor aceita uma inserc¸˜ao (e executa o bloco com as linhas 3-6 do algoritmo 6) se o n´umero de seq¨uˆencia da requisic¸˜ao do cliente c for for maior que out count[c] e c apresentou uma justificativa contendo mensagens assinadas de um qu´orum de servidores para a inserc¸˜ao anterior (de n´umero de seq¨uˆencia out count[c]). Na primeira inserc¸˜ao, o cliente deve enviar um n´umero de seq¨uˆencia 1 e n˜ao precisa apresentar justificativa de inserc¸˜ao.

A principal implicac¸˜ao desta modificac¸˜ao ´e que ela requer que todas as mensagens ACK-OUT sejam assinadas pelos servidores. O uso de criptografia de chave p´ublica nestas assinaturas poderia elevar em muito a latˆencia da operac¸˜ao de escrita, especialmente em redes locais [22]. No entanto, podemos utilizar vetores de MACs da mesma forma que em [36] para implementar estas assinaturas. Desta forma, a justificativa de inserc¸˜ao ´e v´alida para um servidor s se e somente se ela cont´em q − f mensagens corretamente autenticadas para esse servidor (o campo com o MAC correspondente a este servidor est´a correto). Esta modificac¸˜ao praticamente elimina a latˆencia das assinaturas.

Outra implicac¸˜ao desta modificac¸˜ao ´e o requisito de canais FIFO entre os clientes e os servidores, o que n˜ao era necess´ario na vers˜ao original do LBTS.

Note a modificac¸˜ao para limitac¸˜ao das escritas de clientes maliciosos apresentada nesta sec¸˜ao pode ser implementada em uma camada subjacente do algoritmo de escrita do LBTS, n˜ao requerendo portanto nenhuma alterac¸˜ao no protocolo do algoritmo 6.

4.7

Trabalhos Relacionados

Existem duas t´ecnicas de replicac¸˜ao para a construc¸˜ao de servic¸os tolerantes a faltas bizantinas: sistemas de qu´oruns bizantinos [86] (ver sec¸˜ao 2.4.2) e replicac¸˜ao m´aquina de estados [36, 114] (ver sec¸˜ao 2.4.1). A primeira ´e uma abordagem centrada em dados e baseada na execuc¸˜ao de diferentes

operac¸˜oes em diferentes conjuntos de servidores que se intersectam (chamados qu´oruns), enquanto a segunda ´e baseada na manutenc¸˜ao de um estado consistente entre as v´arias r´eplicas do sistema atrav´es da execuc¸˜ao da mesma seq¨uˆencia de operac¸˜oes. Uma vantagem dos sistemas de qu´oruns em relac¸˜ao `a replicac¸˜ao M´aquina de Estados reside no fato de que suas operac¸˜oes n˜ao precisam ser executadas na mesma ordem em todos os servidores, n˜ao requerendo portanto a resoluc¸˜ao do problema de consenso. Adicionalmente, os protocolos para qu´oruns tendem a ser muito mais escal´aveis devido a oportuni- dade para concorrˆencia na execuc¸˜ao das operac¸˜oes e a mudanc¸a do trabalho de processamento mais pesado dos servidores para os processos clientes.

As construc¸˜oes apresentadas neste cap´ıtulo utilizam sistemas de qu´oruns bizantinos e provˆeem protocolos espec´ıficos para cada uma das operac¸˜oes do objeto de mem´oria compartilhada espac¸o de tuplas. Apenas uma das operac¸˜oes providas por estas construc¸˜oes, inp, requer a resoluc¸˜ao de con- senso em seus protocolos, necessitando portanto de mais trocas de mensagens entre os servidores e premissas de sincronismo para sua terminac¸˜ao (sincronia terminal - ver sec¸˜ao 2.1.3). Este requisito se justifica pelo fato do espac¸o de tuplas ter n´umero de consenso 2 [117] e portanto n˜ao poder ser implementado de maneira determinista satisfazendo terminac¸˜ao livre de espera em sistemas comple- tamente ass´ıncronos. At´e onde sabemos, apenas o trabalho FT-SCALABILITY[1] faz uso de sistemas de qu´oruns bizantinos na implementac¸˜ao de objetos mais poderosos que registradores, de forma se- melhante a usada na implementac¸˜ao do BTS e do LBTS. Este trabalho prop˜oem um esquema de replicac¸˜ao gen´erico (pode ser utilizado para implementar qualquer servic¸o) para sistemas ass´ıncronos sujeitos a faltas bizantinas que se baseia inteiramente em protocolos para sistemas de qu´oruns. Como isto n˜ao pode ser implementado satisfazendo liberdade de espera, o FT-SCALABILITYsacrifica a vi- vacidade: as operac¸˜oes satisfazem apenas liberdade de obstruc¸˜ao [68], i.e. uma operac¸˜ao ´e garantida de terminar apenas se n˜ao existem outras operac¸˜oes sendo executadas concorrentemente a ela. Desta forma, o FT-SCALABILITYn˜ao provˆe operac¸˜oes livres de espera, mas permite a implementac¸˜ao de objetos mais fortes que registradores em sistemas ass´ıncronos. O (L)BTS, por outro lado, garante a liberdade de espera em todas as operac¸˜oes assumindo sincronia parcial (que acreditamos ser um mo- delo bastante realista). Quando comparado com a nossa abordagem , o FT-SCALABILITYapresenta pelo menos duas desvantagens: (i.) ele satisfaz apenas liberdade de obstruc¸˜ao, o que em ambientes su- jeitos a faltas bizantinas pode ser muito perigoso, j´a que clientes maliciosos podem invocar operac¸˜oes continuamente no sistema, causando negac¸˜ao de servic¸o facilmente; e (ii.) ele requer n ≥ 5 f + 1 servidores, uma resistˆencia sub-´otima que tem um alto impacto no custo do sistema quando levamos em considerac¸˜ao a provis˜ao de independˆencia de falhas atrav´es de diversidade [99].

A grande maioria dos trabalhos sobre sistemas de qu´oruns bizantinos se concentra na implementac¸˜ao de operac¸˜oes de leitura e escrita para registradores (ex. [35, 64, 80, 86, 87, 92, 93]). No entanto, exis- tem alguns outros trabalhos nesta linha que prop˜oem objetos de mem´oria compartilhada diferentes. Em [13] ´e proposto um objeto que fornece non-skipping timestamps. Este objeto pode ser utilizado para eliminar uma conhecida vulnerabilidade dos protocolos para sistemas de qu´oruns bizantinos. Este tipo de objeto ´e equivalente a um registrador fetch&add, que sabidamente tem n´umero de con- senso 2 [67]. Entretanto, para implementar este objeto usando sistemas de qu´oruns, sua especificac¸˜ao foi enfraquecida de tal forma que o objeto resultante tenha n´umero de consenso 1 (como um registra- dor). O sistema para autoridade certificadora COCA [129] provˆe uma operac¸˜ao para atualizac¸˜ao de

chaves p´ublicas associadas a certificados usando apenas protocolos para sistemas de qu´oruns bizanti- nos. Sabendo-se que as operac¸˜oes de atualizac¸˜ao (read-write) no sentido da hierarquia livre de espera tˆem n´umero de consenso maior ou igual a 2 [67], pode-se pensar que esta operac¸˜ao d´a ao servic¸o im- plementado pelo COCA um n´umero de consenso maior que 1. No entanto, a operac¸˜ao de atualizac¸˜ao do COCA ´e na verdade uma operac¸˜ao de escrita (onde a nova chave p´ublica representa o valor) em um certificado (que funciona como um registrador), e portanto, o servic¸o provido ´e equivalente a um registrador. Alguns trabalhos prop˜oem objetos de consenso baseados em registradores usando alea- toriedade (ex. [88]) ou detectores de falhas (ex. [3]). Estes trabalhos diferem fundamentalmente do apresentado neste cap´ıtulo por usarem objetos baseados em sistemas de qu´oruns (registradores) para implementar consenso enquanto neste cap´ıtulo usamos consenso (protocolo PAXOSBIZANTINO) na implementac¸˜ao de objetos mais elaborados (espac¸o de tuplas). Al´em disso, os algoritmos de consenso providos nestes trabalhos n˜ao s˜ao uniformes, i.e. os processos precisam conhecer uns aos outros [9], um problema quando consideramos sistemas abertos.

Conforme apresentado na sec¸˜ao 3.6, existem v´arios trabalhos que exploram replicac¸˜ao para cons- truc¸˜ao de espac¸os de tuplas tolerantes a faltas. Alguns deles s˜ao baseados em replicac¸˜ao m´aquina de estados (ex. [11]) enquanto outros usam sistemas de qu´oruns (ex. [128]). Entretanto, nenhuma destas propostas consideram a ocorrˆencia de falhas bizantinas, foco principal do BTS e do LBTS.