Saltar al contenido
Financial Context Wiki

Mecanismos de consenso: validez, elección de bifurcación y finalidad

Un mecanismo de consenso coordina réplicas sobre historiales compatibles bajo supuestos explícitos de fallos y red. Analice por separado la decisión, participantes y pesos, validez, propuesta, elección de bifurcación, finalidad, seguridad, vivacidad y despliegue.

Actualizado

Material educativo de análisis de protocolos. La etiqueta de consenso no demuestra por sí sola seguridad, vivacidad, implementación correcta, descentralización, finalidad, orden justo ni protección de activos en una red desplegada.

Respuesta directa

Un mecanismo de consenso es el protocolo mediante el cual réplicas no defectuosas convergen en decisiones compatibles sobre un registro ordenado o un estado pese al retraso, la concurrencia y los fallos cubiertos por su modelo. En una blockchain, el mecanismo completo puede incluir selección de proponente, validación de bloques y transiciones de estado, votos o pruebas, elección de bifurcación, compromiso o finalidad, recuperación y reglas de membresía. No es solo «muchas computadoras guardan el mismo archivo», un umbral de votos, minería, staking o un calendario de incentivos.

Hay que declarar por separado tres propiedades. safety (seguridad) impide decisiones incompatibles entre participantes no defectuosos; liveness (vivacidad) dice que el trabajo válido puede avanzar finalmente bajo condiciones específicas; validity (validez) restringe qué puede decidirse. Un protocolo puede detenerse conservando la seguridad o continuar bajo supuestos que permiten una reorganización posterior. La palabra «consenso» no identifica por sí sola qué garantía rige, cuándo lo hace ni en qué evidencia debe confiar un cliente.

La validez de una transacción y la selección canónica son distintas. Un nodo completo rechaza de forma independiente una transición que infringe las reglas vigentes. Si dos transacciones individualmente válidas gastan la misma entrada, el orden o la elección de bifurcación decide cuál puede entrar en el historial canónico; una mayoría de recursos no vuelve válidas ambas. Del mismo modo, acordar bytes no prueba que un dato de oráculo, una afirmación de puente, un cálculo de aplicación o una afirmación jurídica sean verdaderos.

Proof of Work y Proof of Stake suelen aportar resistencia Sybil, influencia de propuesta o peso de voto atribuible, pero sus nombres no especifican un protocolo completo. Bitcoin combina prueba de trabajo con validación y selección por trabajo acumulado. Gasper de Ethereum combina atestaciones ponderadas por stake, elección LMD-GHOST y finalidad de puntos de control Casper FFG. Un BFT por rondas como CometBFT tiene otros mensajes, umbrales, supuestos temporales y finalidad. Sus porcentajes no son intercambiables.

Cómo analizarlo

  1. Nombre la decisión y el alcance. Precise si las réplicas deciden un valor, un registro ordenado, un bloque por altura, un punto de control o un estado de aplicación; identifique cadena, red, capa, versión y punto inicial de confianza.
  2. Defina participantes e influencia. Separe proponentes, votantes, validadores completos, clientes ligeros y observadores. Registre altas y bajas de identidades, si la influencia sigue hash, stake, membresía igual u otro peso, y qué impide identidades duplicadas baratas.
  3. Separe las etapas. Documente validez de transacción y estado, construcción y difusión de propuestas, voto o prueba, elección de bifurcación, compromiso, finalidad y recuperación. Un bloque válido puede perder la elección y una cabeza canónica aún no estar finalizada.
  4. Declare el modelo del sistema. Defina canales autenticados, sincronía o sincronía parcial, retrasos y tiempos de espera, fallos por parada y bizantinos, equívoco, omisión, corrupción adaptativa, robo de claves, particiones y el máximo número o peso defectuoso f.
  5. Rastree una decisión. Siga dominios de mensajes, alturas, rondas, padres, bloqueos, certificados y estado local desde la propuesta hasta la decisión. Muestre qué ocurre con mensajes tardíos, un proponente equívoco, una ronda agotada o dos ramas válidas.
  6. Verifique seguridad y vivacidad por separado. Derive intersección de cuórums, crecimiento de cadena u otras condiciones con el conjunto y la instantánea de pesos exactos. Después compruebe si queda conectividad y participación honesta suficiente para avanzar; no deduzca vivacidad de un umbral de seguridad.
  7. Lleve la prueba al despliegue. Revise versiones de clientes, cambios de parámetros, concentración de miembros y stake, custodia de claves, diversidad de pares, papeles de builder o secuenciador, puntos de control, reglas de subjetividad débil, reorganizaciones y política de confirmación de la aplicación.

FLP no afirma que el consenso desplegado sea imposible. Demuestra que, en un modelo de mensajes totalmente asíncrono, incluso un fallo por parada deja alguna ejecución admisible en la que un protocolo determinista no termina. Los protocolos reales obtienen garantías útiles añadiendo sincronía o sincronía parcial, aleatoriedad, detectores de fallos, supuestos económicos o promesas de terminación más débiles. Esas adiciones deben nombrarse, no ocultarse tras una etiqueta.

Ejemplos resueltos

1. Validez no es orden canónico

Una salida no gastada U vale 1 BTC. La transacción T_B la gasta hacia Bob y T_C gasta la misma salida hacia Carol. Respecto del mismo estado padre, cada una puede tener firma y formato correctos, pero un historial válido no puede consumir U dos veces.

Si dos bloques válidos competidores contienen una transacción cada uno, la validación conserva localmente ambas ramas candidatas y la elección de bifurcación selecciona una rama canónica. Cuando T_B entra en el historial elegido, T_C entra en conflicto con el estado resultante. El consenso eligió un orden; no corrigió una firma mala ni decidió qué receptor merecía moralmente el pago.

