O que é Byzantine Fault Tolerance (BFT)?

Byzantine Fault Tolerance (BFT) é, em suma, a capacidade de uma rede de computadores continuar a funcionar corretamente quando uma parte dos participantes falha, comete erros ou difunde deliberadamente informação incorreta.

Isto é especialmente importante para as blockchains. Uma blockchain não tem um administrador central que determine que transações e blocos são válidos. Em vez disso, computadores distribuídos, também designados por nodes ou validadores, têm de chegar em conjunto a um acordo sobre uma única versão da blockchain.

Um validador pode ter um erro de várias formas, nomeadamente um erro normal ou uma falha bizantina (Byzantine Fault). Num erro normal, é claro para a rede que o validador não está a funcionar corretamente. Por exemplo, o validador falha, perde a ligação à Internet ou não envia uma mensagem a tempo. Nesse caso, não fornece informação utilizável. A blockchain consegue, em geral, lidar facilmente com esta situação. Os outros validadores não esperam indefinidamente, mas avançam após algum tempo sem o validador que falhou. Desde que ainda existam validadores suficientes ativos, a rede continua a processar novos blocos.

Numa falha bizantina, um validador não se comporta apenas de forma defeituosa, mas de forma imprevisível. Continua a poder enviar mensagens, mas fornece informação incorreta ou contraditória. Assim, pode dizer a um validador que o bloco A é válido e a outro validador que o bloco B é válido.

A diferença é, portanto, a seguinte:

• Num erro normal, falta a informação de um validador.
• Numa falha bizantina, existe informação, mas não é claro se esta está correta.

Por isso, uma falha bizantina é mais difícil de resolver. A rede tem de conseguir continuar sem um validador que falhou, mas também tem de evitar que mensagens incorretas ou contraditórias conduzam a uma decisão errada.

Byzantine Fault Tolerance descreve como uma rede, apesar deste tipo de problemas, consegue ainda assim tomar uma decisão conjunta. Para tal, o protocolo utiliza, entre outros, controlos, assinaturas digitais, várias rondas de votação e um limiar de votação elevado.

Muitos protocolos BFT exigem que mais de dois terços do peso total de voto apoiem a mesma proposta antes de um bloco se tornar definitivo. Deste modo, um pequeno grupo de validadores defeituosos ou maliciosos não pode, por si só, determinar qual a versão da blockchain que é válida.

A BFT não é um mecanismo de consenso autónomo. É uma propriedade de uma rede ou de um protocolo de consenso. Protocolos como o PBFT, o Tendermint e o HotStuff utilizam cada um as suas próprias regras para tolerar falhas bizantinas.

Pontos principais

• A Byzantine Fault Tolerance ajuda uma blockchain a lidar com validadores defeituosos ou não fiáveis.
• Uma falha bizantina pode surgir devido a uma avaria técnica, um erro de software ou um ataque deliberado.
• Os validadores verificam propostas e votam em novos blocos.
• Muitos protocolos BFT exigem o apoio de mais de dois terços do peso total de voto.
• A BFT ajuda a evitar que diferentes versões da blockchain se tornem definitivas ao mesmo tempo.
• PBFT, Tendermint e HotStuff são exemplos de protocolos BFT.

O que resolve a Byzantine Fault Tolerance?

A Byzantine Fault Tolerance impede que um pequeno grupo de validadores defeituosos ou maliciosos determine, por si só, qual a versão da blockchain que é válida. Ajuda a rede a manter um histórico de transações único e partilhado, mesmo quando alguns participantes falham, não respondem ou difundem informação incorreta.

Por exemplo, um validador não fiável pode enviar blocos diferentes a participantes diferentes, votar em dois blocos em conflito, ou tentar fazer aprovar um bloco inválido. Um validador também pode recusar-se a cooperar e, assim, atrasar a obtenção de consenso.

Sem regras adequadas, diferentes grupos de validadores poderiam, por isso, seguir cada um uma versão diferente da blockchain. A rede deixaria então de conseguir determinar com certeza quais transações e blocos são válidos.

A BFT evita isto ao confirmar um bloco apenas quando validadores suficientes tiverem verificado e apoiado a mesma proposta. Assim, um grupo limitado de participantes não fiáveis não consegue enganar a rede por si só.

