Consenso de escalonamento para empresas: explicando o algoritmo IBFT

NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressboletins informativos

Assine a nossa newsletter.

Endereço de email

Nós respeitamos sua privacidade

HomeBlog Enterprise Blockchain

Consenso de escalonamento para empresas: explicando o algoritmo IBFT

Como Istanbul Byzantine Fault Tolerance (IBFT) melhora a finalidade e aumenta a taxa de transferência em redes privadas Ethereum.by ConsenSys 22 de junho de 2018Postado em 22 de junho de 2018

Algoritmos de consenso são uma das principais inovações do blockchain, mas também uma das mais confusas. Satoshi Nakamoto criou uma versão da Prova de Trabalho (PoW) que foi implementada como um meio para proteger e validar simultaneamente transações Bitcoin. A comunidade blockchain desenvolveu essa visão central para criar uma sopa de letrinhas de Prova de Participação (PoS), Prova de Autoridade (PoA), PBFT (Prático Bizantino Tolerante a Falhas) e muitos outros que são projetados para construir consenso em um sistema distribuído sistema, criando a única fonte de verdade que torna o blockchain tão valioso.

IBFT (Istanbul Byzantine Fault Tolerant) é um mecanismo de consenso que é uma alternativa à Prova de Trabalho em uma rede Ethereum. Como outros algoritmos, o IBFT garante um pedido único e acordado para transações no blockchain e fornece benefícios adicionais para empresas, incluindo finalização da liquidação. IBFT era implementado pela primeira vez em Geth pela Amis Technologies, e logo depois implementado no Quorum.

Antes de entrar na operação do mecanismo de consenso do IBFT, vale a pena mencionar quando e por que se deseja usar o IBFT. Em um blockchain público, a resposta curta é provável que você provavelmente não faria. Mas quando se trata de consórcio ou blockchains privados, o IBFT começa a parecer bastante atraente.

O algoritmo PoW é notoriamente caro, tanto em hardware quanto em eletricidade. Esse custo é intencional, para evitar que qualquer pessoa controle facilmente a rede e, portanto, PoW é muito adequado para situações com descentralização total, onde qualquer pessoa (incluindo invasores) pode participar. Os nós nas redes de consórcio / privadas usados por empresas, no entanto, são intrinsecamente mais confiáveis do que aqueles em uma rede pública. Como tal, o mecanismo de consenso PoW pode ser excessivamente oneroso e outros mecanismos podem fornecer confiança “suficiente” para executar um sistema distribuído.

A prova de interesse, da mesma forma, pode ser menos relevante para as empresas, porque pagar pelo gás é menos importante em uma rede autorizada. Uma vez que os nós não precisam (necessariamente) manter a circulação na rede, o PoS introduziria requisitos estranhos.

Considerando essas compensações, a Prova de Autoridade (PoA) surge como a melhor solução possível, utilizando um sistema em que os nós da rede têm o privilégio de produzir novos blocos para a cadeia usando um round-robin ou outro sistema arbitrário.

IBFT é um dos muitos sabores de PoA e oferece os seguintes benefícios:

Finalidade do bloco imediato. Existe apenas 1 bloco proposto para uma determinada altura de corrente. A cadeia única remove, assim, bifurcações, blocos de tio e o risco de que uma transação possa ser “desfeita” uma vez na cadeia posteriormente.
Tempo reduzido entre blocos. O esforço necessário para construir e validar blocos é significativamente reduzido (em particular no que diz respeito ao PoW), aumentando muito o rendimento da cadeia.
Alta integridade de dados e tolerância a falhas. O IBFT usa um grupo de validadores para garantir a integridade de cada bloco proposto. Uma supermaioria (~ 66%) desses validadores é obrigada a assinar o bloco antes da inserção na corrente, tornando a falsificação do bloco muito difícil. A “liderança” do grupo também gira ao longo do tempo – garantindo que um nó com defeito não possa exercer influência a longo prazo sobre a cadeia.
Operacionalmente flexível. O grupo de validadores pode ser modificado com o tempo, garantindo que o grupo contenha apenas nós totalmente confiáveis.

Aqui, fornecemos uma visão geral do IBFT, em sua maioria em termos não técnicos. Para algumas das propostas originais do IBFT, você pode revisar os EIPs no GitHub:

