Lectura de elecciones y slashing de validadores de BNB Smart Chain vía RPC

Elecciones y slashing de validadores de BNB Smart Chain vía RPC

BNB Smart Chain (BSC) ejecuta un consenso híbrido llamado Parlia, un modelo de prueba de autoridad apostada en el que un conjunto acotado de validadores activos se turnan para producir bloques en orden rotatorio. El conjunto activo no es estático: se recalcula en un límite de época diario a partir del BNB apostado y cualquier estado de encarcelamiento o slashing. Para integradores, indexadores y herramientas de monitoreo, la pregunta práctica es cómo observar este comportamiento de elección y slashing a través de JSON-RPC sin ejecutar una pila completa de validador.

Esta guía cubre la representación on-chain de las elecciones de validadores y el slashing, los métodos RPC que las exponen y métodos reproducibles para medir el conjunto actual de productores y el número de validadores contra tu propio endpoint. Separa el comportamiento documentado del protocolo del comportamiento específico del proveedor y de los métodos de medición que puedes ejecutar tú mismo. Para detalles de acceso a nivel de red, consulta los endpoints RPC de BNB Chain (RPC Assistant) y el hub de aprendizaje de OnFinality.

• Parlia: los validadores activos producen bloques en orden rotatorio durante una época.
• Límite de época: el conjunto activo se recalcula diariamente a partir del stake y el jailing.
• Contratos del sistema: el Validator Contract / stake hub y el Slash Contract contienen el estado autoritativo.
• Lecturas RPC: eth_getBlockByNumber para productores, eth_call para el estado de los contratos.

Consenso Parlia y el límite de época diario

Parlia es un consenso de prueba de autoridad apostada que combina el staking con un conjunto de validadores con permiso. Según la documentación de BNB Chain: descripción general de validadores de BSC, los validadores se eligen según la cantidad de BNB apostado, y el conjunto activo de validadores se actualiza en los límites de época. Dentro de una época, los validadores se turnan para producir bloques en una secuencia rotatoria determinista, lo que significa que el productor de un bloque dado es predecible si conoces el orden actual de validadores.

La longitud de la época es una constante del protocolo, pero no es fija en todas las versiones y actualizaciones de la cadena. Debe leerse de la cadena en ejecución en lugar de codificarse de forma fija a partir de la documentación. Lo mismo se aplica a las direcciones de los contratos del sistema y los nombres de los getters: se documentan por versión y pueden cambiar con las actualizaciones. Trátalos como configuración en tiempo de ejecución, no como constantes en tu código.

• Longitud de época: documentada / varía según la versión y actualización de la cadena.
• Orden de validadores: rotatorio determinista dentro de una época.
• Entradas de la elección: BNB apostado y estado de jailing.
• Fuente autoritativa: contratos del sistema, no solo los miners de los bloques.

Contratos del sistema que contienen el estado de validadores y slashing

BSC almacena el estado de elección de validadores y slashing en contratos del sistema. El Validator Contract (a menudo denominado stake hub) contiene el conjunto de validadores, el poder de voto de cada validador y la información de delegación. El Slash Contract registra los eventos de slashing y jailing. Estos contratos no son contratos de usuario ordinarios; forman parte del protocolo y son actualizados por la capa de consenso en los límites de época.

Como son contratos, puedes leerlos con eth_call usando selectores de función codificados en ABI. Las direcciones exactas y los nombres de los getters son constantes del protocolo que varían según la versión y actualización de la cadena, por lo que debes leerlos de la cadena en ejecución o de la documentación actual de BNB Chain en lugar de codificar de forma fija los valores de este artículo. La documentación de BNB Chain: reglas de slashing de BSC describe las reglas de slashing y el papel del Slash Contract.

• Validator Contract / stake hub: conjunto de validadores, poder de voto, delegaciones.
• Slash Contract: registros de slashing y jailing.
• Método de lectura: eth_call con getters codificados en ABI.
• Direcciones y nombres de getters: documentados / varían según la versión y actualización de la cadena.

Lectura del productor de bloques actual con eth_getBlockByNumber

