Skip to main content
O IntentionBFT é o protocolo de consenso da Intention — um protocolo BFT da família HotStuff estendido para infraestrutura financeira. A segurança (safety) mantém-se incondicionalmente abaixo do limiar de falhas; a vivacidade (liveness) mantém-se depois de a rede estabilizar. Aqui o consenso faz duas coisas que o consenso de uma cadeia de uso geral não faz: confirma uma ordenação como objeto de primeira classe e confirma um vetor de preços certificado no mesmo evento. Tudo o que o kernel consegue garantir sobre a execução depende de ambos estarem fixados antes de a execução começar.

​
Modelo

O IntentionBFT tolera um adversário bizantino que controle até um terço do stake total. O stake honesto é, portanto, sempre superior a dois terços, e o quórum padrão é qualquer conjunto de validadores cujo stake combinado exceda dois terços — o que estas páginas chamam um quórum ponderado por stake de 2f+12f+1. A rede é parcialmente síncrona: antes de um ponto de estabilização os atrasos são arbitrários; depois dele, os atrasos entre validadores honestos são limitados.
Sidecar de oráculoum por validador
O validador valida e assinaincluindo a atualidade face a limiares configurados
Gossip entre validadorescomo mensagem da rede de consenso
Preços certificadospor epoch e ronda
Os preços condicionam a produção de blocosUm validador só é elegível para propor um bloco se apresentar observações de preço válidas para a ronda atual — pelo que as assinaturas que confirmam as transações confirmam também os preços contra os quais são liquidadas.
O que isto não afirmaLiga o preço à transação. Não torna o preço correto — o consenso certifica que um quórum de validadores submeteu estas observações nesta ronda, e mais nada.
Cada ronda tem um líder designado. Dentro de uma ronda, uma proposta recolhe agregados sucessivos de assinaturas 2f+12f+1, e as fases encadeiam-se em pipeline entre rondas adjacentes, pelo que um bloco se torna definitivo em duas idas e voltas de rede no caso comum. Sob capacidade de resposta otimista, o progresso é limitado pelo atraso real das mensagens; o backoff do pacemaker só entra em ação quando a rede é adversarial ou está particionada.

​
Confirmar uma ordenação

A ordem das transações dentro de um bloco é promovida a objeto confirmado pelo consenso, em vez de ficar como um artefacto da execução. O hash do bloco cobre o payload ordenado, pelo que qualquer reordenação após o consenso invalida as assinaturas que o confirmaram. O efeito: assim que um bloco se torna definitivo, um quórum ponderado por stake de 2f+12f+1 assinou um compromisso com essa ordenação exata, e nenhum validador honesto terá assinado uma ordenação diferente das mesmas transações na mesma ronda. Combinado com a execução sequencial sobre essa ordem confirmada, é isto que transforma a reexecução determinista de uma convenção de implementação numa propriedade que qualquer pessoa pode verificar.
A margem de discricionariedade do líder dentro de uma única proposta — que lotes disponíveis incluir e como os dispor — continua a ser uma superfície residual, mitigada pela reputação do líder e pelo facto de um líder não conseguir sequer produzir um bloco sem observações de preço válidas. Estão em avaliação construções mais fortes de ordenação justa, como candidatas a uma atualização futura.

​
Disponibilidade dos lotes

Num protocolo ingénuo, o líder propõe um bloco cujo payload transporta todas as transações da ronda, acoplando o tamanho das mensagens de consenso ao débito. O IntentionBFT separa a disseminação dos dados da ordenação. Os validadores disseminam continuamente lotes de transações em segundo plano. Cada lote recolhe confirmações de receção até o seu originador conseguir provar disponibilidade ponderada por stake de 2f+12f+1, e só então uma proposta o pode referenciar — por digest, não pelo conteúdo. As mensagens de consenso mantêm-se pequenas independentemente do débito, e um bloco confirmado é sempre reexecutável, porque nenhum bloco pode referenciar dados que apenas uma minoria bizantina detinha.

​
Certificar preços

