A confiabilidade da tecnologia blockchain é uma das principais razões para sua popularidade. Os especialistas veem isso como uma forma de melhorar a eficiência e a transparência dos sistemas tradicionais, que podem ser pouco confiáveis, caros e propensos a fraudes.
Então, como as blockchains são capazes de fornecer essa confiabilidade? Este artigo explicará o conceito por trás da tolerância a falhas bizantinas (BFT) e o que isso significa no contexto da blockchain.
- O que é tolerância a falhas bizantinas (BFT)?
- Qual é o problema dos generais bizantinos?
- Como o BFT se aplica à blockchain?
- O que é tolerância prática a falhas bizantinas?
- Como funciona a tolerância prática a falhas bizantinas
- Tipos de falhas bizantinas
- Vantagens da tolerância prática a falhas bizantinas
- Limitações da tolerância prática a falhas bizantinas
- Importância da tolerância a falhas bizantinas (BFT)
- Variações da tolerância a falhas bizantinas (BFT)
- Mecanismos de consenso são a chave
- Perguntas frequentes
O que é tolerância a falhas bizantinas (BFT)?
A tolerância a falhas bizantinas (BFT) é a capacidade de um sistema sem permissão descentralizado de identificar e rejeitar informações falsas. Diz-se que um sistema descentralizado e sem permissão é tolerante a falhas bizantinas se tiver resolvido o Problema dos Generais Bizantinos – um problema que o Bitcoin finalmente resolveu de maneira distribuída.
Tal como está, qualquer pessoa pode ingressar em um sistema descentralizado e sem permissão e começar a transmitir informações. Se este sistema não for tolerante a falhas bizantinas, um membro da rede pode fornecer informações falsas ao sistema e comprometer a confiabilidade da rede. É por isso que a tolerância a falhas bizantinas (BFT) é tão importante.
Qual é o problema dos generais bizantinos?
O Problema dos Generais Bizantinos é uma analogia da teoria dos jogos. Os especialistas o usam para descrever os desafios das partes descentralizadas ao tentar chegar a um consenso sem depender de uma parte central confiável. Essa questão da teoria dos jogos foi trabalhada em 1982 pelos cientistas da computação Leslie Lamport, Marshall Pease e Robert Shostak.
O Problema dos Generais Bizantinos descreve uma situação em que várias divisões de um exército bizantino estão acampadas em diferentes posições fora de uma cidade sitiada. Cada divisão é liderada por um general, que deve decidir coletivamente quando atacar ou recuar. A decisão deles é crucial porque se eles atacarem em momentos diferentes, eles perderão. Somente se eles atacarem ao mesmo tempo, eles vencerão.
No entanto, os generais não têm uma linha segura de comunicação sem uma parte central confiável. Isso significa que as mensagens que eles enviam uns aos outros podem ser interceptadas, destruídas e manipuladas por traidores que surgem entre os defensores da cidade. A mensagem também pode se perder durante a transmissão. Por outro lado, se uma mensagem chega com sucesso, a pergunta é: ela é confiável? Como um general sabe que o portador da mensagem não foi sequestrado e trocado por um traidor para enganar o general receptor da mensagem?
Para resolver esse dilema, os generais precisariam de uma forma que garantisse que:
- Todos os generais leais concordarão e implementarão o mesmo plano.
- Os generais leais seguirão regras específicas.
- Generais leais devem chegar a um consenso, apesar das ações que os traidores decidem tomar.
- Generais leais não seguirão um plano errado sob a influência de generais desleais.
Como o BFT se aplica à blockchain?
Uma blockchain é um sistema descentralizado sem uma autoridade central confiável que possa resolver esse problema. Sua rede de nós é semelhante aos generais do problema da teoria dos jogos descritos acima. Eles carecem de uma parte central confiável para ajudá-los a se comunicar uns com os outros com segurança, mas devem chegar a um consenso para que a rede funcione sem problemas. O mesmo dilema se aplica aqui, pois os nós devem concordar com o mesmo curso de ação e executá-lo simultaneamente.
Mecanismo de consenso
Satoshi Nakamoto ofereceu uma solução para o problema dos generais bizantinos quando publicou o whitepaper do Bitcoin em outubro de 2008. Essa solução veio na forma do mecanismo de consenso de proof of work (PoW). Aqui, os membros da rede declaram um bloco válido se ele tiver uma prova de trabalho autêntica anexada a ele, representada por um hash. Essa declaração significa que todos os nós da rede de blockchain chegaram a um consenso e um nó de mineração pode adicionar o bloco à cadeia. Um bloco é um local na blockchain do Bitcoin que armazena dados de transação.
O hash PoW prova que o trabalho foi usado para produzir um bloco. Esse trabalho é na forma do capital que os mineradores de Bitcoin investem em eletricidade e equipamentos para executar as operações de mineração e produzir um bloco. Portanto, esse investimento os desencoraja de agir maliciosamente contra a rede. O processo de mineração de alto custo torna a blockchain do Bitcoin muito segura e confiável.
Outras blockchains resolvem o problema dos generais bizantinos com diferentes algoritmos de consenso. Por exemplo, a blockchain Ethereum usa proof of stake (PoS), onde os membros da rede colocam uma participação de 32 ETH ou menos (dependendo do método de staking), desencorajando-os a agir contra a rede. Os stakers podem perder todas as suas criptomoedas se agirem de forma desonesta.
O que é tolerância prática a falhas bizantinas?
A tolerância prática a falhas bizantinas (pBFT) é um algoritmo de consenso que busca tolerar falhas bizantinas (falhas de nós). Barbara Liskov e Miguel Castro o apresentaram em um artigo acadêmico de 1999 intitulado “Practical Byzantine Fault Tolerance”.
O pBFT melhora os algoritmos de tolerância a falhas bizantinas (BFT) anteriores. Este modelo assume que existem falhas de nós independentes. Também presume que nodos independentes podem transmitir mensagens falsas.
Como funciona a tolerância prática a falhas bizantinas
No pBFT, os nós devem provar que uma mensagem veio de um nó de par específico. As regras do algoritmo também exigem que os nós verifiquem se uma mensagem foi inalterada durante a transmissão. Em outras palavras, o pBFT trabalha com a suposição de que o número de nós maliciosos não pode ser igual ou superior a um terço do número total de nós na rede. Um sistema com muitos nós torna-se matematicamente improvável de se aproximar de um cenário em que um terço do total de nós são maliciosos.
Um sistema baseado em pBFT tem um nó primário, também chamado de nó líder. O restante dos nós são nós secundários ou de backup. Qualquer nó no sistema pode se tornar um nó primário. Por exemplo, se o nó primário falhar, um nó secundário pode se tornar um nó primário. O nó primário é alterado a cada rodada de consenso pBFT. A maioria dos nós honestos também pode votar para remover um nó primário existente com defeito e substituí-lo pelo próximo nó da fila.
O consenso pBFT ocorre da seguinte forma:
- Um cliente envia uma solicitação ao nó líder.
- O nó líder transmite a mensagem para os nós de backup.
- Todos os nós (primários e secundários) executam a solicitação do cliente. Em seguida, eles enviam uma resposta ao cliente.
- A requisição é bem-sucedida se o cliente receber respostas “m+1”, onde m representa o número máximo de nós com falha permitidos.
Hyperledger Fabric, Zilliqa e Tendermint são plataformas blockchain que usam o algoritmo de consenso pBFT. O Hyperledger Fabric usa uma variante permitida do pBFT, enquanto o Zilliqa usa PoW e pBFT. Tendermint utiliza PoS delegado e pBFT.
Tipos de falhas bizantinas
Existem dois tipos de falhas bizantinas: fail-stop e nó arbitrário. Falhas de fail-stop ocorrem quando um nó falha e para de funcionar. Ao contrário, falhas de nó arbitrárias podem ocorrer quando:
- Um nó responde com um resultado falso.
- Os nós falham ao retornar um resultado.
- Um nó responde intencionalmente com um resultado incorreto.
- Os nós respondem com resultados diferentes para diferentes partes da rede.
Vantagens da tolerância prática a falhas bizantinas
pBFT oferece alguns méritos em comparação com outros algoritmos de consenso, particularmente PoW. Essas vantagens incluem o seguinte:
- Finalidade da transação: O modelo pBFT fornece finalidade da transação sem exigir confirmações. Se os nós concordarem com a validade de um bloco proposto, as transações nesse bloco serão finais. Isso difere do PoW, onde cada nó verifica individualmente uma transação antes que um nó de mineração a adicione à cadeia. As confirmações de Bitcoin, por exemplo, levam em torno de 10 a 60 minutos, dependendo do número de nós que confirmam o bloco.
- Baixo consumo de energia: Ao contrário do PoW, o pBFT não consome muita energia, pois não requer nós para resolver problemas matemáticos complexos. Os mineradores de Bitcoin precisam de eletricidade para gastar prova de trabalho, o que pode resultar em alto consumo de eletricidade.
- Pagamentos uniformes: No pBFT, todos os nós implementam a solicitação do cliente, o que significa que todos recebem uma recompensa.
Limitações da tolerância prática a falhas bizantinas
As blockchains baseados em pBFT não escalam bem devido à comunicação constante entre os nós. Isso significa que redes com muitos nós levarão muito tempo para responder a uma solicitação do cliente.
Além disso, as blockchains baseados na tolerância prática a falhas bizantinas são vulneráveis a ataques Sybil. Este é um tipo de ataque em que uma única entidade assume o controle de vários nós para interromper o consenso da rede. No entanto, os ataques Sybil são menos prováveis de acontecer à medida que o número de nós se expande. Ainda assim, os problemas de dimensionamento do modelo pBFT podem exigir que os desenvolvedores o combinem com um mecanismo de consenso diferente, como é o caso do projeto Zilliqa, por exemplo.
Importância da tolerância a falhas bizantinas (BFT)
A tolerância a falhas bizantinas (BFT) é importante porque as redes blockchain podem operar normalmente, mesmo que alguns nós transmitam informações falsas ou parem de funcionar. Os usuários de criptomoedas devem entender a tolerância a falhas bizantina (BFT) das blockchains em cujas moedas eles investiram, porque isso informa o quão seguras serão suas transações com criptomoedas.
Variações da tolerância a falhas bizantinas (BFT)
A tolerância a falhas bizantinas (BFT) de uma blockchain dependerá do algoritmo de consenso que os desenvolvedores decidirem usar. Isso significa que nem todas as blockchains têm a mesma tolerância a falhas bizantinas.
Alguns dos algoritmos de consenso mais comuns são:
- Proof-of-work
- Proof-of-stake
- Delegated proof-of-stake (DPoS)
- practical Byzantine Fault Tolerance (pBFT)
- Leased proof-of-stake (LPoS)
- Proof-of-importance (PoI)
- Proof-of-authority (PoA)
- Direct Acyclic Graph (DAG)
- Delegated Byzantine Fault Tolerance (dBFT)
- Proof-of-capacity (PoC)
- Proof-of-identity (PoI)
- Proof-of-activity (PoA)
- Proof-of-elapsed-time (PoET)
Mecanismos de consenso são a chave
As redes blockchain precisam de bons mecanismos de consenso para serem eficientes e bem-sucedidas. Existem muitos algoritmos de consenso no mercado, cada um operando de maneira ligeiramente diferente. Embora nenhuma rede blockchain seja perfeita, os sistemas PoW e PoS BFT surgiram como ótimas abordagens para resolver o problema dos generais bizantinos.
Perguntas frequentes
O que é um sistema de tolerância a falhas bizantinas?
Por que é chamado de tolerância a falhas bizantinas?
O que é o processo bizantino?
Ethereum é tolerante a falhas bizantina?
O Bitcoin é tolerante a falhas bizantina?
O que é bizantino em blockchain?
Isenção de responsabilidade
Todas as informações contidas em nosso site são publicadas de boa fé e com o objetivo único de informar. Qualquer atitude tomada pelo usuário a partir das informações veiculadas no site é de sua inteira responsabilidade.
Na seção Aprender, nossa prioridade é fornecer informações de alta qualidade. Nós tomamos o tempo necessário para identificar, pesquisar e produzir conteúdo que seja útil para nossos leitores.
Para manter esse padrão e continuar a criar um conteúdo de excelência, nossos parceiros podem nos recompensar com uma comissão por menções em nossos artigos. No entanto, essas comissões não afetam o processo de criação de conteúdo imparcial, honesto e útil.