En BSC, el campo miner (también llamado coinbase) de un bloque identifica al validador que produjo ese bloque. Este es un comportamiento documentado del consenso Parlia: el beneficiario del bloque es el validador de esa altura. Puedes leerlo con eth_getBlockByNumber e inspeccionar el campo miner. Esto te da una vista puntual de quién está produciendo bloques.

Para reconstruir el orden de validadores dentro de una época, muestrea el campo miner a lo largo de un intervalo de bloques consecutivos y agrupa los productores consecutivos. Como los validadores se turnan en orden rotatorio, una muestra suficientemente larga revelará la secuencia repetitiva. Sin embargo, esto es solo una aproximación del estado autoritativo del contrato: un validador puede ser omitido, encarcelado o reemplazado en un límite de época, y el campo miner por sí solo no te dice el conjunto completo de elegidos ni el poder de voto.

const https = require('https');

const RPC_URL = process.env.BSC_RPC_URL || 'https://your-bsc-rpc-endpoint';

function rpcCall(method, params) {
  return new Promise((resolve, reject) => {
    const body = JSON.stringify({ jsonrpc: '2.0', id: 1, method, params });
    const req = https.request(RPC_URL, { method: 'POST', headers: { 'Content-Type': 'application/json' } }, (res) => {
      let data = '';
      res.on('data', (chunk) => (data += chunk));
      res.on('end', () => {
        try {
          const json = JSON.parse(data);
          if (json.error) reject(new Error(json.error.message));
          else resolve(json.result);
        } catch (e) { reject(e); }
      });
    });
    req.on('error', reject);
    req.write(body);
    req.end();
  });
}

async function sampleProducers(startBlock, count) {
  const producers = [];
  for (let i = 0; i < count; i++) {
    const block = await rpcCall('eth_getBlockByNumber', ['0x' + (startBlock + i).toString(16), false]);
    if (block && block.miner) producers.push(block.miner.toLowerCase());
  }
  const tally = {};
  for (const p of producers) tally[p] = (tally[p] || 0) + 1;
  return { producers, tally };
}

(async () => {
  const latest = await rpcCall('eth_blockNumber', []);
  const start = parseInt(latest, 16) - 100;
  const { producers, tally } = await sampleProducers(start, 100);
  console.log('Distinct producers:', Object.keys(tally).length);
  console.log('Tally:', tally);
})();

Lectura del conjunto de validadores y el poder de voto vía eth_call

El conjunto autoritativo de validadores y el poder de voto de cada validador se almacenan en el Validator Contract. Puedes leerlos con eth_call usando las funciones getter del contrato. Un getter común es getValidators, que devuelve el conjunto actual de validadores, pero el nombre y la firma exactos son constantes del protocolo que varían según la versión y actualización de la cadena. Debes verificar el ABI actual de la cadena en ejecución o de la documentación oficial.

El poder de voto se deriva del auto-stake del validador y las delegaciones. El contrato expone esta información a través de getters que devuelven montos de stake y totales de delegación. Como eth_call se ejecuta contra el estado de un bloque específico, leer conjuntos históricos de validadores requiere un nodo con acceso de archivo. Para más información sobre los requisitos de archivo, consulta RPC histórico y archivo de BNB Smart Chain.

const { ethers } = require('ethers');

const RPC_URL = process.env.BSC_RPC_URL || 'https://your-bsc-rpc-endpoint';
const provider = new ethers.JsonRpcProvider(RPC_URL);

// Replace with the current Validator Contract address and ABI getter.
// These are protocol constants: documented / varies by chain version and upgrade.
const VALIDATOR_CONTRACT = process.env.VALIDATOR_CONTRACT || '0x0000000000000000000000000000000000001000';
const ABI = [
  'function getValidators() view returns (address[])'
];

async function readValidatorCount(blockTag) {
  const contract = new ethers.Contract(VALIDATOR_CONTRACT, ABI, provider);
  const validators = await contract.getValidators({ blockTag });
  return validators.length;
}

(async () => {
  const count = await readValidatorCount('latest');
  console.log('Validator count from contract:', count);
})();

Cálculo del límite de época y observación de cambios de productores