Os participantes não precisam de confiar uns nos outros pessoalmente. Confiam nas regras fixas do protocolo de consenso, como assinaturas digitais, rondas de votação e um limiar de votação elevado.

A BFT torna assim possível manter uma versão partilhada e consistente da blockchain sem um administrador central.

Como funciona a Byzantine Fault Tolerance?

Para compreender bem a Byzantine Fault Tolerance, é importante conhecer primeiro a diferença face a um mecanismo de consenso.

Um mecanismo de consenso é o conjunto de regras através do qual os participantes numa blockchain chegam a acordo sobre novos blocos e sobre o histórico válido da rede. Determina, por exemplo, quem pode propor um bloco, como os validadores votam sobre este e quando um bloco é confirmado ou se torna definitivo.

A Byzantine Fault Tolerance é a propriedade que assegura que este processo continua a funcionar mesmo quando alguns validadores falham, cometem erros ou enviam informação incorreta.

Assim, a BFT geralmente não é um sistema separado ao lado do mecanismo de consenso. Consiste nas regras dentro do processo de consenso que impedem que validadores não fiáveis enganem a blockchain. Pense, por exemplo, num limiar de votação elevado, assinaturas digitais, várias rondas de votação e na substituição de um validador que não proponha um bloco válido.

O funcionamento exato varia de blockchain para blockchain, mas em muitos protocolos BFT o processo decorre aproximadamente da mesma forma.

Um validador é temporariamente designado para propor um novo bloco. Este validador é frequentemente designado por proposer ou leader. O bloco contém novas transações e uma referência ao bloco anterior. O proposer assina digitalmente a proposta, para que os outros validadores possam verificar de quem provém.

Os outros validadores verificam de seguida se o bloco é válido. Por exemplo, verificam se as transações cumprem as regras, se os utilizadores têm saldo suficiente e se os mesmos tokens não estão a ser gastos duas vezes. Verificam também se o bloco se liga à versão correta da blockchain.

Quando um validador considera o bloco válido, emite um voto digital. Através desta assinatura, a rede consegue ver quem votou, para que bloco o voto se destinava e se um validador também votou num bloco em conflito.

É aqui que entra a Byzantine Fault Tolerance. A rede não confia na decisão de um único validador. Em muitos protocolos BFT, mais de dois terços do peso total de voto têm de apoiar o mesmo bloco antes de este poder tornar-se definitivo.

Este limiar de votação elevado garante que um pequeno grupo de validadores defeituosos ou maliciosos não consegue, por si só, determinar qual bloco é válido. Quando alguns validadores enviam informação incorreta ou não respondem, os restantes validadores ainda assim conseguem chegar em conjunto a uma decisão.

Exemplo: o Ethereum utiliza Proof of Stake e regras do tipo BFT para tornar os blocos definitivos. Os validadores bloqueiam ETH e votam depois em pontos de controlo na blockchain. Pelo menos dois terços do total de ETH em stake têm de apoiar o mesmo ponto de controlo antes de este se tornar definitivo. Quando uma pequena parte dos validadores falha ou vota incorretamente, o Ethereum continua a conseguir alcançar finalidade. Se cerca de um terço do peso total de voto não participar corretamente, a finalidade pode parar temporariamente. O Ethereum tem, para isso, uma inactivity leak: os validadores que não participam durante um período prolongado perdem gradualmente uma parte do seu stake. Deste modo, os validadores ativos acabam por voltar a representar peso de voto suficiente para alcançar finalidade.

Nas redes Proof-of-Stake, por isso, geralmente não importa apenas o número de validadores, mas sobretudo o seu peso de voto. Esse peso de voto depende da quantidade de tokens que estes colocaram em stake.

Alguns protocolos de consenso utilizam várias rondas de votação. Um exemplo conhecido é o Tendermint, atualmente desenvolvido como CometBFT e utilizado por muitas blockchains no ecossistema Cosmos, incluindo o Cosmos Hub. Os validadores votam primeiro no bloco proposto e, numa ronda seguinte, confirmam que validadores suficientes apoiam a mesma proposta. Assim, a rede não verifica apenas se o bloco é válido, mas também se existe amplo acordo sobre este.

