Propuesta de bloque
Última actualización de la página: 24 de diciembre de 2025
Los bloques son las unidades fundamentales de la cadena de bloques. Los bloques son unidades discretas de información que se pasan entre nodos, se acuerdan y se añaden a la base de datos de cada nodo. Esta página explica cómo se producen.
Requisitos previos
La propuesta de bloque es parte del protocolo de prueba de participación. Para entender mejor esta página, le recomendamos que lea sobre la prueba de participación y la arquitectura de bloques.
¿Quién produce los bloques?
Las cuentas de validadores proponen bloques. Las cuentas de validación slas administran operadores de nodos que ejecutan software de validación como parte de sus clientes de ejecución y consenso y han depositado al menos 32 ETH en el contrato de depósito. No obstante, cada validador solo es responsable ocasionalmente de proponer un bloque. Ethereum mide el tiempo en ranuras y épocas. Cada ranura es de doce segundos, y 32 ranuras (6,4 minutos) hacen una época. Cada ranura es una oportunidad de añadir un nuevo bloque en Ethereum.
Selección aleatoria
Un solo validador se elige pseudoaleatoriamente para proponer un bloque en cada ranura. No hay tal cosa como la verdadera aleatoriedad en una cadena de bloques, porque si cada nodo generara números genuinamente aleatorios, no podrían llegar a un consenso. En su lugar, el objetivo es hacer que el proceso de selección del validador sea impredecible. La aleatoriedad se logra en Ethereum utilizando un algoritmo llamado RANDAO que mezcla un hash del proponente de bloques con una semilla que se actualiza en cada bloque. Este valor sirve para seleccionar un validador específico del conjunto de validadores totales. La selección del validador se fija con dos épocas de antelación como una forma de protegerse contra ciertos tipos de manipulación de semillas.
Aunque los validadores se añaden a RANDAO en cada ranura, el valor global de RANDAO solo se actualiza una vez por época. Para calcular el índice del siguiente proponente de bloques, el valor de RANDAO se mezcla con el número de ranura para dar un valor único en cada ranura. La probabilidad de que se seleccione un validador individual no es simplemente 1/N (donde N = total de validadores activos). En su lugar, se pondera por el saldo efectivo de ETH de cada validador. El saldo efectivo máximo es de 32 ETH (esto significa que balance < 32 ETH da como resultado una ponderación menor que balance == 32 ETH, pero balance > 32 ETH no da como resultado una ponderación mayor que balance == 32 ETH).
Solo se selecciona un proponente de bloque en cada ranura. En condiciones normales, un productor de un solo bloque crea y lanza un solo bloque en su ranura dedicada. Crear dos bloques para la misma ranura es una ofensa que se puede recortar, a menudo conocida como «equivocación».
¿Cómo se crea el bloque?
Se espera que el proponente de bloques transmita un bloque de baliza firmado que se construye sobre la cabeza más reciente de la cadena, de acuerdo con la vista de su propio algoritmo de elección de bifurcación de ejecución local. El algoritmo de elección de bifurcación aplica cualquier certificación en cola que quede de la ranura anterior, luego encuentra el bloque con el mayor peso acumulado de certificaciones en su historia. Ese bloque es el padre del nuevo bloque creado por el proponente.
El proponente de bloques crea un bloque recopilando datos de su propia base de datos local y vista de la cadena. El contenido del bloque se muestra en el siguiente fragmento:
1class BeaconBlockBody(Container):2 randao_reveal: BLSSignature3 eth1_data: Eth1Data4 graffiti: Bytes325 proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]6 attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]7 attestations: List[Attestation, MAX_ATTESTATIONS]8 deposits: List[Deposit, MAX_DEPOSITS]9 voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]10 sync_aggregate: SyncAggregate11 execution_payload: ExecutionPayloadMostrar todoEl campo randao_reveal toma un valor aleatorio verificable que el proponente del bloque crea al firmar el número de época actual. eth1_data es un voto para la vista del proponente del bloque del contrato de depósito, incluyendo la raíz del trie de Merkle de depósito y el número total de depósitos que permiten verificar nuevos depósitos. graffiti es un campo opcional que puede usarse para agregar un mensaje al bloque. proposer_slashings y attester_slashings son campos que contienen pruebas de que ciertos validadores han cometido ofensas sancionables según la vista de la cadena que tiene el proponente. deposits es una lista de nuevos depósitos de validadores de los que el proponente del bloque tiene conocimiento, y voluntary_exits es una lista de validadores que desean salir, de los que el proponente del bloque ha oído hablar en la red de rumores de la capa de consenso. El sync_aggregate es un vector que muestra qué validadores fueron asignados previamente a un comité de sincronización (un subconjunto de validadores que sirven datos de clientes ligeros) y participaron en la firma de datos.
El execution_payload permite que la información sobre las transacciones se transmita entre los clientes de ejecución y de consenso. El execution_payload es un bloque de datos de ejecución que se anida dentro de un bloque de baliza. Los campos dentro del execution_payload reflejan la estructura del bloque descrita en el libro amarillo de Ethereum, excepto que no hay ommers y existe prev_randao en lugar de difficulty. El cliente de ejecución tiene acceso a un grupo local de transacciones de las que ha oído hablar en su propia red de intercambio de información. Estas transacciones se ejecutan localmente para generar un estado trie actualizado conocido como «posestado». Las transacciones se incluyen en el execution_payload como una lista llamada transactions y el postestado se proporciona en el campo state-root.
Todos estos datos se recopilan en un bloque de baliza, se firman y se transmiten a los pares del proponente del bloque, que los propagan a sus pares, etc.
Lea más sobre la anatomía de los bloques.
¿Qué pasa con el bloque?
El bloque se añade a la base de datos local del proponente del bloque y se transmite a los pares a través de la red de intercambio de información de la capa de consenso. Cuando un validador recibe el bloque, verifica los datos dentro de él, incluida la verificación de que el bloque tiene el padre correcto, corresponde a la ranura indicada, el índice del proponente es el esperado, la revelación de RANDAO es válida y que el proponente no está recortado. El execution_payload se desempaqueta, y el cliente de ejecución del validador vuelve a ejecutar las transacciones de la lista para comprobar el cambio de estado propuesto. Suponiendo que el bloque pase todas estas comprobaciones, cada validador añade el bloque a su propia cadena predilecta. El proceso comienza de nuevo en la siguiente ranura.
Recompensas de bloque
El proponente de bloques recibe el pago por su trabajo. Hay una base_reward calculada como una función del número de validadores activos y sus saldos efectivos. El proponente del bloque recibe entonces una fracción de la base_reward por cada atestación válida incluida en el bloque; cuantos más validadores atestigüen el bloque, mayor será la recompensa del proponente del bloque. También hay una recompensa por reportar validadores que deberían ser sancionados, igual a 1/512 * effective balance por cada validador sancionado.
Más sobre recompensas y penalizaciones