Beacon Chain desde cero

¿Qué hora es en Ethereum? En un servidor normal la respuesta es un timestamp. En la capa de consenso de Ethereum la respuesta es un par de números: el slot y la epoch. Todo lo demás (quién propone el siguiente bloque, quién vota, qué bloque puede quedar finalizado) se calcula a partir de ese reloj.

La Beacon Chain es la cadena que introdujo ese reloj y la prueba de participación. Se lanzó el 1 de diciembre de 2020 como una cadena separada de la red principal, y desde The Merge, en septiembre de 2022, es la capa de consenso de Ethereum. [1] Este capítulo la explica en cuatro piezas: de dónde salió, cómo mide el tiempo, cómo reparte el trabajo y cómo entra y sale un validador.

Preguntas guía

• Si te doy un timestamp Unix, ¿cómo calculas el slot y la epoch de mainnet?
• ¿Por qué cada validador vota una vez por epoch y no en cada slot?
• ¿De dónde sale la aleatoriedad que decide quién propone?
• ¿Qué campos del registro cambian cuando un validador entra, sale o es expulsado?

Conexiones dentro de la serie

• Antes: "Ethereum 2" ya no es el nombre explica por qué hablamos de capa de consenso.
• Después: The Merge: cómo se apagó proof-of-work sin apagar Ethereum conecta esta cadena con la de ejecución.
• Votos: Validadores, attestations y BLS abre el contenido de cada voto.
• Retiros: Shapella: retirar stake sin romper el consenso completa la última etapa del ciclo de vida.

Historia corta: una cadena de votos sin transacciones

La secuencia empieza con un contrato. El contrato de depósito de staking se desplegó en la red principal el 14 de octubre de 2020, en el bloque 11 052 984. [2] Quien quería ser validador enviaba ETH a ese contrato junto con su clave pública.

La especificación fijó un umbral para arrancar: MIN_GENESIS_ACTIVE_VALIDATOR_COUNT = 16 384 validadores y una hora mínima de génesis el 1 de diciembre de 2020 a las 12:00 UTC. [3] Según ethereum.org, los 16 384 depósitos de 32 ETH se alcanzaron el 27 de noviembre y la cadena empezó a producir bloques el 1 de diciembre. [2]

Durante casi dos años la Beacon Chain fue una cadena de bloques "vacíos": acordaba qué validadores estaban activos y cuáles eran sus saldos, pero no procesaba transacciones de usuarios ni contratos. [1] Era un ensayo en producción del mecanismo de consenso antes de conectarlo a la red con dinero de verdad.

El reloj del protocolo: slots, epochs y checkpoints

El tiempo se divide en slots de 12 segundos y epochs de 32 slots. [4] Una epoch dura entonces 384 segundos, 6,4 minutos. En cada slot se elige un validador para proponer un bloque; el slot puede quedar vacío si ese validador no aparece.

El primer bloque de cada epoch es un checkpoint, un punto de control. Los votos de finalidad no apuntan a bloques sueltos sino a pares de checkpoints, y por eso la finalidad avanza a ritmo de epochs y no de slots. [4]

Como el reloj es fijo, se puede calcular. La especificación expresa la duración del slot como SLOT_DURATION_MS = 12 000 y SLOTS_PER_EPOCH = 32. [5] El siguiente fragmento es ilustrativo y usa la hora real de génesis de mainnet que publica ethereum.org (1 de diciembre de 2020, 12:00:23 UTC): [2]

// Ilustrativo: reloj de la Beacon Chain en mainnet.
const GENESIS_TIME = 1606824023; // 2020-12-01T12:00:23Z
const SECONDS_PER_SLOT = 12;
const SLOTS_PER_EPOCH = 32;
 
function beaconClock(unixSeconds) {
  const slot = Math.floor((unixSeconds - GENESIS_TIME) / SECONDS_PER_SLOT);
  const epoch = Math.floor(slot / SLOTS_PER_EPOCH);
  return { slot, epoch, checkpointSlot: epoch * SLOTS_PER_EPOCH };
}
 
// Comprobación: Bellatrix se activó en la epoch 144896.
const t = GENESIS_TIME + 144896 * SLOTS_PER_EPOCH * SECONDS_PER_SLOT;
console.log(new Date(t * 1000).toISOString()); // 2022-09-06T11:34:47.000Z
console.log(beaconClock(t)); // { slot: 4636672, epoch: 144896, checkpointSlot: 4636672 }

