> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# IntentionBFT

> Consenso: como uma ordenação e um vetor de preços certificado são confirmados em conjunto, e como a rede está organizada.

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](/pt/protocol/architecture/kernel) consegue garantir sobre a execução depende de ambos estarem fixados antes de a execução começar.

<h2 id="model">
  Modelo
</h2>

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+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.

<div className="dg" data-dg="bft-prices">
  <div className="dg-c" style={{aspectRatio:"720 / 318"}}>
    <svg className="dg-w" viewBox="0 0 720 318" aria-hidden="true">
      <path className="dg-wire" d="M 163.00 78.00 L 176.60 78.00" />

      <path className="dg-head" d="M 183.00 78.00 L 176.60 82.40 L 176.60 73.60 Z" />

      <path className="dg-wire" d="M 350.00 78.00 L 363.60 78.00" />

      <path className="dg-head" d="M 370.00 78.00 L 363.60 82.40 L 363.60 73.60 Z" />

      <path className="dg-wire" d="M 537.00 78.00 L 550.60 78.00" />

      <path className="dg-head" d="M 557.00 78.00 L 550.60 82.40 L 550.60 73.60 Z" />
    </svg>

    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Sidecar de oráculo</span><span className="dg-s">um por validador</span></div>
    <div className="dg-b dg--blue" style={{left:"25.9722%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">O validador valida e assina</span><span className="dg-s">incluindo a atualidade face a limiares configurados</span></div>
    <div className="dg-b dg--blue" style={{left:"51.9444%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Gossip entre validadores</span><span className="dg-s">como mensagem da rede de consenso</span></div>
    <div className="dg-b dg--green" style={{left:"77.9167%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Preços certificados</span><span className="dg-s">por epoch e ronda</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"0.0000%",top:"48.4277%",width:"100.0000%",height:"21.3836%"}}><span className="dg-t">Os preços condicionam a produção de blocos</span><span className="dg-s">Um 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.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"75.4717%",width:"100.0000%",height:"19.4969%"}}><span className="dg-t">O que isto não afirma</span><span className="dg-s">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, e mais nada.</span></div>
  </div>
</div>

Cada ronda tem um líder designado. Dentro de uma ronda, uma proposta recolhe agregados sucessivos de assinaturas $2f+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.

<h2 id="committing-an-ordering">
  Confirmar uma ordenação
</h2>

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+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.

<Note>
  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.
</Note>

<h2 id="batch-availability">
  Disponibilidade dos lotes
</h2>

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+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.

<h2 id="certifying-prices">
  Certificar preços
</h2>

Os validadores são também observadores de preços, e um bloco transporta os preços contra os quais foi executado.

<div className="dg" data-dg="bft-topology">
  <div className="dg-c" style={{aspectRatio:"720 / 322"}}>
    <svg className="dg-w" viewBox="0 0 720 322" aria-hidden="true">
      <path className="dg-wire dg-soft" d="M 215.00 95.00 L 215.00 99.00" />

      <path className="dg-wire dg-soft" d="M 215.00 167.00 L 215.00 171.00" />

      <path className="dg-wire dg-soft" d="M 215.00 239.00 L 215.00 243.00" />
    </svg>

    <div className="dg-b dg--blue dg-left" style={{left:"0.0000%",top:"9.3168%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Validadores</span><span className="dg-s">consenso · mempool · sidecar de oráculo · kernel · armazenamento</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"9.3168%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Os únicos participantes que votam</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"0.0000%",top:"31.6770%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Nós completos de validador</span><span className="dg-s">seguem e executam blocos confirmados; não votam</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"31.6770%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Isolamento — absorvem tráfego público de leitura e ligações de pares, para que os validadores não fiquem expostos à internet aberta</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"0.0000%",top:"54.0373%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Nós completos públicos</span><span className="dg-s">qualquer pessoa pode correr um; seguem, executam, servem leituras</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"54.0373%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">O nível aberto</span></div>
    <div className="dg-b dg--green dg-left" style={{left:"0.0000%",top:"76.3975%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Clientes</span><span className="dg-s">front ends · agentes · market makers · indexadores</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"76.3975%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">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.</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"0.0000%",width:"59.7222%"}}><div className="dg-n">Quatro níveis, a partir do consenso</div></div>
    <div className="dg-free" style={{left:"63.6111%",top:"0.0000%",width:"36.3889%"}}><div className="dg-n">Porquê cada nível</div></div>
  </div>
</div>

Cada validador corre o seu próprio [sidecar de oráculo](/pt/protocol/architecture/oracle), 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.

<Warning>
  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](/pt/protocol/architecture/oracle) e delimitada pelas [advertências de risco](/pt/protocol/security/risks).
</Warning>

<h2 id="leader-reputation">
  Reputação do líder
</h2>

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.

<h2 id="epochs-and-reconfiguration">
  Epochs e reconfiguração
</h2>

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.

<h2 id="network-topology">
  Topologia da rede
</h2>

<div className="dg" data-dg="bft-round">
  <div className="dg-c" style={{aspectRatio:"720 / 318"}}>
    <svg className="dg-w" viewBox="0 0 720 318" aria-hidden="true">
      <path className="dg-rule dg-dash" d="M 90 40 L 90 266" />

      <path className="dg-rule dg-dash" d="M 360 40 L 360 266" />

      <path className="dg-rule dg-dash" d="M 630 40 L 630 266" />

      <path className="dg-wire dg--blue" d="M 94.00 64.00 L 349.60 64.00" />

      <path className="dg-head dg--blue" d="M 356.00 64.00 L 349.60 68.40 L 349.60 59.60 Z" />

      <path className="dg-wire dg--sky" d="M 364.00 92.00 L 414.00 92.00 L 414.00 114.00 L 374.40 114.00" />

      <path className="dg-head dg--sky" d="M 368.00 114.00 L 374.40 109.60 L 374.40 118.40 Z" />

      <path className="dg-wire dg--sky dg-dash" d="M 356.00 146.00 L 100.40 146.00" />

      <path className="dg-head dg--sky" d="M 94.00 146.00 L 100.40 141.60 L 100.40 150.40 Z" />

      <path className="dg-wire dg--blue" d="M 94.00 218.00 L 349.60 218.00" />

      <path className="dg-head dg--blue" d="M 356.00 218.00 L 349.60 222.40 L 349.60 213.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 364.00 254.00 L 619.60 254.00" />

      <path className="dg-head dg--green" d="M 626.00 254.00 L 619.60 258.40 L 619.60 249.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"2.2222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Líder</span></div>
    <div className="dg-b dg--sky" style={{left:"39.7222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Validadores</span></div>
    <div className="dg-b dg--green" style={{left:"77.2222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Cadeia</span></div>
    <div className="dg-b dg-dashed dg-tight dg-solid" style={{left:"14.4444%",top:"52.2013%",width:"33.6111%",height:"8.1761%"}}><span className="dg-s">Agregado ponderado por stake 2f+1</span></div>
    <div className="dg-b dg--green" style={{left:"68.8889%",top:"86.7925%",width:"31.1111%",height:"11.9497%"}}><span className="dg-s">Ordenação e preços já são imutáveis</span></div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"15.0943%",width:"34.4444%",whiteSpace:"normal"}}>Propor bloco — digests de lotes e preços certificados</div>
    <div className="dg-lbl" style={{left:"72.7778%",top:"32.3899%",width:"26.3889%",whiteSpace:"normal"}}>Verificar disponibilidade, ordenação, preços</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"40.8805%"}}>Votar</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"63.5220%"}}>Certificar a ronda</div>
    <div className="dg-lbl" style={{left:"68.7500%",top:"74.8428%"}}>Confirmar</div>
  </div>
</div>

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](/pt/protocol/architecture/state/sync) para saber como um nó novo se põe em dia.

<h2 id="where-to-go-next">
  Para onde ir a seguir
</h2>

<CardGroup cols={2}>
  <Card title="Mempool" href="/pt/protocol/architecture/mempool">
    O que chega ao consenso, por que ordem e o que é descartado.
  </Card>

  <Card title="IntentionKernel" href="/pt/protocol/architecture/kernel">
    O que acontece a um bloco depois de a sua ordenação e os seus preços serem confirmados.
  </Card>

  <Card title="Oráculo" href="/pt/protocol/architecture/oracle">
    Como um preço do índice é produzido antes de um validador o assinar.
  </Card>

  <Card title="Operar um nó" href="/pt/developers/run-a-node">
    Porque é fechado o conjunto de validadores e como perguntar sobre a adesão.
  </Card>
</CardGroup>