2. Trabajo acumulado, no número de nodos

Suponga que dos ramas válidas al estilo Bitcoin tienen puntuaciones de trabajo acumulado W_A=240 y W_B=235 en la misma unidad arbitraria. Un nodo validador elige A por la regla de trabajo acumulado aunque haya oído B primero de más pares. El número de pares no es peso de consenso.

Si B suma después 10 unidades y A ninguna, queda W_B=245 frente a W_A=240, por lo que el nodo puede reorganizarse a B tras validar la rama. Esta aritmética simplificada muestra por qué la confirmación PoW es probabilística: reemplazar historia profunda se encarece progresivamente, no se vuelve lógicamente imposible tras un número fijo de bloques.

3. Cuórum BFT ponderado y detención de vivacidad

Sea el peso validador total 100 y suponga que un compromiso al estilo CometBFT requiere precompromisos >2/3 para el mismo bloque, altura y ronda. El peso entero 67 pasa. Dos cuórums de peso 67 se intersectan en al menos 34, porque 67 + 67 - 100 = 34. Si el peso bizantino es inferior a un tercio, la intersección contiene peso honesto que no debe firmar compromisos contradictorios.

El mismo umbral revela un límite de vivacidad. Si 34 de peso quedan fuera de línea, solo quedan 66 y no puede formarse un compromiso aunque todos los validadores conectados sean honestos. El protocolo puede detenerse conservando seguridad; un voto de gobernanza o el número de operadores no sustituye el peso ausente.

4. Elección de bifurcación y finalidad de puntos de control son distintas

En una traza simplificada de Gasper, sean C_0, C_1 y su hijo directo C_2 los puntos de control. Votos que representan 67/100 del saldo efectivo activo pueden crear un enlace de supermayoría de C_0 a C_1, justificando C_1. Otro enlace válido de C_1 a C_2 puede finalizar el punto anterior bajo la regla FFG aplicable.

Entre puntos de control, LMD-GHOST usa las últimas atestaciones para elegir la cabeza entre descendientes viables del punto justificado, mientras las restricciones del punto finalizado filtran ramas incompatibles. Elegir cabeza, justificar y finalizar son transiciones relacionadas pero distintas; «67% votó por este bloque» no describe por completo ninguna.

Riesgos y fallos de revisión

Modelo y garantías

  • Decir «la red logra consenso» sin definir decisión, seguridad, vivacidad, validez y terminación.
  • Tratar Proof of Work, Proof of Stake, minería, staking o un porcentaje como especificación completa.
  • Aplicar 51%, 2/3 o n=3f+1 universalmente a modelos distintos de fallos, tiempo, peso y finalidad.
  • Mezclar parada, comportamiento bizantino, robo de claves, canales defectuosos, software correlacionado y captura de gobernanza.
  • Invocar FLP como prohibición del consenso práctico y no como resultado de determinismo, asincronía total y terminación garantizada.
  • Contar nodos o claves sin medir operadores independientes, peso, clientes, nubes y custodia.
  • Suponer que canónico, safe, justificado, comprometido y finalizado son estados intercambiables.
  • Inferir verdad externa, orden justo, privacidad, descentralización o valor del acuerdo replicado.

Protocolo e implementación

  • Aceptar bloques o votos sin vincular cadena, versión, altura, ronda, padre, carga, remitente y época de membresía.
  • Permitir que implementaciones discrepen en transición, serialización, dominio de firma, elección, desempate o redondeo.
  • Verificar un certificado sin reconstruir la instantánea de peso elegible y el tratamiento de firmantes duplicados.
  • Reproducir votos, trabajo o certificados entre bifurcaciones, redes, rondas, actualizaciones o cambios de validadores.
  • Actualizar mal bloqueos, puntos justificados o certificados máximos durante espera, cambio de vista o recuperación.
  • Tratar una cabeza observada localmente o la etiqueta de un solo RPC como evidencia independiente de finalidad.
  • Probar solo el camino feliz, no retrasos, particiones, equívocos, propuestas inválidas, reorganizaciones y recuperación.

Despliegue y aplicación

  • Concentrar hash, stake, clientes, relés, builders, secuenciadores, nubes o firma tras identidades nominalmente separadas.
  • Fijar esperas o intervalos inferiores a tiempos reales de propagación y validación, dañando vivacidad o aumentando bifurcaciones.
  • Acreditar depósitos, acuñar activos puente o ejecutar acciones irreversibles antes de la finalidad necesaria de origen y aplicación.
  • Suponer que penalizaciones, recompensas o precio del token siempre crean un presupuesto de seguridad suficiente y líquido.
  • Usar recuperación social o gobernanza sin reconocer quién coordina, qué cadena instalan los clientes y qué garantía anterior cambió.

Errores comunes

  • Consenso y validación son lo mismo. La validación rechaza datos contra las reglas; el consenso elige decisiones compatibles entre candidatos quizá válidos localmente.
  • Más nodos significan automáticamente más seguridad. Influencia, independencia, topología, diversidad de software y modelo de fallos importan más que el recuento bruto.
  • Un atacante del 51% puede falsificar cualquier firma. El recurso mayoritario puede permitir censura o reorganización en cierto protocolo, pero no revela claves ni autoriza gastos inválidos.
  • Dos tercios siempre significan finalidad. La desigualdad, mensaje, ronda, instantánea de peso, bloqueo y condición de finalidad son específicos del protocolo.
  • Bloques rápidos prueban consenso fuerte. Intervalos cortos pueden aumentar carreras de propagación y presión de recursos; evalúe latencia con seguridad, vivacidad y finalidad.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...