La comprobación coincide con la configuración de mainnet, que fecha la epoch 144 896 de Bellatrix el 6 de septiembre de 2022 a las 11:34:47 UTC. [5] Esa coincidencia es la razón por la que, desde Altair, cada actualización de consenso tiene una hora exacta y conocida de antemano. [2]

Figura 1

El reloj de la Beacon Chain: slots, epochs y checkpoints

Fuentes:

[4][3]

Cómo leer esta figura

Fila de casillas numeradas 0, 1, 2, 3, puntos suspensivos y 31 bajo el título epoch e, seguidas de las casillas 0 y 1 de la epoch e más 1. Las casillas 0 de ambas epochs están resaltadas en morado como checkpoints, y una flecha morada las une con la etiqueta voto FFG: source a target. Bajo la casilla 2, una medida indica 12 segundos. Un texto superior dice 32 slots por 12 segundos igual a 384 segundos igual a 6,4 minutos. Un recuadro azul a la izquierda explica: en cada slot un proponente pseudoaleatorio, uno o más comités atestiguan la cabeza, cada validador activo vota una vez por epoch. Un recuadro morado a la derecha explica: el slot 0 de cada epoch es el checkpoint y los votos FFG van de un checkpoint justificado (source) a este (target).

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Cuello de botella y reparto: comités y aleatoriedad

Con cientos de miles de validadores, que todos voten en cada slot saturaría la red. La solución es dividirlos en comités: cada validador activo vota una vez por epoch, en un slot asignado, y no en cada slot. [4]

La especificación fija los tamaños: TARGET_COMMITTEE_SIZE = 128, MAX_COMMITTEES_PER_SLOT = 64 y MAX_VALIDATORS_PER_COMMITTEE = 2048. [3] El número de comités por slot crece con el conjunto de validadores hasta ese máximo de 64. La propia especificación explica que 128 se eligió por seguridad: supera el tamaño mínimo recomendado de 111 para que un comité muestreado al azar sea representativo. [3]

¿Quién cae en qué comité? Un barajado determinista alimentado por una semilla que sale de RANDAO. [4] En cada bloque, el proponente revela una firma BLS sobre el número de epoch y el protocolo mezcla su hash con XOR en el valor acumulado del estado. [3] Las asignaciones de comité se conocen con al menos una epoch de antelación, para que el validador se suscriba a tiempo a la subred correcta. [6]

El proponente también sale de esa semilla, pero la elección se pondera por saldo efectivo: más ETH efectivo, más probabilidad de proponer. [3] Desde Fulu, EIP-7917 guarda en el estado la lista de proponentes de las próximas epochs, de modo que el calendario de propuestas deja de cambiar por sorpresa. [7]

El validador como máquina de estados

Cada validador es una fila en el estado de la Beacon Chain. El contenedor Validator guarda su clave pública BLS, sus credenciales de retiro, su saldo efectivo, si fue penalizado por slashing y cuatro epochs: elegibilidad, activación, salida y retiro. [3] Con esos cuatro números se lee toda su vida.

Para activarse hace falta un saldo mínimo de 32 ETH, MIN_ACTIVATION_BALANCE. Desde Electra, un validador con credenciales de capitalización puede llegar a un saldo efectivo de 2048 ETH, MAX_EFFECTIVE_BALANCE_ELECTRA. [8] La entrada pasa por una cola que limita cuántos validadores nuevos se suman por unidad de tiempo. [4]

La salida es simétrica. Si el saldo efectivo cae hasta EJECTION_BALANCE, 16 ETH en mainnet, el protocolo expulsa al validador. [5] En phase0, withdrawable_epoch se fija en la epoch de salida más MIN_VALIDATOR_WITHDRAWABILITY_DELAY = 256 epochs, unas 27 horas. [3] Esa espera deja tiempo para detectar y castigar una falta antes de que el dinero se vaya; los retiros reales llegaron con Shapella.

Una prueba rápida de comprensión: si un validador aparece con slashed = true y una exit_epoch todavía futura, ¿puede proponer bloques? No. Sigue contando como activo hasta su epoch de salida, pero el procesamiento de la cabecera de bloque rechaza cualquier bloque cuyo proponente esté marcado como penalizado. [3]