Sprints, spans y conjuntos de validadores de Polygon Bor a través de RPC

Cómo Polygon PoS Bor organiza la producción de bloques

Polygon PoS utiliza Bor, un fork de go-ethereum, como su capa de producción de bloques. Bor combina un conjunto de validadores de Proof-of-Stake con un mecanismo de checkpointing que ancla la finalidad a Ethereum. El conjunto activo de validadores se selecciona mediante staking en Ethereum, y los productores de bloques se extraen de este conjunto. El tiempo de bloque es del orden de un par de segundos, aunque el valor exacto es un parámetro documentado que puedes verificar on-chain.

Para hacer que la producción de bloques sea predecible y eficiente, Bor organiza a los productores en spans y sprints. Un span es un número fijo de sprints consecutivos durante los cuales un subconjunto seleccionado de validadores es responsable de producir bloques. Dentro de un span, los productores rotan: un sprint es una serie de bloques consecutivos producidos por un único validador, tras lo cual el siguiente validador en el span toma el relevo. Esta estructura significa que 'quién produce el siguiente bloque' es una función del estado actual del span, no un round-robin global.

El conjunto de validadores cambia solo en los límites de span, normalmente activado por un evento de state-sync o checkpoint. Este diseño reduce la frecuencia de los cambios de conjunto y hace que la selección de productores sea determinista dentro de un span. Para una visión más profunda de cómo encaja esto en la red Polygon en general, consulta la página de la red Polygon.

• Span: un número fijo de sprints durante los cuales un subconjunto seleccionado de validadores produce bloques.
• Sprint: una serie de bloques consecutivos producidos por un único validador.
• Los cambios en el conjunto de validadores ocurren en los límites de span, a menudo mediante eventos de state-sync o checkpoint.
• La selección de productores se deriva del conjunto de validadores y del span/seed, lo que la hace computable a partir del conjunto.

Leer el estado del productor con métodos RPC específicos de Bor

Bor expone varios métodos JSON-RPC no estándar bajo el espacio de nombres bor_. Estos métodos no forman parte de la especificación estándar de JSON-RPC de Ethereum, por lo que un endpoint de Ethereum simple o una cadena que no sea Bor devolverán un error de método no encontrado. Los métodos clave para leer el estado del productor son:

bor_getSnapshot(blockNumber) devuelve la instantánea actual de span/sprint, incluido el conjunto de validadores, los números de span y sprint actuales, y el productor. bor_getSigners(blockNumber) devuelve la lista de firmantes para un bloque dado. bor_getCurrentValidators() devuelve el conjunto actual de validadores. bor_getCurrentProposer() devuelve la dirección del validador que producirá el siguiente bloque.

También puedes usar el estándar eth_getBlockByNumber para obtener metadatos del bloque, incluidos campos específicos de Bor como el firmante (a menudo disponible como miner o mediante bor_getAuthor). Para confirmar que tu nodo está en el fork correcto, verifica eth_syncing y compara las marcas de tiempo de los bloques con una fuente confiable.

• bor_getSnapshot: devuelve la instantánea de span/sprint con el conjunto de validadores y el productor.
• bor_getSigners: devuelve los firmantes de un bloque específico.
• bor_getCurrentValidators: devuelve el conjunto actual de validadores.
• bor_getCurrentProposer: devuelve el siguiente productor de bloques.
• eth_getBlockByNumber: método estándar para metadatos de bloque, incluidos campos específicos de Bor.

Usos prácticos: atribución de bloques, validadores atascados y riesgo de reorganización

Conocer el productor actual y el conjunto de validadores es esencial para la atribución de bloques. Si tu aplicación necesita acreditar un bloque a un validador específico, puedes usar bor_getSigners o el campo miner del bloque. Esto es útil para análisis, cálculos de recompensas y monitoreo del rendimiento de los validadores.

Detectar un validador atascado es otro caso de uso común. Si un validador no produce bloques durante su sprint, puedes ver bloques vacíos o un vacío en la producción. Informes upstream, como un issue de GitHub titulado 'Bor sync wedges on empty block after producer restart', destacan que un reinicio del productor puede provocar un bloque vacío que detiene la sincronización. Monitorear bor_getCurrentProposer y las marcas de tiempo de los bloques puede ayudarte a detectar tales anomalías a tiempo.