Também pode acontecer que não se obtenha apoio suficiente. Por exemplo, o proposer pode estar offline, propor um bloco inválido ou difundir propostas contraditórias. O mecanismo de consenso inicia então, após um determinado tempo de espera, uma nova ronda com outro proposer.

Isto também faz parte da tolerância a falhas. Um único validador defeituoso ou malicioso não consegue, assim, bloquear a rede indefinidamente.

O mecanismo de consenso determina, portanto, como a blockchain toma decisões em conjunto. A Byzantine Fault Tolerance garante que essa tomada de decisão continua a ser fiável quando nem todos os participantes atuam corretamente.

Em suma: como funciona a Byzantine Fault Tolerance?

1. O mecanismo de consenso determina que validador pode propor um bloco e como os outros validadores votam sobre este.
2. Os outros validadores verificam se o bloco proposto é válido.
3. A BFT garante que a rede não confia num único validador, mas apenas toma uma decisão quando uma grande maioria apoia o mesmo bloco.
4. As assinaturas digitais tornam visível quem votou em quê e se um validador emitiu votos contraditórios.
5. Em muitos protocolos BFT é necessário mais de dois terços do peso total de voto para tornar um bloco definitivo.
6. Quando um proposer falha, mente ou não obtém uma maioria válida, o protocolo inicia uma nova ronda de votação com outro proposer.
7. O papel da BFT é, portanto, manter o consenso fiável quando alguns validadores falham, cometem erros ou difundem deliberadamente informação incorreta.

O que procuram proteger a safety e a liveness?

A Byzantine Fault Tolerance deve garantir que uma blockchain continua a ser fiável quando alguns validadores falham, cometem erros ou difundem informação incorreta. Nesse contexto, a rede tem de evitar dois problemas.

Em primeiro lugar, os validadores não podem chegar a duas versões definitivas diferentes da blockchain. Em segundo lugar, a rede deve, sempre que possível, continuar a processar novos blocos e transações.

Estes dois objetivos são designados, no contexto da BFT, por safety e liveness.

Safety: não existem duas versões diferentes

Safety significa que a rede não aceita dois blocos em conflito como definitivos.

Imagine que dois grupos de validadores recebem cada um um bloco diferente. Sem regras claras, ambos os grupos poderiam pensar que a sua própria versão é válida. A blockchain poderia então ter dois históricos de transações diferentes.

Os protocolos BFT procuram evitar isto com um limiar de votação elevado, várias rondas de votação e votos assinados digitalmente. Podem também existir regras que impeçam os validadores de votar simplesmente noutro bloco depois de já terem apoiado anteriormente uma proposta.

A safety garante, assim, que os participantes honestos continuam a seguir a mesma versão definitiva da blockchain, mesmo quando alguns validadores difundem informação contraditória.

Liveness: a rede continua a avançar

Liveness significa que a rede consegue continuar a tomar novas decisões.

Isto implica que são produzidos novos blocos, as transações são processadas e que um proposer defeituoso ou malicioso pode ser substituído quando bloqueia o processo.

Os protocolos BFT utilizam, por exemplo, tempos de espera e novas rondas de votação para este fim. Quando um proposer não propõe um bloco válido ou não responde, após algum tempo outro validador tem a sua vez.

A safety e a liveness podem, por vezes, entrar em conflito. Quando demasiados validadores estão offline ou difundem informação diferente, a rede pode não conseguir reunir votos fiáveis suficientes.

O protocolo pode então optar por, temporariamente, não tornar definitivos quaisquer blocos. A blockchain não avança durante algum tempo, mas evita que duas versões diferentes sejam aprovadas.

Por isso, em situações de incerteza grave, os protocolos BFT geralmente dão prioridade à safety. A rede prefere ficar temporariamente parada a tornar definitiva uma versão possivelmente incorreta ou conflituante da blockchain.

Qual é a diferença entre Byzantine Fault Tolerance e o Byzantine Generals Problem?

O Byzantine Generals Problem e a Byzantine Fault Tolerance estão relacionados, mas não significam o mesmo.

