Tolerância a falhas bizantinas no blockchain

Nas últimas décadas, a indústria de criptomoedas cresceu significativamente. Novos projetos surgem constantemente, obrigando os desenvolvedores a encontrar novas maneiras de resolver os problemas existentes no setor. Um termo bastante comum é o mecanismo de consenso BFT. BFT significa tolerância a falhas bizantinas e é considerado problema teórico de sistemas de computador, com o qual os criadores tiveram que lidar muito antes do surgimento do Bitcoin.

No entanto, muitos desenvolvedores de protocolos baseados em blockchain estão lidando com problemas com tolerância a falhas bizantinas, então vamos ver a natureza do problema e as implicações que enfrentamos quando esse problema surge.

O problema da tolerância a falhas bizantinas

Emitir A tolerância a falhas bizantinas é uma das situações teóricas mais frequentemente consideradas ao discutir as nuances do consenso. Este problema foi reconhecido pela primeira vez como existente no estudo "Major Problems of Byzantine Failure" de Leslie Lappport, Robert Szostak e Marshall Pease, publicado em 1982.

O estudo descobriu:

Um sistema de computador confiável deve lidar com a falha de um ou mais componentes. Um componente com falha pode se comportar de uma maneira que muitas vezes é negligenciada, ou seja, enviando informações conflitantes para diferentes partes do sistema. O problema de resolver esse tipo de falha é chamado em abstrato de "Problema geral de tolerância a falhas bizantinas".

O nome vem da analogia apresentada no estudo.

Mais precisamente, os autores descrevem uma situação teórica em que várias unidades do exército bizantino estavam estacionadas fora da cidade inimiga. Cada destacamento tinha seu comandante e cada destacamento estava em um acampamento separado. Os comandantes tinham que traçar um plano de ação conjunta (avançar ou recuar), mas só podiam se comunicar por meio de mensageiros. Por outro lado, poderia haver traidores entre os generais que poderiam impedir generais leais de chegar a um denominador comum (consenso).

Portanto, os generais tiveram que encontrar uma maneira de garantir que:

• todos os generais leais seguem o mesmo plano de ação,
• um pequeno punhado de traidores não poderá impedir que os generais adotem o plano certo.

Então estamos falando de um sistema que pode resolver o problema descrito acima e chama-se Solução de Tolerância a Falhas Bizantinas (BFS). É daí que vem o algoritmo de consenso BFT. No geral, a solução Byzantine Fault Tolerance evita falhas do sistema devido a participantes não confiáveis ​​(inválidos).

Resolvendo o problema dos generais bizantinos

Para resolver o problema dos generais bizantinos e fazer uma solução de tolerância a falhas bizantinas (FTS), a maioria dos generais deve usar a mesma estratégia. Isso é alcançado de diferentes maneiras, dependendo da natureza do sistema e de sua finalidade. No blockchain, dois mecanismos, proof-of-stake e proof-of-work, também podem chegar a um consenso sobre uma solução de contingência bizantina usando diferentes abordagens.

A maioria dos blockchains proof-of-stake pode funcionar quando um terço de seus nós existentes falhará, dando rédea solta à regra "3f+1", onde F i refere-se ao número de nós não funcionais. A própria fórmula calcula o número de nós que devem estar presentes no sistema para que ele funcione corretamente.

Por exemplo, para satisfazer a regra (3f+1), em um sistema com 4 nós, três nós devem estar totalmente funcionais.

Como o blockchain pode resolver esse problema?

A tecnologia baseada em blockchain teria várias maneiras de resolver o problema dos generais bizantinos. A única diferença é o algoritmo de consenso necessário e como o BFTS é aplicado. Diferentes soluções podem ser encontradas tanto no lado da prova de trabalho quanto na prova de participação.

Curiosamente, Satoshi Nakamoto não mencionou o “problema dos generais bizantinos” no whitepaper original do bitcoin. No entanto, após o lançamento da rede Bitcoin, o criador desconhecido da primeira criptomoeda propôs uma solução para o problema mencionado usando um consenso de "prova de trabalho". Satoshi criou uma maneira de usar segurança criptográfica e criptografia de chave pública em uma rede digital. Para evitar qualquer vazamento de dados, a segurança criptográfica usa hash e a identidade do usuário da rede é verificada usando uma chave pública.

As transações são capturadas em blocos que são vinculados ao restante à custa de hash e são protegidos criptograficamente. Também deve ser notado que o blockchain usa uma árvore Merkle para verificar os hashes provenientes do bloco principal. Todos o bloco vindo do bloco genesis é válido. Esses blocos são verificados por mineradores que resolvem quebra-cabeças criptográficos em uma competição consensual de criação de blocos.

O Bitcoin estabeleceu um conjunto claro e definitivamente objetivo de regras que o blockchain deve seguir para superar o problema dos generais bizantinos. Um participante da rede deve publicar uma prova de trabalho para adicionar informações ao blockchain (daí prova de trabalho). Isso é caro para o participante e o desencoraja de compartilhar informações falsas, pois elas serão refutadas por outros participantes da rede.

Todas as regras são claras e objetivas, ou seja, as informações não podem ser alteradas.

E a prova de participação?

As redes governadas pelo algoritmo de consenso proof-of-stake não são baseadas em mineração, mas em staking. Para se tornar um validador de rede, o usuário deve primeiro depositar fundos no sistema. Aqueles que detêm uma parcela maior também podem comprometer mais blocos e receber recompensas maiores. Quem tentar falsificar informações corre o risco de perder sua aposta.

Sistemas diferentes lidam com esse problema de maneiras diferentes. Por exemplo, Ethereum 2.0 usa o algoritmo Casper. requer que pelo menos dois terços da maioria dos nós concordaram com um determinado blocoantes de ser criado e adicionado à rede.

Existem diferentes tentativas de resolver o problema, dependendo da necessidade do sistema e da abordagem da equipe. Por exemplo, com a prova de participação delegada (dPoS), o consenso é alcançado muito mais rapidamente. Por outro lado, alguns sistemas usam tolerância a falhas bizantinas na prática.