Finalmente, comprender los límites de span ayuda a estimar la profundidad de reorganización frente a la finalización. Debido a que el conjunto de validadores cambia solo en los límites de span, las reorganizaciones que cruzan un límite de span son más disruptivas. Para más información sobre conceptos de finalidad, consulta Finalidad de OP-Stack y etiquetas de bloques safe/finalized.

• Atribuye bloques a productores usando bor_getSigners o el campo miner del bloque.
• Detecta validadores atascados monitoreando los cambios de productor y los vacíos en la producción de bloques.
• Estima el riesgo de reorganización en los límites de span donde cambian los conjuntos de validadores.

Código ejecutable: obtener la instantánea y verificar firmantes

El siguiente script de Node.js se conecta a un endpoint RPC de Bor, obtiene la instantánea en un bloque dado, imprime los validadores actuales, el sprint, el span y el productor actual, y luego verifica con bor_getSigners para ese bloque. Reemplaza la URL de RPC con tu propio endpoint.

Este código utiliza la biblioteca ethers para llamadas JSON-RPC. Asegúrate de tenerla instalada (npm install ethers). El script es autocontenido y se puede ejecutar directamente con Node.js.

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

const RPC_URL = 'https://your-bor-rpc-endpoint';
const BLOCK_NUMBER = 'latest'; // or a specific block number

async function main() {
  const provider = new JsonRpcProvider(RPC_URL);

  // Fetch snapshot
  const snapshot = await provider.send('bor_getSnapshot', [BLOCK_NUMBER]);
  console.log('Snapshot:');
  console.log('  Span:', snapshot.span ? snapshot.span.id : 'N/A');
  console.log('  Sprint:', snapshot.sprint);
  console.log('  Current Validators:', snapshot.validators);
  console.log('  Current Producer:', snapshot.producer);

  // Fetch signers for the same block
  const signers = await provider.send('bor_getSigners', [BLOCK_NUMBER]);
  console.log('Signers for block', BLOCK_NUMBER, ':', signers);

  // Fetch current proposer
  const proposer = await provider.send('bor_getCurrentProposer', []);
  console.log('Current Proposer:', proposer);

  // Fetch current validators
  const validators = await provider.send('bor_getCurrentValidators', []);
  console.log('Current Validators (bor_getCurrentValidators):', validators);
}

main().catch(console.error);

Tabla de resultados: medir el estado del productor en tu endpoint

Utiliza la siguiente tabla para registrar los resultados de tu propio endpoint RPC. Ejecuta el código anterior y completa los valores. Esto te ayuda a verificar que tu endpoint devuelve datos específicos de Bor consistentes y que el productor coincide con el firmante del bloque.

Si algún campo falta o devuelve un error, consulta la sección de resolución de problemas a continuación. Ten en cuenta que bor_getSnapshot puede devolver null para bloques podados o muy antiguos; se requiere un nodo de archivo para instantáneas históricas. Para más información sobre nodos de archivo, consulta Nodos de archivo de Polygon y RPC histórico.

• Número de bloque: el bloque que consultaste.
• ID de span: de snapshot.span.id.
• Número de sprint: de snapshot.sprint.
• Validadores actuales: lista de snapshot.validators o bor_getCurrentValidators.
• Productor actual: de snapshot.producer o bor_getCurrentProposer.
• Firmantes: de bor_getSigners para el mismo bloque.
• ¿Coincide? ¿Aparece el productor en la lista de firmantes?

Fallos comunes y lista de verificación para la resolución de problemas

Al leer el estado del productor de Bor a través de RPC, puedes encontrar varios problemas comunes. Aquí tienes una lista de verificación para diagnosticarlos:

Método no encontrado: Si obtienes un error de 'método no encontrado' para los métodos bor_, es probable que tu endpoint no sea un nodo Bor o sea un endpoint de Ethereum simple. Asegúrate de estar conectado a un endpoint RPC de Polygon PoS. Para obtener una lista de proveedores, consulta Proveedores y nodos RPC de Polygon (RPC Assistant).