La longitud de la época determina con qué frecuencia se recalcula el conjunto de validadores. Puedes leer la longitud de la época de la cadena en ejecución, a menudo mediante un getter de contrato del sistema o una llamada de configuración. Una vez que conoces la longitud de la época, puedes calcular el siguiente límite de época como la siguiente altura de bloque que sea múltiplo de la longitud de la época. En ese límite, el conjunto activo de validadores puede cambiar, y puedes observar el cambio comparando el conjunto de productores antes y después.

Un método práctico es muestrear el campo miner en un rango que abarque un límite de época y buscar un cambio en el conjunto de productores distintos o en el orden rotatorio. Históricamente, un primer bloque de época bajo o corto ha sido una señal de transición del conjunto de validadores, pero esto no es un indicador garantizado y debe verificarse contra el estado del contrato. La guía Confiabilidad y tiempos de espera de RPC de BNB Smart Chain cubre cómo manejar errores de RPC durante tales observaciones.

async function getEpochLength() {
  // Replace with the current epoch length getter or configuration call.
  // This is a protocol constant: documented / varies by chain version and upgrade.
  const epochLengthHex = await rpcCall('eth_call', [
    { to: process.env.EPOCH_CONTRACT || '0x0000000000000000000000000000000000001000', data: '0x' },
    'latest'
  ]);
  return parseInt(epochLengthHex, 16);
}

async function findNextEpochBoundary(currentBlock) {
  const epochLength = await getEpochLength();
  const nextBoundary = Math.ceil((currentBlock + 1) / epochLength) * epochLength;
  return { epochLength, nextBoundary };
}

(async () => {
  const latest = await rpcCall('eth_blockNumber', []);
  const current = parseInt(latest, 16);
  const { epochLength, nextBoundary } = await findNextEpochBoundary(current);
  console.log('Epoch length:', epochLength);
  console.log('Next epoch boundary:', nextBoundary);
})();

Señales de slashing y jailing en las lecturas RPC

El slashing y el jailing se registran en el Slash Contract. Cuando un validador es penalizado o encarcelado, su estado cambia, y el efecto sobre la producción de bloques ocurre en el siguiente límite de época. Para un integrador, la señal práctica es un cambio en quién produce bloques: un validador encarcelado no aparecerá como miner en las épocas posteriores hasta que sea liberado. El Slash Contract en sí puede leerse vía eth_call para inspeccionar los registros de slashing, pero los nombres exactos de los getters y las firmas de eventos son constantes del protocolo que varían según la versión y actualización de la cadena.

Es importante distinguir entre el comportamiento documentado del protocolo y el comportamiento específico del proveedor. El hecho de que el slashing se registre en el Slash Contract y surta efecto en los límites de época está documentado en la documentación de BNB Chain: reglas de slashing de BSC. La rapidez con la que tu proveedor de RPC refleja estos cambios depende de la sincronización e indexación del nodo del proveedor. Verifica siempre contra el estado del contrato en el bloque correspondiente.

• Slashing y jailing: registrados en el Slash Contract.
• Momento del efecto: los cambios de estado surten efecto en los límites de época.
• Señal para el integrador: cambio en los productores de bloques entre épocas.
• Comportamiento del proveedor: documentado / varía según el proveedor.

Método de medición reproducible y tabla de resultados

Para medir el comportamiento de elección de validadores y slashing contra tu propio endpoint, ejecuta los scripts de muestreo y lectura de contratos anteriores y registra los resultados en una tabla. Este método es reproducible: usa el mismo rango de bloques y el mismo endpoint RPC, y completa los valores que observes. No te bases en números de referencia de este artículo; mide contra tu propia infraestructura.

La tabla a continuación es una plantilla. Complétala con tus propias observaciones. El rango de bloques debe abarcar al menos un límite de época si quieres observar un cambio de productor. El número de validadores del contrato es la cifra autoritativa; los productores distintos vistos a partir de los miners de bloques son una aproximación.

• Rango de bloques: bloque inicial y bloque final que muestreaste.
• Productores distintos vistos: número de direcciones miner únicas en la muestra.
• Número de validadores del contrato: resultado de la llamada a getValidators.
• Longitud de época: valor leído de la cadena en ejecución.
• Cambio de productor en el límite: sí/no, y la altura de bloque donde ocurrió.