O Byzantine Generals Problem é uma experiência mental que mostra por que razão o acordo é difícil numa rede sem um decisor central. Na história, vários generais têm de decidir em conjunto se atacam ou se recuam. Estes comunicam apenas por mensagens, enquanto alguns generais podem mentir ou difundir informação contraditória.

Numa blockchain, ocorre essencialmente o mesmo problema. Os validadores têm de decidir em conjunto quais transações e blocos são válidos, sem terem a certeza de que todos os participantes são honestos e fiáveis.

A Byzantine Fault Tolerance descreve, em seguida, como uma rede lida com esse problema. Garante que os validadores conseguem, ainda assim, chegar a uma decisão conjunta, mesmo quando uma parte dos participantes falha, comete erros ou envia informação incorreta.

O Byzantine Generals Problem descreve, portanto, o problema. A Byzantine Fault Tolerance é a capacidade de uma rede resolver esse problema. As regras concretas através das quais isso acontece, como rondas de votação, assinaturas digitais e um limiar de votação elevado, formam em conjunto o protocolo BFT.

Como aplicam as blockchains a Byzantine Fault Tolerance?

As blockchains podem aplicar a Byzantine Fault Tolerance de diferentes formas. Nem todas as redes utilizam o mesmo protocolo, mas o objetivo é sempre semelhante: os validadores têm de escolher em conjunto uma versão válida da blockchain, mesmo quando alguns falham ou difundem informação incorreta.

As diferenças estão sobretudo na forma como um validador é escolhido para propor um bloco, em quantas rondas de votação são necessárias e em quando um bloco se torna definitivo. Também varia, de protocolo para protocolo, o que acontece quando os validadores não respondem ou emitem votos contraditórios.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance, normalmente abreviado para PBFT, é um dos protocolos BFT mais conhecidos. Foi desenvolvido por Miguel Castro e Barbara Liskov para tornar a Byzantine Fault Tolerance utilizável em sistemas informáticos reais.

O PBFT funciona com um líder temporário que envia uma proposta aos outros participantes. Estes verificam a proposta e depois partilham entre si se a consideram válida. Em seguida, confirmam que participantes suficientes apoiam a mesma proposta.

Através destas diferentes rondas de comunicação, a rede consegue verificar se existe realmente um amplo consenso. O PBFT funciona especialmente bem com um grupo relativamente pequeno de participantes conhecidos. À medida que o grupo aumenta, têm de ser trocadas cada vez mais mensagens. Por isso, o protocolo torna-se menos eficiente para blockchains com um número muito elevado de validadores.

Tendermint BFT

O Tendermint BFT é utilizado por muitas blockchains no ecossistema Cosmos. No Tendermint, um validador propõe primeiro um bloco. Depois seguem-se duas rondas de votação nas quais os validadores indicam se apoiam o bloco.

Um bloco só se torna definitivo quando mais de dois terços do peso de voto concordam com este. O Tendermint utiliza também um mecanismo de locking. Quando um validador vê que um bloco tem apoio suficiente, este fica, por assim dizer, bloqueado nesse bloco.

Depois disso, o validador não pode simplesmente votar num bloco em conflito. Isto ajuda a evitar que, em rondas diferentes, sejam aprovados dois blocos contraditórios.

HotStuff

O HotStuff é um protocolo BFT mais moderno que procura aplicar a mesma ideia base de forma mais eficiente. Também aqui um líder temporário propõe blocos e validadores suficientes têm de os apoiar.

O HotStuff pode resumir o apoio dos validadores num quorum certificate. Trata-se de uma prova criptográfica de que validadores suficientes apoiaram a mesma proposta. Os validadores ainda têm de enviar os seus votos, mas o quorum certificate permite transmitir de forma compacta a prova desse apoio amplo. O HotStuff foi também concebido para tornar mais eficiente a comunicação e a troca de líder.

Assim, nem sempre é necessário processar separadamente todos os votos individuais. O protocolo foi ainda concebido para trocar mais rapidamente de líder quando o líder atual não funciona bem.

Vários protocolos modernos de blockchain são total ou parcialmente inspirados no HotStuff.

Ethereum

O Ethereum não utiliza uma forma clássica de PBFT, Tendermint ou HotStuff. A rede utiliza Proof of Stake, em que os validadores votam com a ETH que colocaram em stake. Ainda assim, existem princípios BFT claramente visíveis na forma como o Ethereum alcança finalidade.

