Recompensas y penalizaciones de la prueba de participación

Ethereum está protegido gracias al uso de su criptomoneda nativa, el ether (ETH). Los operadores de nodos que deseen participar en la validación de bloques y en la identificación de la cabeza de la cadena, depositan ether en el contrato de depósito en Ethereum. Luego se les paga en ether para ejecutar un software de validación que compruebe la validez de los nuevos bloques recibidos a través de la red entre pares y aplicar el algoritmo de elección de bifurcación para identificar la cabeza de la cadena.

Hay dos funciones principales para un validador: 1) comprobar los nuevos bloques y «certificar» si son válidos, 2) proponer nuevos bloques cuando se seleccionan al azar del grupo total de validadores. Si el validador no realiza ninguna de estas tareas cuando se le pide, pierde un pago de ether. A veces, los validadores también tienen la tarea de agregar firmas y participar en comités de sincronización.

Hay algunas acciones que son muy difíciles de acometer accidentalmente y indican alguna intención maliciosa, como proponer múltiples bloques para la misma ranura o certificar múltiples bloques para la misma ranura. Se trata de comportamientos «recortables» que hacen que el validador tenga cierta cantidad de ether (hasta 1 ETH) quemado antes de que el validador se elimine de la red, lo que lleva 36 días. El ether del validador recortado se drena lentamente a lo largo del período de salida, pero en el 18.º día recibe una «penalización de correlación» que es mayor cuantos más validadores se recortan aproximadamente al mismo tiempo. Por lo tanto, la estructura de incentivos del mecanismo de consenso paga por la honestidad y castiga las malas conductas.

Todas las recompensas y penalizaciones se aplican una vez por época.

Siga leyendo si desea ahondar más al respecto...

Recompensas y penalizaciones

Recompensas

Los validadores reciben recompensas cuando hacen votos que son consistentes con la mayoría de otros validadores, cuando proponen bloques y cuando participan en comités de sincronización. El valor de las recompensas en cada época se calcula a partir de una base_reward. Esta es la unidad de base a partir de la cual se calculan otras recompensas. La base_reward representa la recompensa media que recibe un validador en condiciones óptimas por época. Esto se calcula a partir del saldo efectivo del validador y el número total de validadores activos de la siguiente manera:

1base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))

donde base_reward_factor es 64, base_rewards_per_epoch es 4 y sum(active balance) es el ether total en staking entre todos los validadores activos.

Esto significa que la recompensa de base es proporcional al saldo efectivo del validador e inversamente proporcional al número de validadores en la red. Cuantos más validadores, mayor será la emisión total (como sqrt(N)), pero menor será la base_reward por validador (como 1/sqrt(N)). Estos factores influyen en la APR de un nodo de participación. Lea la justificación de esto en las notas de Vitalikopens in a new tab.

La recompensa total se calcula entonces como la suma de cinco componentes, cada uno de los cuales tiene una ponderación que determina cuánto suma cada componente a la recompensa total. Los componentes son:

11. source vote: el validador ha realizado un voto a tiempo para el punto de control de origen correcto
22. target vote: el validador ha realizado un voto a tiempo para el punto de control de destino correcto
33. head vote: el validador ha realizado un voto a tiempo para el bloque de cabeza correcto
44. sync committee reward: el validador ha participado en un comité de sincronización
55. proposer reward: el validador ha propuesto un bloque en la ranura correcta

Las ponderaciones para cada componente son las siguientes:

1TIMELY_SOURCE_WEIGHT	uint64(14)
2TIMELY_TARGET_WEIGHT	uint64(26)
3TIMELY_HEAD_WEIGHT	uint64(14)
4SYNC_REWARD_WEIGHT	uint64(2)
5PROPOSER_WEIGHT	uint64(8)

Estos pesos suman 64. La recompensa se calcula como la suma de los pesos aplicables divididos entre 64. Un validador que haya realizado votos de origen, destino y cabeza a tiempo, haya propuesto un bloque y haya participado en un comité de sincronización podría recibir 64/64 * base_reward == base_reward. Sin embargo, un validador no suele ser un proponente de bloques, por lo que su recompensa máxima es 64-8 /64 * base_reward == 7/8 * base_reward. Los validadores que no son proponentes de bloques ni están en un comité de sincronización pueden recibir 64-8-2 / 64 * base_reward == 6.75/8 * base_reward.

Se añade una recompensa adicional para incentivar las certificaciones rápidas. Esta es la inclusion_delay_reward. Tiene un valor igual a la base_reward multiplicada por 1/delay, donde delay es el número de ranuras que separan la propuesta de bloque y la atestación. Por ejemplo, si la atestación se envía dentro de una ranura de la propuesta de bloque, el atestador recibe base_reward * 1/1 == base_reward. Si la atestación llega en la siguiente ranura, el atestador recibe base_reward * 1/2 y así sucesivamente.