Instantánea nula para bloques antiguos: bor_getSnapshot puede devolver null para bloques que han sido podados. Usa un nodo de archivo para consultas históricas. Consulta Nodos de archivo de Polygon y RPC histórico.

Casos límite en los límites de sprint/span: En el límite exacto entre sprints o spans, la instantánea puede reflejar el nuevo productor o el anterior según el número de bloque. Consulta siempre la instantánea para el bloque específico que te interesa y verifícala con bor_getSigners.

Interpretar erróneamente la instantánea como finalidad: La instantánea muestra el productor actual y el conjunto de validadores, pero no indica finalidad. La finalidad se logra mediante checkpoints en Ethereum. No trates la instantánea como una señal de finalidad.

Nodo retrasado respecto a la punta de la cadena: Si tu nodo no está sincronizado, la instantánea puede estar desactualizada. Verifica eth_syncing y compara las marcas de tiempo de los bloques. Consulta Detectar un nodo RPC retrasado respecto a la punta de la cadena.

• Verifica que el endpoint admita métodos específicos de Bor.
• Usa un nodo de archivo para instantáneas históricas.
• Consulta la instantánea para el número de bloque exacto.
• Verifica el productor con los firmantes.
• Monitorea el estado de sincronización del nodo.

Limitaciones y compensaciones del estado del productor de Bor a través de RPC

Si bien los métodos RPC de Bor proporcionan información valiosa sobre la producción de bloques, conllevan limitaciones. Primero, estos métodos no son estándar y pueden no ser compatibles con todos los proveedores de RPC. Incluso entre nodos Bor, la disponibilidad de bor_getSnapshot para bloques históricos depende de la configuración de poda del nodo. Segundo, los datos de la instantánea reflejan el estado en un bloque dado, pero no garantizan que el productor vaya a producir con éxito el siguiente bloque; las condiciones de la red o el tiempo de inactividad del validador pueden causar desviaciones.

Tercero, confiar únicamente en bor_getCurrentProposer para el monitoreo en tiempo real puede ser engañoso si tu nodo no está completamente sincronizado. Verifica siempre la salud del nodo y el estado de sincronización. Para obtener mejores prácticas de monitoreo, consulta Monitoreo de endpoints RPC y salud del nodo.

Finalmente, el conjunto de validadores y los parámetros de span están sujetos a la gobernanza y a las actualizaciones del protocolo. Verifica siempre los valores actuales on-chain en lugar de asumir números fijos. Para obtener detalles autorizados, consulta la documentación oficial de Polygon sobre la arquitectura de Bor y el paquete de consenso de Bor.

• Los métodos no estándar pueden no estar disponibles en todos los endpoints.
• Las instantáneas históricas requieren nodos de archivo.
• La instantánea no garantiza la producción futura de bloques.
• El estado de sincronización del nodo afecta la frescura de los datos.
• Los parámetros del protocolo pueden cambiar mediante gobernanza.

Próximos pasos: integrar el estado del productor en tu aplicación

Ahora que comprendes cómo leer el estado del productor de Bor, puedes integrarlo en tu aplicación. Para exploradores de bloques o paneles de análisis, usa bor_getSigners para atribuir bloques a validadores. Para herramientas de monitoreo, sondea bor_getCurrentProposer y bor_getCurrentValidators para detectar cambios en el conjunto y tiempos de inactividad de validadores. Para billeteras o exchanges, usa los límites de span para estimar el riesgo de reorganización y ajustar los requisitos de confirmación.

Para comenzar con un endpoint RPC confiable, explora la página de la red Polygon de OnFinality y considera un plan de servicio API que se ajuste a tus necesidades. Para obtener detalles sobre precios, consulta Precios de RPC. Para más guías, visita el centro de aprendizaje de OnFinality.

Recuerda probar tu integración contra múltiples endpoints y verificar los resultados con el método de la tabla de resultados descrito anteriormente. Esto asegura que tu aplicación maneje casos límite y diferencias entre proveedores con elegancia.

• Usa bor_getSigners para la atribución de bloques.
• Sondea bor_getCurrentProposer para monitoreo en tiempo real.
• Ajusta la profundidad de confirmación según los límites de span.
• Elige un proveedor RPC confiable con soporte para Bor.