Os validadores votam em pontos de controlo na blockchain. Um ponto de controlo só se torna definitivo quando pelo menos dois terços do total de ETH em stake o apoiam.

Quando mais de um terço do peso de voto não coopera, a finalidade pode parar temporariamente. A rede opta então por esperar por votos fiáveis suficientes, em vez de tornar definitivas duas versões diferentes.

Os validadores que votem comprovadamente em versões contraditórias podem ser punidos. Isto chama-se slashing. A penalização económica apoia aqui as regras BFT: os validadores podem difundir informação incorreta, mas esse comportamento é visível e pode ter consequências.

Bitcoin

O Bitcoin aborda o mesmo problema de base de outra forma. A rede também tem de alcançar consenso enquanto os participantes não confiam totalmente uns nos outros, mas não utiliza, para isso, um protocolo BFT clássico baseado em votos.

O Bitcoin utiliza Proof of Work. Os miners utilizam poder de computação para produzir novos blocos, após o que os nodes verificam se estes blocos são válidos. Os miners continuam a construir sobre a chain válida em que foi investido o maior trabalho computacional cumulativo.

Um bloco não é, neste caso, imediatamente definitivo. A probabilidade de este ser revertido diminui à medida que mais blocos são construídos por cima. Isto chama-se finalidade probabilística.

O Bitcoin procura, portanto, resolver o mesmo problema geral que os protocolos BFT: como mantém uma rede um único histórico fiável quando nem todos os participantes são dignos de confiança? A diferença é que o Bitcoin utiliza poder de computação e custos económicos, enquanto os protocolos BFT clássicos funcionam sobretudo com rondas de votação explícitas e um limiar de votação elevado.

O que acontece quando os validadores não cooperam?

O que acontece quando os validadores falham ou atuam incorretamente depende do peso de voto que estes representam em conjunto.

Quando apenas um pequeno grupo de validadores não coopera, os restantes validadores normalmente conseguem ainda reunir apoio suficiente para confirmar novos blocos. A rede continua então a funcionar normalmente, mesmo que nem todos os validadores estejam ativos ou sejam fiáveis.

A situação muda quando mais de um terço do peso total de voto não participa. Em muitos protocolos BFT, a rede deixa então de conseguir reunir o apoio necessário de mais de dois terços. Como resultado, novos blocos podem temporariamente não conseguir tornar-se definitivos. Este grupo consegue, assim, bloquear o progresso, mas normalmente não consegue, por si só, aprovar uma versão conflituante da blockchain.

Quando um grupo controla mais de dois terços do peso de voto e atua em conjunto, pode formar, por si só, apoio suficiente para confirmar blocos. Um grupo desse tipo pode, assim, determinar quais os blocos válidos que alcançam finalidade e pode censurar transações ao não as incluir. Para tornar definitivas duas versões em conflito, os validadores teriam de violar comprovadamente as regras de consenso, o que, em muitas redes Proof-of-Stake, pode levar a slashing.

Por isso, não é apenas o número de validadores que é importante, mas sobretudo a distribuição do peso de voto. Uma blockchain pode ter milhares de validadores e, ainda assim, ser relativamente concentrada quando um pequeno número de entidades controla uma grande parte dos tokens em stake.

Como são punidos os validadores maliciosos?

As blockchains Proof-of-Stake podem punir os validadores quando estes violam comprovadamente as regras de consenso. Isto chama-se slashing.

Por exemplo, um validador pode ser punido quando vota em dois blocos em conflito ou tenta apoiar duas versões diferentes da blockchain. Como cada voto é assinado digitalmente, a rede consegue verificar que validador cometeu a infração.

A penalização varia consoante a blockchain. Um validador pode perder recompensas de staking, perder uma parte dos seus tokens em stake ou ser removido temporariamente do conjunto de validadores. Em infrações graves, a exclusão pode durar mais tempo ou ser permanente.

O slashing não torna a fraude impossível, mas aumenta as consequências financeiras. Um validador que viole as regras de consenso corre, assim, o risco de perder uma parte do seu próprio valor depositado.

Quais são as vantagens da Byzantine Fault Tolerance?