Los proponentes de bloques reciben 8 / 64 * base_reward por cada atestación válida incluida en el bloque, por lo que el valor real de la recompensa escala con el número de validadores que atestan. Los proponentes de bloques también pueden aumentar su recompensa al incluir evidencia de mal comportamiento por parte de otros validadores en su bloque propuesto. Estas recompensas son los alicientes que fomentan la honestidad del validador. Un proponente de bloque que incluya un «slashing» será recompensado con slashed_validators_effective_balance / 512.

Penalizaciones

Hasta ahora hemos considerado validadores con un comportamiento ejemplar, pero ¿qué pasa con los validadores que no hacen votos portunamente de cabeza, fuente y destino, o se toman demasiado tiempo en hacerlos?

Las penalizaciones por no alcanzar el objetivo y los votos de la fuente son iguales a las recompensas que el certificador habría recibido si las hubiera presentado. Esto significa que en lugar de tener la recompensa añadida a su saldo, tienen un valor igual eliminado de su saldo. No hay penalización por omitir el voto de cabeza (es decir, los votos de cabeza solo se recompensan, nunca se penalizan). No hay ninguna penalización asociada con el inclusion_delay; la recompensa simplemente no se añadirá al saldo del validador. Tampoco hay penalización por fallar en proponer un bloque.

Lea más sobre recompensas y penalizaciones en las especificaciones de consensoopens in a new tab. Las recompensas y penalizaciones se ajustaron en la actualización Bellatrix. Vea a Danny Ryan y a Vitalik discutir esto en este vídeo de «Peep an EIP»opens in a new tab.

Slashing

Los recortes son una acción más grave que resulta en la eliminación forzada de un validador de la red y una pérdida asociada de su ether apostado. Hay tres formas en las que se puede recortar un validador, todas ellas equivalen a la propuesta deshonesta o la certificación de bloques:

Proponer y firmar dos bloques diferentes para el mismo espacio.
Certificar un bloque que «rodea» a otro (cambiando completamente la historia).
Por «doble votación» al certificar a dos candidatos para el mismo bloque.

Si se detectan estas acciones, el validador se recorta. Esto quiere decir que 0,0078125 ETH se queman inmediatamente para un validador de 32 ETH (escalado linealmente con el balance activo), seguido de un periodo de eliminación de 36 días. Durante este período de eliminación, la participación del validador se desvanece gradualmente. En el punto medio (18.º día) se aplica una penalización adicional cuya magnitud se prorratea con el ether total en participación de todos los validadores recortados en los 36 días anteriores al evento de recorte. Esto significa que cuando se recortan más validadores, la magnitud del recorte aumenta. El «slashing» máximo es el saldo efectivo completo de todos los validadores que han sufrido «slashing» (es decir, si hay muchos validadores que sufren «slashing», podrían perder toda su participación). Por otro lado, un solo evento de recorte aislado solo quema una pequeña parte de la participación del validador. Esta penalización de punto medio que se prorratea con el número de validadores recortados se llama «pena de correlación».

Fuga por inactividad

Si la capa de consenso ha pasado más de cuatro épocas sin finalizar, se activa un protocolo de emergencia llamado «pérdida por inactividad». El objetivo final de la pérdida por inactividad es crear las condiciones necesarias para que la cadena recupere la finalidad. Como se explicó anteriormente, la finalidad requiere una mayoría de 2/3 del ether en participación para acordar los puntos de control de origen y destino. Si los validadores que representan más de 1/3 del total de validadores se desconectan o no envían las certificaciones correctas, entonces no es posible que una supermayoría de 2/3 finalice los puntos de control. La pérdida por inactividad permite que la participación relativa a los validadores inactivos se desvanezca gradualmente hasta que controlen menos de 1/3 de la participación total, lo que permite que los validadores activos restantes finalicen la cadena. Por grande que sea el grupo de validadores inactivos, los validadores activos restantes eventualmente controlarán >2/3 de la participación. ¡La pérdida de participación es un fuerte incentivo para que los validadores inactivos se reactiven lo antes posible! Se encontró un caso de pérdida por inactividad en la red de pruebas de Medalla, cuando < 66 % de los validadores activos pudieron llegar a un consenso sobre la cabeza actual de la cadena de bloques. ¡La pérdida por inactividad se activó y finalmente se recuperó la finalidad!

El diseño de recompensa, penalización y recorte del mecanismo de consenso anima a los validadores individuales a comportarse correctamente. No obstante, de estas opciones de diseño surge un sistema que incentiva poderosamente la distribución equitativa de validadores entre múltiples clientes, y debería desincentivar con ahínco el dominio de un solo cliente.

Lecturas adicionales

Fuentes

https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/opens in a new tab