Os validadores são também observadores de preços, e um bloco transporta os preços contra os quais foi executado.
Validadoresconsenso · mempool · sidecar de oráculo · kernel · armazenamento
Os únicos participantes que votam
Nós completos de validadorseguem e executam blocos confirmados; não votam
Isolamento — absorvem tráfego público de leitura e ligações de pares, para que os validadores não fiquem expostos à internet aberta
Nós completos públicosqualquer pessoa pode correr um; seguem, executam, servem leituras
O nível aberto
Clientesfront ends · agentes · market makers · indexadores
Ligam-se a nós completos, nunca a validadores. Um cliente que precise da visão mais completa e com menor latência corre o seu.
Quatro níveis, a partir do consenso
Porquê cada nível
Cada validador corre o seu próprio sidecar de oráculo, que recolhe dados das plataformas e produz um preço do índice por instrumento. O validador vai buscar esse preço, valida-o — incluindo a atualidade face a limiares configurados —, assina-o e propaga por gossip a submissão assinada aos outros validadores, como mensagem da rede de consenso. Os preços certificados são montados por epoch (época) e ronda e transportados no bloco, pelo que as assinaturas que confirmam as transações confirmam também os preços contra os quais essas transações são liquidadas financeiramente. Um validador só é elegível para propor um bloco se conseguir apresentar observações de preço válidas para a ronda atual. A disponibilidade de preços é, portanto, uma pré-condição da produção de blocos e não uma entrada que a execução espera encontrar.
Isto liga o preço à transação; não torna o preço correto. O consenso certifica que um quórum de validadores submeteu estas observações nesta ronda. Se as plataformas subjacentes estavam certas é uma questão separada, tratada pelas regras de agregação na página Oráculo e delimitada pelas advertências de risco.

​
Reputação do líder

Os líderes são selecionados ronda a ronda por rotação determinista ponderada por stake, estendida com uma heurística de reputação sobre uma janela deslizante. Um validador com propostas falhadas repetidas — indício de indisponibilidade ou de comportamento adversarial — é despromovido em seleções posteriores e os seus slots são redistribuídos por validadores que responderam recentemente, para que um validador indisponível não bloqueie o progresso ao reclamar a liderança dos slots que lhe foram atribuídos. Como as observações de preço condicionam a elegibilidade para propor, a reputação tem também de evitar concentrar a liderança nos validadores com melhor conectividade a dados de mercado. Um requisito de diversidade de plataformas — observações retiradas de várias fontes independentes por instrumento — fecha esse caminho.

​
Epochs e reconfiguração

O tempo é organizado em epochs. Dentro de um epoch, o conjunto de validadores e a maior parte dos parâmetros são constantes. Nas fronteiras entre epochs podem mudar através de uma reconfiguração autorizada pela governação: alterações ao conjunto de validadores, alterações a parâmetros de consenso, atualizações de parâmetros de risco e ações de emergência. As transições são atómicas — todos os validadores honestos veem a mesma transição à mesma altura de bloco.

​
Topologia da rede

Líder
Validadores
Cadeia
Agregado ponderado por stake 2f+1
Ordenação e preços já são imutáveis
Propor bloco — digests de lotes e preços certificados
Verificar disponibilidade, ordenação, preços
Votar
Certificar a ronda
Confirmar
Os validadores participam no consenso. Cada um corre toda a pilha: consenso, mempool, um sidecar de oráculo, execução do kernel e armazenamento. São os únicos participantes que votam. Os nós completos de validador ficam imediatamente atrás dos validadores. Seguem os blocos confirmados e executam-nos, mas não votam. Servem de isolamento — absorvem o tráfego público de leitura e as ligações de pares para que os validadores não fiquem diretamente expostos à internet aberta. Os nós completos públicos são o nível aberto. Qualquer pessoa pode correr um. Seguem a cadeia, executam blocos confirmados, servem leituras e alimentam os sistemas a jusante. Os clientes — front ends, agentes de negociação, market makers, indexadores — ligam-se a nós completos e não a validadores. Um cliente que precise da visão mais completa e com menor latência corre o seu próprio nó completo em vez de depender do nó de outra pessoa. Os nós que se juntam à rede não reexecutam desde a génese por omissão; ver sincronização de estado para saber como um nó novo se põe em dia.

​
Para onde ir a seguir

Mempool

O que chega ao consenso, por que ordem e o que é descartado.

IntentionKernel

O que acontece a um bloco depois de a sua ordenação e os seus preços serem confirmados.

Oráculo

Como um preço do índice é produzido antes de um validador o assinar.

Operar um nó

Porque é fechado o conjunto de validadores e como perguntar sobre a adesão.