PBFT e trabalhos relacionados

A execução do PBFT é baseada em visões. Em cada visão, uma réplica é designada primária, responsável pelo sub-protocolo de acordo ou consenso. O sub-protocolo de acordo é a base do PBFT, e define em que ordem as requisições dos clientes são executadas pelas réplicas. A comunicação entre as réplicas é autenticada por meio de chaves criptográficas, conforme definido no modelo do sistema (ver Seção 5.2.1).

O sub-protocolo de acordo atua como um protocolo de efetivação (commit) de três fases adaptado a falhas bizantinas. O cliente envia a requisição ao grupo de réplicas. Então, inicia- se a fase de PRE-PREPARE, na qual o primário assinala um número de sequência e envia a requisição ao grupo de réplicas. As réplicas respondem a esta requisição com uma mensagem de PREPARE. Se ao menos 2 f mensagens de PREPARE para uma requisição são recebidas por uma réplica, esta envia COMMIT para a requisição. Uma réplica executa uma requisição se recebe 2 f + 1 mensagens de COMMIT desta requisição. Por fim, o resultado é enviado ao cliente, o qual aceitará o resultado, se recebe ao menos f + 1 respostas equivalentes.

De modo a maximizar o desempenho, é utilizada criptografia com chaves públicas para a troca periódica de chaves simétricas de sessão, sendo estas utilizadas na comunicação em pares das réplicas. Devido ao custo da autenticação, o primário pode agrupar um conjunto de re-

5.2 REPLICAÇÃO BIZANTINA 83 quisições recebidas em uma única mensagem com um lote de requisições a serem processadas (batching). Nesse mecanismo de batching, cada requisição recebida é armazenada em buffer e seu respectivo resumo (digest) é gerado. Quando existem requisições suficientes para pre- encher um lote, uma mensagem de PRE-PREPARE é enviada contendo, entre outros campos, o conjunto de digests calculados para cada requisição do lote. Para prevenir que o primário fique bloqueado esperando indefinidamente que o lote de requisições seja preenchido, quando a primeira requisição do lote é recebida, um temporizador é iniciado, e caso o lote não seja pre- enchido dentro do timeout de batching, então a mensagem de PRE-PREPARE é enviada com as requisições recebidas até então. Uma vez que o número de requisições que chegam dentro de um timeout pode variar, diferentes lotes podem agrupar diferentes números de requisições – por conta disto, alguns autores, como [80], afirmam que o mecanismo de batching é adaptativo, apesar do mesmo não observar quaisquer aspectos referentes ao desempenho do protocolo ou da carga das aplicações para determinar o tamanho do lote.

Em caso de suspeita de falha do primário, o sub-protocolo de mudança de visão permite a eleição de uma nova réplica primária. De modo a evitar falhas intermitentes (de maior proba- bilidade com o envelhecimento), ou mesmo permitir restaurar uma réplica eventualmente com- prometida, o sub-protocolo de recuperação pró-ativa reinicia uma réplica de forma periódica – esta técnica é dita rejuvenescimento de réplica.

Em diferentes casos, como na eleição de uma nova réplica ou no de rejuvenescimento da réplica, é necessário que uma réplica recupere o estado da máquina de estados. Ao longo da execução, a recuperação do estado pode ser custosa, o sub-protocolo de checkpoint permite sincronizar réplicas, limitando o estado que deve ser mantido em log.

Outros protocolos foram publicados com o objetivo de otimizar aspectos do PBFT. Por exemplo, o Zyzzyva [81] modifica o sub-protocolo de acordo por meio da execução especula- tiva, onde o acordo somente é executado em caso de suspeitas de falha. A versão original do PBFT considera execução especulativa somente para operações que não alteram os estados das réplicas, como, por exemplo, operações de leitura. Recentemente, o PBFT foi especializado em [80] para permitir execução especulativa para operações que alteram o estado das répli- cas. Entretanto, diferente do Zyzzyva, esta versão do PBFT permite que o cliente execute de forma especulativa, mas não externaliza o estado da máquina replicada antes que o acordo seja executado.

Os diferentes protocolos apresentados na literatura diferem com relação a estratégia utili- zada para cada sub-protocolo que compõe a replicação tolerante a falhas bizantinas, em especial na escolha do sub-protocolo de acordo, desde uma abordagem especulativa, como em [81], a uma abordagem de adaptação pré-definida em tempo de projeto, como em [82], em que dife- rentes estratégias para o sub-protocolo de acordo podem ser escalonadas em face de diferentes condições de gatilho, pré-definidas na configuração do protocolo. Ao nosso saber, nenhuma abordagem se baseia na configuração dinâmica dos parâmetros que definem os pontos de ope- ração dos sub-protocolos. Neste aspecto, a abordagem proposta é genérica o suficiente para ser

aplicada não somente ao PBFT, mas em outros protocolos derivados do PBFT.

Alguns protocolos de replicação bizantina baseados em quóruns atuam de forma adaptativa, mas considerando a adaptação a falhas, sem considerar, por exemplo, as mudanças dinâmi- cas na carga de trabalho do ambiente distribuído. Em [83], por exemplo, é considerada uma abordagem baseada em quoruns, em que o limiar de falhas é inicialmente configurado em um valor otimista. Na medida em que os servidores do sistema falhem, este limiar é incrementado. Tal limiar é usado na definição do número mínimo de servidores nos quóruns, por conta disso, os autores nomeiam a abordagem de sistema de quoruns dinâmicos. A abordagem de [83] é especializada em [84], em que um detector de falhas bizantinas é usado para permitir que ser- vidores defeituosos sejam removidos, possibilitando assim que o número total de servidores considerados seja reavaliado em tempo de execução – que promove alterações nas composições dos quoruns. Por conta disto, os autores a denominam de abordagem re-configurável de quo- runs bizantinos. Estes trabalhos consideram apenas a reconfiguração de parâmetros mediante às falhas no sistema, enquanto que a abordagem proposta realiza a adaptação considerando as condições de carga no ambiente – buscando assim por configurações que permitam um melhor desempenho em face de mudanças nas condições de carga. Em outros trabalhos não diretamente relacionados à presente proposta, o tratamento de falhas bizantinas também tem sido estudado no contexto de armazenamento de dados [85, 86].