Documentação IBFT: https://github.com/ethereum/EIPs/issues/650
Código usado no Quorum: https://github.com/jpmorganchase/quorum

No restante deste artigo, exploraremos as considerações mais técnicas do IBFT, discutindo muitos dos conceitos encontrados nos EIPs e que aprendemos por meio de nossa própria pesquisa.

Observação: o código IBFT também pode ser encontrado em uma solicitação de pull go-ethereum # 16385.

Operação

O mecanismo de consenso IBFT compreende os seguintes componentes:

UMA PBFT modelo de consenso de grupo inspirado.
Um processo pelo qual os membros podem ser adicionados / removidos do grupo de validação.

IBFT requer que o cabeçalho do bloco seja (sutilmente) retrabalhado para oferecer suporte a todas as facetas da capacidade.

Modelo de consenso de grupo

Visão geral

IBFT usa um conjunto de nós de validação (validadores) operando em uma rede Ethereum para determinar se um bloco proposto é adequado para adição à cadeia.

Um nó dos Validadores é selecionado arbitrariamente como Proponente e é responsável por construir um bloco no intervalo de bloco e compartilhar esse bloco com o grupo. Se a maioria dos validadores considerar o bloco válido, ele será adicionado ao blockchain.

Na conclusão da rodada de consenso, os Validadores podem selecionar um novo Proponente que será responsável por fornecer o Bloco candidato no próximo intervalo de bloco.

O mecanismo de consenso é uma máquina de estado sincronizado que é responsável por garantir que todos os Validadores anexem o mesmo bloco à cadeia na mesma altura.

Se um bloco não consegue inserir, o Proponente é alterado, e o processo começa novamente.

Para garantir que apenas um bloco possa ser anexado à máquina de estado, o IBFT evita a alteração do bloco proposto, uma vez que a maioria dos validadores concordou com sua inserção (mas não realizou o referido trabalho), este processo é conhecido como “Bloqueio de Bloco”.

O mecanismo de consenso IBFT oferece estabilidade do sistema, desde que menos de 1/3 dos nós de validação estejam se comportando incorretamente (devido a estarem comprometidos ou devido a código com defeito). Ou seja, para tolerar nós com falha F, o grupo de validação deve conter pelo menos 3F + 1 nós (mais do que isso não aumenta a integridade do sistema).

Nota: Aqui, F implica o número de nós defeituosos tolerados pelo sistema.

Máquina de Estado

Máquina de Estado IBFT

Estados

Aguardando Proposta. O validador está aguardando que um novo bloco seja fornecido pelo proponente atual. Se o validador for o proponente desta rodada, ele prepara o bloco proposto e o transmite em uma mensagem de pré-preparação.
Preparando. Recebeu um bloco proposto (válido) e notificou os pares de validação; está agora esperando que os pares validadores notifiquem sua aceitação do bloqueio.
Preparar. Recebeu a aceitação do validator-peer do bloqueio e está esperando que eles estejam em uma posição semelhante. Nesta fase, o bloco proposto foi “bloqueado” e não pode ser substituído até que uma tentativa de inserção tenha sido conduzida.
Mudança de Rodada. A rodada expirou antes que o consenso fosse alcançado ou o bloco falhou na inserção. Aguarde até que todos os validadores concordem com o número da próxima rodada.

Transições

UMAaguardando Proposta → Preparando. Na recepção de um novo bloco (mensagem de pré-preparação) do proponente (ou seja, o bloco é válido em seu conteúdo, assim como seu ponto de inserção de cadeia proposto).
Aguardando proposta → Mudança da rodada. A proposta recebida não era um bloco válido de acordo com um determinado conjunto de regras (por exemplo, proponente inválido, numeração de rodadas incorreta).
Preparando → Pronto. Na recepção de notificações 2F + 1 (mensagem de preparação) de pares validadores indicando que o bloco proposto é adequado para inserção.
Pronto → Aguardando Proposta. Na recepção de notificações 2F + 1 (mensagem de confirmação) de pares validadores indicando que eles estão prontos para anexar o bloco à cadeia. Na transição, o processo de anexar o bloco à cadeia é executado (sucesso).
Pronto → Mudança de rodadas. Conforme Pronto->Aguardando proposta, no entanto, a inserção do bloco falhou.
Mudança de rodada → Aguardando proposta. 2F + 1 dos validadores concordam com o número da próxima rodada a ser usado.

