> ## 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
> El consenso: cómo se confirman juntos un orden y un vector de precios certificados, y cómo está dispuesta la red.
IntentionBFT es el protocolo de consenso de Intention: un protocolo BFT de la familia HotStuff extendido para infraestructura financiera. La seguridad se mantiene incondicionalmente por debajo del umbral de fallos; la vivacidad se mantiene una vez que la red se estabiliza.
Aquí el consenso hace dos cosas que el consenso de una cadena de propósito general no hace: confirma **un orden** como objeto de primera clase y confirma **un vector de precios certificados** en el mismo evento. Todo lo que el [kernel](/es/protocol/architecture/kernel) puede garantizar sobre la ejecución depende de que ambos queden fijados antes de que la ejecución empiece.
El modelo
IntentionBFT tolera a un adversario bizantino que controle hasta un tercio del stake total. El stake honesto es por tanto siempre superior a dos tercios, y el quórum estándar es cualquier conjunto de validadores cuyo stake combinado supere los dos tercios: lo que estas páginas llaman un **quórum de $2f+1$ ponderado por stake**. La red es parcialmente síncrona: antes de un punto de estabilización los retardos son arbitrarios; después de él, los retardos entre validadores honestos están acotados.
Sidecar de oráculouno por validador
El validador valida y firmaincluida la frescura frente a umbrales configurados
Gossip entre validadoresmensaje de la red de consenso
Precios certificadospor epoch y ronda
Sin precios disponibles no hay bloqueUn validador solo puede proponer un bloque si presenta observaciones de precio válidas para la ronda en curso — así, las firmas que confirman las transacciones confirman también los precios contra los que se compensan.
Lo que esto no afirmaAta el precio a la transacción; no hace que el precio sea correcto — el consenso certifica que un quórum de validadores envió estas observaciones en esta ronda, nada más.
Cada ronda tiene un líder designado. Dentro de una ronda, una propuesta reúne agregados sucesivos de firmas $2f+1$, y las fases se solapan en pipeline entre rondas adyacentes, de modo que un bloque alcanza la firmeza en dos viajes de ida y vuelta por la red en el caso común. Con capacidad de respuesta optimista, el avance queda acotado por el retardo real de los mensajes; el backoff del pacemaker solo entra en juego cuando la red es adversarial o está particionada.
Confirmar un orden
El orden de las transacciones dentro de un bloque se eleva a objeto confirmado por el consenso en lugar de quedar como un subproducto de la ejecución. El hash del bloque cubre el payload ordenado, así que cualquier reordenación posterior al consenso invalida las firmas que lo confirmaron.
El efecto: una vez que un bloque es firme, un quórum de $2f+1$ ponderado por stake ha firmado un compromiso con ese orden exacto, y ningún validador honesto habrá firmado un orden distinto de las mismas transacciones en la misma ronda. Junto con la ejecución secuencial sobre ese orden confirmado, esto es lo que convierte la reejecución determinista de una convención de implementación en una propiedad que cualquiera puede comprobar.
La discrecionalidad del líder dentro de una misma propuesta (qué lotes disponibles incluir y cómo disponerlos) sigue siendo una superficie residual, mitigada por la reputación del líder y por el hecho de que un líder no puede producir bloque alguno sin observaciones de precio válidas. Se hace seguimiento de construcciones de ordenación equitativa más fuertes como posible mejora futura.
Disponibilidad de los lotes
En un protocolo ingenuo, el líder propone un bloque cuyo payload lleva todas las transacciones de la ronda, lo que acopla el tamaño de los mensajes de consenso al rendimiento. IntentionBFT separa la difusión de datos de la ordenación.
Los validadores difunden continuamente lotes de transacciones en segundo plano. De cada lote se acusa recibo hasta que su originador puede demostrar disponibilidad $2f+1$ ponderada por stake, y solo entonces puede una propuesta referenciarlo, por digest y no por contenido. Los mensajes de consenso se mantienen pequeños con independencia del rendimiento, y un bloque confirmado siempre es reejecutable, porque ningún bloque puede referenciar datos que solo tuviera en su poder una minoría bizantina.
Certificar los precios
Los validadores son además observadores de precios, y un bloque lleva consigo los precios contra los que se ejecutó.
Se conectan a nodos completos, nunca a validadores. Quien necesita la vista más completa y de menor latencia ejecuta el suyo.
Cuatro niveles, del consenso hacia fuera
Por qué existe el nivel
Cada validador ejecuta su propio [sidecar de oráculo](/es/protocol/architecture/oracle), que recoge datos de los exchanges y produce un precio índice por instrumento. El validador toma ese precio, lo valida (incluida su frescura frente a los umbrales configurados), lo firma y difunde por gossip el envío firmado a los demás validadores como mensaje de la red de consenso. Los precios certificados se ensamblan por epoch y ronda y viajan en el bloque, de modo que las firmas que confirman las transacciones confirman también los precios contra los que esas transacciones se compensan.
Un validador solo puede proponer un bloque si es capaz de presentar observaciones de precio válidas para la ronda en curso. La disponibilidad de precios es por tanto una precondición de la producción de bloques, no una entrada que la ejecución espera encontrar.
Esto ata el precio a la transacción; no hace que el precio sea correcto. El consenso certifica que un quórum de validadores envió estas observaciones en esta ronda. Si los exchanges subyacentes eran exactos es otra cuestión, que abordan las reglas de agregación de la página [Oráculo](/es/protocol/architecture/oracle) y acotan las [advertencias de riesgo](/es/protocol/security/risks).
Reputación del líder
Los líderes se seleccionan ronda a ronda mediante una rotación determinista ponderada por stake, ampliada con una heurística de reputación sobre una ventana deslizante. Un validador con propuestas fallidas repetidas (señal de indisponibilidad o de comportamiento adversarial) queda degradado en las selecciones posteriores y sus turnos se redistribuyen entre validadores que han respondido recientemente, de modo que un validador no disponible no frene el avance reclamando el liderazgo de los turnos que tiene asignados.
Como las observaciones de precio condicionan la elegibilidad para proponer, la reputación también tiene que evitar concentrar el liderazgo en los validadores con mejor conectividad a datos de mercado. Un requisito de diversidad de exchanges (observaciones tomadas de varias fuentes independientes por instrumento) cierra esa vía.
Epochs y reconfiguración
El tiempo se organiza en epochs. Dentro de un epoch, el conjunto de validadores y la mayoría de los parámetros son constantes. En los límites entre epochs pueden cambiar mediante una reconfiguración autorizada por la gobernanza: cambios en el conjunto de validadores, cambios de parámetros de consenso, actualizaciones de parámetros de riesgo y acciones de emergencia. Las transiciones son atómicas: todo validador honesto ve la misma transición a la misma altura de bloque.
Topología de la red
Líder
Validadores
Cadena
Agregado 2f+1 ponderado por stake
El orden y los precios son ya inmutables
Propone bloque — digests de lotes y precios certificados
Verifican disponibilidad, orden y precios
Voto
Certifica la ronda
Confirman
**Los validadores** participan en el consenso. Cada uno ejecuta la pila completa: consenso, mempool, un sidecar de oráculo, la ejecución del kernel y el almacenamiento. Son los únicos participantes que votan.
**Los nodos completos de validador** se sitúan justo detrás de los validadores. Siguen los bloques confirmados y los ejecutan, pero no votan. Su función es aislar: absorben el tráfico público de lectura y las conexiones de pares para que los validadores no queden expuestos directamente a la internet abierta.
**Los nodos completos públicos** son el nivel abierto. Cualquiera puede ejecutar uno. Siguen la cadena, ejecutan los bloques confirmados, sirven lecturas y alimentan los sistemas de aguas abajo.
**Los clientes** (front ends, agentes de trading, market makers, indexadores) se conectan a nodos completos y no a validadores. Un cliente que necesita la vista más completa y de menor latencia ejecuta su propio nodo completo en lugar de depender del de otro.
Los nodos que se unen a la red no reejecutan desde el génesis por defecto; consulta [sincronización de estado](/es/protocol/architecture/state/sync) para ver cómo se pone al día un nodo nuevo.
Qué leer a continuación
Qué llega al consenso, en qué orden y qué se descarta.
Qué le ocurre a un bloque una vez confirmados su orden y sus precios.
Cómo se produce un precio índice antes de que un validador lo firme.
Por qué el conjunto de validadores es cerrado y cómo preguntar por la incorporación.