Limitaciones, compensaciones y constantes del protocolo

Las direcciones exactas de los contratos del sistema, los nombres de los getters y la longitud de la época son constantes del protocolo que se documentan por versión y actualización de la cadena. Deben leerse de la cadena en ejecución en lugar de codificarse de forma fija a partir de este artículo. Si codificas de forma fija una dirección o un nombre de getter, tu integración puede romperse tras una actualización de la red. Obtén siempre los valores actuales o hazlos configurables.

Leer contratos del sistema con eth_call depende de un nodo cuyo estado esté en el bloque consultado. Para lecturas históricas, necesitas acceso de archivo. Reconstruir el conjunto completo de validadores solo a partir de los miners de bloques es solo una aproximación del estado autoritativo del contrato: no te da el poder de voto, los detalles de delegación ni el conjunto completo de elegidos si algunos validadores no produjeron bloques en tu ventana de muestreo. Para consideraciones de latencia y confiabilidad al consultar estos endpoints, consulta Latencia de RPC de BNB Smart Chain y Rangos de trace y trace_block de paridad en BSC.

• Direcciones de contratos del sistema y nombres de getters: documentados / varían según la versión y actualización de la cadena.
• Longitud de época: leer de la cadena en ejecución, no codificar de forma fija.
• eth_call histórico: requiere acceso de archivo.
• Muestreo de miners: aproximación, no conjunto autoritativo de validadores.

Solución de problemas comunes de lectura RPC

Al leer el estado de los validadores vía RPC, puedes encontrar errores como nodos de trie faltantes, execution reverted o tiempos de espera. Los errores de nodo de trie faltante suelen indicar que tu nodo no tiene el estado para el bloque consultado, lo cual es común al leer datos históricos sin acceso de archivo. Execution reverted puede significar que el nombre del getter o el ABI son incorrectos para la versión actual de la cadena. Los tiempos de espera pueden indicar límites de tasa del proveedor o problemas de red.

Para solucionar problemas, primero verifica que tu endpoint RPC admita el método eth_call y que la etiqueta de bloque que usas esté disponible. Si necesitas estado histórico, usa un endpoint de archivo. Si obtienes execution reverted, verifica la dirección actual del contrato y el ABI en la documentación oficial o en la cadena en ejecución. Para límites específicos del proveedor, consulta la documentación de tu proveedor. Las páginas de servicio de API y precios de RPC de OnFinality describen las opciones de endpoints, y la página de endpoints RPC de BNB Chain (RPC Assistant) enumera los endpoints disponibles.

• Nodo de trie faltante: el nodo carece de estado para el bloque consultado; usa archivo.
• Execution reverted: verifica la dirección del contrato y el ABI para la versión actual.
• Tiempo de espera: revisa los límites de tasa del proveedor y las condiciones de red.
• Método no encontrado: asegúrate de que el endpoint admita eth_call y eth_getBlockByNumber.

Próximos pasos para integradores y herramientas de monitoreo

Para construir una herramienta robusta de monitoreo de validadores, combina el muestreo de miners de bloques con lecturas periódicas de contratos. Usa el muestreo de miners para detectar cambios de productor en tiempo real, y usa eth_call contra el Validator Contract para obtener el conjunto autoritativo de validadores y el poder de voto. Calcula los límites de época a partir de la longitud de la época y programa lecturas de contratos alrededor de esos límites para captar los cambios de elección.

Para sistemas en producción, considera usar un proveedor de RPC confiable con soporte de archivo para lecturas históricas. OnFinality proporciona endpoints RPC de BNB Chain y servicios relacionados. También puedes revisar el hub de aprendizaje de OnFinality para más guías sobre confiabilidad, latencia y métodos de trace de RPC de BSC. Mide siempre contra tu propio endpoint y registra los resultados en una tabla reproducible.

• Combina el muestreo de miners con lecturas de contratos para el estado autoritativo.
• Programa lecturas alrededor de los límites de época para captar las elecciones.
• Usa endpoints de archivo para consultas históricas del conjunto de validadores.
• Mide y registra tus propios resultados; no te bases en benchmarks de terceros.