Nota: Todas as transições para “RoundChange” resultam no Validador transmitindo uma mensagem “RoundChange” para seus pares validadores.

Bloqueio de bloco

O IBFT determina que garfos não sejam criados. Para este fim, uma vez que um bloqueio tenha sido acordado pela maioria (ou seja, na entrada no estado Pronto), ele se torna “bloqueado”.

Isso significa que nenhum outro bloco será considerado para inserção até que uma tentativa de adicionar este bloco à cadeia tenha sido tentada. Assim, ou o bloco é inserido com sucesso (uma vez que mensagens de confirmação suficientes são recebidas, seja nesta ou nas rodadas subsequentes), ou o bloco falha na inserção, é descartado e um novo bloco é proposto na altura da corrente atual.

Associação ao Grupo de Validação

Os membros do grupo de validação podem mudar com o tempo por meio de um mecanismo de votação. Os membros podem ser adicionados ou removidos por maioria (piso (N / 2) + 1) voto; cada voto é capturado no cabeçalho do bloco.

Cada nó na rede (incluindo nós não validadores) é responsável por rastrear a contagem de votos para cada validador para determinar os validadores atuais e garantir que as assinaturas nos blocos minerados caiam dentro do grupo esperado.

Dado que cada voto está contido no Cabeçalho do Bloco, apenas o Proponente de uma determinada rodada pode votar. Portanto, é importante, se os nós forem adicionados / removidos em tempo hábil, que a função do Proponente seja atualizada regularmente.

Uma vez que um nó atinge a maioria dos votos, ele imediatamente se junta / sai do grupo validador.

IBFT reconhece uma Época de Votação, que define um ponto em que todos os votos que ainda não alcançaram a maioria são removidos, forçando a contagem de votos a ser reiniciada. Isso significa que, ao computar os votos, os validadores precisam apenas começar na época mais recente. Por padrão, a Época de Votação ocorre a cada 30.000 blocos.

Os votos definem uma mudança de estado (ou seja, os candidatos são votados, os validadores são eliminados), não votar em um determinado nó implica que o Validador não deseja que o nó mude de estado (um voto explícito não é necessário para manter o status quo).

Block Header Refactor

Para oferecer suporte ao IBFT no Ethereum, várias alterações devem ser feitas nos cabeçalhos dos blocos. Essas mudanças incluem:

beneficiário: identifica o nó para o qual um voto está sendo lançado.
nonce: especifica a “direção” do voto – AUTH ou DROP.
mixHash: um número mágico fixo, identificando este bloco como sendo validado pelo IBFT.
ommersHash: deve ser o hash de um conjunto vazio, pois não há blocos ommer ao operar sob IBFT.
carimbo de data / hora: deve ser pelo menos o carimbo de data / hora + intervalo de bloco do bloco pai.
dificuldade: deve ser preenchido com 0x0000000000000001.
extraData: contém dados específicos IBFT, incluindo Lista de Endereços do Validador, ProposerSeal (identifica o proponente), CommittingSeals (lista dos validadores que relataram ‘cometer’ neste bloco).

Como a lista de CommittingSeals para cada validador é (potencialmente) diferente, é importante que o hash do bloco não inclua essas informações – ou seja, embora dois blocos tenham campos CommittingSeals diferentes, eles representam as mesmas informações (ou seja, as transações, etc. são idênticas).

Conclusão

No fechamento, IBFT é uma solução tolerante a falhas bizantina que oferece finalização de transação imediata que reduz a infraestrutura necessária que PoW exige.

Embora seja improvável que seja usado em Ethereum mainnet (com um conjunto muito mais amplo e desconhecido de atores participantes), ele oferece um benefício substancial quando usado em uma rede privada onde o conjunto de validadores é confiável e responsável; fornece uma solução ideal para uma cadeia com uma cadência fixa e uma taxa de processamento de transação previsível.

Os processos explorados neste artigo dão confiança de que uma rede que emprega IBFT será tolerante com os nós bizantinos e pode ser recuperada caso esses nós sejam vistos exercendo controle sobre a rede.

Boletim informativo Assine nosso boletim informativo para obter as notícias mais recentes da Ethereum, soluções empresariais, recursos para desenvolvedores e muito mais. Endereço de e-mailConteúdo exclusivoGuia