A Byzantine Fault Tolerance tem várias vantagens:

1. A rede pode continuar a funcionar em caso de erros: Nem todos os validadores têm de estar sempre online ou sem falhas. Desde que validadores suficientes continuem a funcionar corretamente, a rede pode continuar a processar novos blocos.
2. A blockchain mantém um único histórico partilhado: A BFT ajuda a evitar que diferentes grupos de validadores tornem definitivos blocos em conflito. Assim, os participantes honestos continuam a seguir a mesma versão da blockchain.
3. Os blocos podem tornar-se definitivos rapidamente: Muitos protocolos BFT tornam um bloco definitivo assim que validadores suficientes o apoiam. Por isso, os utilizadores muitas vezes não têm de esperar por muitos blocos adicionais.
4. O comportamento dos validadores é verificável: Os votos são assinados digitalmente. Deste modo, a rede consegue ver que validador votou em que bloco e se alguém emitiu votos contraditórios.
5. Não é necessário um decisor central: Os validadores podem, em conjunto, determinar quais os blocos válidos, sem que uma única entidade central tome todas as decisões.

Quais são as desvantagens da Byzantine Fault Tolerance?

A Byzantine Fault Tolerance também tem várias desvantagens:

1. A rede pode parar temporariamente: Quando participam poucos validadores, o quorum necessário pode não ser formado. Nesse caso, a rede pode ainda conseguir propor blocos, mas não os tornar definitivos. Assim, as transações permanecem incertas durante mais tempo e os utilizadores têm de esperar até que validadores suficientes voltem a participar.
2. Os validadores têm de trocar muita informação: Os validadores têm de partilhar entre si propostas, votos e confirmações durante o processo de consenso. À medida que o número de validadores cresce, também aumenta a quantidade de comunicação. Isto pode atrasar a rede e exigir mais largura de banda e poder de computação.
3. Os protocolos BFT são tecnicamente complexos: Estes protocolos funcionam com várias rondas de votação, tempos de espera, líderes temporários e regras que determinam quando um validador pode mudar o seu voto. Um erro nestas regras ou no software pode fazer com que os validadores fiquem bloqueados, processem informação diferente ou não consigam alcançar consenso temporariamente.
4. O peso de voto pode ficar concentrado: Uma blockchain pode ter muitos validadores, enquanto alguns grandes prestadores de staking ou organizações gerem em conjunto uma grande parte do peso de voto. Quando estas entidades controlam mais de um terço do peso de voto, podem eventualmente impedir a finalidade. Com mais de dois terços, podem exercer muita influência sobre que blocos são confirmados.
5. A BFT protege apenas a camada de consenso: A BFT ajuda os validadores a alcançar acordo sobre a blockchain válida, mas não protege todas as partes da rede. Por exemplo, uma transação pode ser confirmada corretamente enquanto o smart contract utilizado contém um erro. A BFT também não evita wallets hackeadas, bridges vulneráveis, informação de preços incorreta de oracles, problemas em crypto-exchanges ou perdas devido a quedas de preço.

Considerações finais

A Byzantine Fault Tolerance garante que uma blockchain pode continuar a funcionar de forma fiável quando alguns validadores falham, cometem erros ou difundem deliberadamente informação incorreta. A rede não confia num único participante, mas utiliza, entre outros, assinaturas digitais, rondas de votação e um limiar de votação elevado para chegar a uma decisão conjunta.

A BFT não é um mecanismo de consenso autónomo, mas uma propriedade do processo de consenso. Ajuda a evitar que diferentes versões da blockchain se tornem definitivas ao mesmo tempo e garante que a rede, desde que participem validadores suficientes, continua a processar novos blocos.

As blockchains aplicam estes princípios de diferentes formas. O Tendermint utiliza várias rondas de votação e regras de locking, o Ethereum utiliza regras do tipo BFT para a finalidade e o Bitcoin resolve um problema semelhante com Proof of Work e finalidade probabilística.

A Byzantine Fault Tolerance não torna uma blockchain totalmente protegida contra todos os erros e ataques. No entanto, constitui uma base importante para redes em que os participantes não têm de confiar plenamente uns nos outros, mas ainda assim conseguem manter em conjunto um histórico de transações válido.