chore: import translations for es

Author: actions-user

public/content/translations/es/developers/docs/accounts/accounts.svg.xlsx

@@ -118,11 +118,11 @@ En el siguiente vídeo Austin le guiará por las funciones hash y los pares de c
 
 <YouTube id="9LtBDy67Tho" />
 
-## Para seguir leyendo {#further-reading}
+## Más información {#further-reading}
 
 - [Claves para entender las cuentas de Ethereum](https://info.etherscan.com/understanding-ethereum-accounts/)-etherscan
 
-_¿Conoce algún recurso comunitario que le haya sido de ayuda? Edite la página y añádalo._
+_¿Conoce algún recurso de la comunidad que le haya servido de ayuda? Edite esta página y añádalo._
 
 ## Temas relacionados {#related-topics}
 

public/content/translations/es/developers/docs/accounts/index.md

@@ -33,31 +33,31 @@ La prueba de participación (PoS) consiste en lo siguiente:
 - Otros validadores enterados de la existencia de este nuevo bloque vuelven a ejecutar las transacciones con el fin de mostrar que están de acuerdo con los cambios propuestos a la red en general. Tras asumir el bloque como válido, se añade a sus propias bases de datos.
 - Cuando se informa a un validador sobre dos bloques que entran en conflicto para una misma ranura, entonces este ha de hacer uso del algoritmo de elección de bifurcación para elegir el bloque respaldado por los ETH más apostados.
 
-[Más información sobre la prueba de participación](/developers/docs/consensus-mechanisms/pos)
+[Más sobre la prueba de participación](/developers/docs/consensus-mechanisms/pos)
 
 ## ¿Qué hay en un bloque? {#block-anatomy}
 
 Hay mucha información contenida en un bloque. En los niveles más altos, un bloque contiene las siguientes características:
 
 | Campo            | Descripción                                                         |
 |:---------------- |:------------------------------------------------------------------- |
-| `ranura`         | la ranura a la que pertenece el bloque                              |
+| `slot`           | la ranura a la que pertenece el bloque                              |
 | `proposer_index` | la ID del validador que propone el bloque                           |
 | `parent_root`    | el hash del bloque anterior                                         |
 | `state_root`     | el hash raíz del objeto de estado                                   |
-| `cuerpo`         | un objeto que contiene varios campos, como se define a continuación |
+| `body`           | un objeto que contiene varios campos, como se define a continuación |
 
 El `cuerpo` del bloque contiene una serie de características:
 
 | Campo                | Descripción                                                          |
 |:-------------------- |:-------------------------------------------------------------------- |
 | `randao_reveal`      | un valor utilizado para seleccionar el siguiente bloque propuesto    |
 | `eth1_data`          | información sobre el contrato de depósito                            |
-| `grafiti`            | datos arbitrarios usados para etiquetar bloques                      |
+| `graffiti`           | datos arbitrarios usados para etiquetar bloques                      |
 | `proposer_slashings` | lista de validadores por cortar                                      |
-| `attester_slashings` | lista de validadores a cortar                                        |
-| `certificaciones`    | lista de certificaciones a favor del bloque actual                   |
-| `depósitos`          | lista de nuevos depósitos en el contrato de depósito                 |
+| `attester_slashings` | lista de certificantes por recortar                                  |
+| `attestations`       | lista de certificaciones a favor del bloque actual                   |
+| `deposits`           | lista de nuevos depósitos en el contrato de depósito                 |
 | `voluntary_exits`    | lista de validadores que salen de la red                             |
 | `sync_aggregate`     | subconjunto de validadores utilizados para servir a clientes ligeros |
 | `execution_payload`  | transacciones pasadas desde el cliente de ejecución                  |
@@ -67,15 +67,15 @@ El campo `certificaciones` contiene una lista con todas las certificaciones del
 | Campo              | Descripción                                                         |
 |:------------------ |:------------------------------------------------------------------- |
 | `aggregation_bits` | una lista de los validadores que participaron en esta certificación |
-| `datos`            | una terminal con múltiples subcampos                                |
-| `firma`            | firma añadida de todos los validadores que certifican               |
+| `data`             | una terminal con múltiples subcampos                                |
+| `signature`        | firma añadida de todos los validadores que certifican               |
 
 El campo `datos` en la `certificación` contiene lo siguiente:
 
 | Campo               | Descripción                                                |
 |:------------------- |:---------------------------------------------------------- |
-| `ranura`            | el ranura a la que se refiere la certificación             |
-| `índice`            | índices para certificar validadores                        |
+| `slot`              | el ranura a la que se refiere la certificación             |
+| `index`             | índices para certificar validadores                        |
 | `beacon_block_root` | el hash raíz del bloque de baliza que contiene este objeto |
 | `fuente`            | el último puesto de control justificado                    |
 | `target`            | el último bloque de límite de época                        |
@@ -106,29 +106,29 @@ El propio `execution_payload` contiene lo siguiente (observe que esto es idénti
 
 | Campo              | Descripción                                                               |
 |:------------------ |:------------------------------------------------------------------------- |
-| `parent_hash`      | hash del bloque padre                                                     |
-| `fee_recipient`    | dirección de la cuenta para pagar las tarifas de transacción a            |
+| `parent_hash`      | hash del bloque principal                                                 |
+| `fee_recipient`    | dirección de cuenta para pagar comisiones de transacción a                |
 | `state_root`       | hash raíz para el estado global después de aplicar cambios en este bloque |
 | `receipts_root`    | hash de los recibos de transacción trie                                   |
 | `logs_bloom`       | estructura de datos que contiene registros de eventos                     |
-| `prev_randao`      | valor utilizado en la selección aleatoria del validador                   |
+| `prev_randao`      | valor usado en la selección aleatoria del validador                       |
 | `block_number`     | el número del bloque actual                                               |
 | `gas_limit`        | gas máximo permitido en este bloque                                       |
 | `gas_used`         | la cantidad real de gas utilizada en este bloque                          |
-| `marca de tiempo`  | el tiempo de bloqueo                                                      |
+| `marca de tiempo`  | el tiempo del bloque                                                      |
 | `extra_data`       | datos adicionales arbitrarios como bytes sin procesar                     |
-| `base_fee_per_gas` | el valor de la tarifa base                                                |
-| `block_hash`       | Hash del bloque de ejecución                                              |
+| `base_fee_per_gas` | el valor de la tarifa de base                                             |
+| `block_hash`       | hash del bloque de ejecución                                              |
 | `transacciones`    | lista de transacciones por ejecutar                                       |
-| `retiradas`        | lista de objetos de retiradas                                             |
+| `withdrawals`      | lista de objetos de retiradas                                             |
 
 La lista de `retiradas` contiene objetos de `retirada` estructurados de la siguiente manera:
 
 | Campo            | Descripción                                          |
 |:---------------- |:---------------------------------------------------- |
 | `dirección`      | dirección de la cuenta que ha realizado una retirada |
 | `amount`         | cantidad de la retirada                              |
-| `índice`         | valor del índice de la retirada                      |
+| `index`          | valor del índice de la retirada                      |
 | `validatorIndex` | valor del índice del validador                       |
 
 ## Tiempo del bloque {#block-time}

public/content/translations/es/developers/docs/blocks/index.md

@@ -56,7 +56,7 @@ Los validadores crean bloques. Un validador se selecciona aleatoriamente en cada
 
 Un sistema de prueba de participación es criptoeconómicamente seguro, porque un atacante que intente tomar el control de la cadena debe destruir una cantidad masiva de ETH. Un sistema de recompensas alienta a participantes individuales a comportarse honestamente, y las penalizaciones desaniman a los participantes a actuar malintencionadamente.
 
-Más información sobre la [prueba de participación](/developers/docs/consensus-mechanisms/pos/).
+Más información sobre la [prueba de participación](developers/docs/consensus-mechanisms/pos/).
 
 ### Una guía visual {#types-of-consensus-video}
 
@@ -82,7 +82,7 @@ Ethereum utiliza un mecanismo de consenso conocido como [Gasper](/developers/doc
 - [Sobre la seguridad y el rendimiento de las cadenas de bloques de prueba de trabajo](https://eprint.iacr.org/2016/555.pdf)
 - [Fallo bizantino](https://en.wikipedia.org/wiki/Byzantine_fault)
 
-_¿Conoce algún recurso comunitario que le haya sido de ayuda? Edite la página y añádalo._
+_¿Conoce algún recurso de la comunidad que le haya servido de ayuda? Edite esta página y añádalo._
 
 ## Temas relacionados {#related-topics}
 

public/content/translations/es/developers/docs/blocks/tx-block.svg.xlsx

@@ -6,7 +6,7 @@ lang: es
 
 Los ladrones y saboteadores buscan constantemente oportunidades para atacar el software cliente de Ethereum. Esta página describe los vectores de ataque conocidos en la capa de consenso de Ethereum y describe cómo se pueden defender esos ataques. La información de esta página está resumida de una [versión más larga](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs).
 
-## Prerrequisitos {#prerequisites}
+## Requisitos previos {#prerequisites}
 
 Se requieren algunos conocimientos básicos de la[prueba de participación](/developers/docs/consensus-mechanisms/pos/). Además, será útil tener una comprensión básica de la [capa de incentivos](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) y del algoritmo de elección de bifurcación de Ethereum, [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper).
 

public/content/translations/es/developers/docs/consensus-mechanisms/index.md

@@ -1,5 +1,5 @@
 ---
-title: Certificaciones
+title: Atestaciones
 description: Una descripción de las certificaciones sobre la prueba de participación de Ethereum.
 lang: es
 ---
@@ -50,9 +50,15 @@ El ciclo de vida de la certificación se describe en el siguiente esquema:
 
 ## Recompensas {#rewards}
 
-Se recompensa a los validadores por presentar certificaciones. La recompensa de certificación depende de dos variable: la `recompensa de base` y el `retraso de inclusión`. El mejor caso para el retraso de inclusión es que sea igual a 1.
+Se recompensa a los validadores por presentar certificaciones. La recompensa de la certificación depende de las banderas de participación (fuente, objetivo y cabeza), la recompensa base y la tasa de participación.
 
-`attestation reward = 7/8 x base reward x (1/inclusion delay)`
+Cada una de las banderas de participación puede ser verdadera o falsa, dependiendo de la certificación presentada y de su retraso en la inclusión.
+
+La mejor situación se produce cuando las tres banderas son ciertas, en cuyo caso un validador ganaría (por bandera correcta):
+
+`recompensa += recompensa base * peso de la bandera * tasa de atestación de la bandera / 64`
+
+La tasa de certificación de la bandera se mide utilizando la suma de los saldos efectivos de todos los validadores de certificación para la bandera dada, en comparación con el saldo efectivo del activo total.
 
 ### La recompensa de base {#base-reward}
 
@@ -78,9 +84,9 @@ Hay 16 agregadores por época en total. Además, los validadores aleatorios se s
 
 Tenga en cuenta que en algunos casos un agregador afortunado también puede convertirse en el proponente de bloques. Si la certificación no se incluyó porque el proponente del bloque ha desaparecido, el siguiente proponente del bloque elegiría la certificación añadida y la incluiría en el siguiente bloque. Sin embargo, el **retraso de la inclusión** aumentará un valor.
 
-## Más lecturas {#further-reading}
+## Más información {#further-reading}
 
 - [Certificaciones en la especificación de consenso anotada de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
-- [Certificaciones en eth2book.info](https://eth2book.info/altair/part3/containers/dependencies#attestationdata)
+- [Certificaciones en eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
 
-_¿Conoces algún recurso en la comunidad que te haya servido de ayuda? Edita esta página y añádelo._
+_¿Conoce algún recurso de la comunidad que le haya servido de ayuda? Edite esta página y añádalo._

public/content/translations/es/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md

@@ -18,7 +18,7 @@ La prueba de participación requiere que los nodos, conocidos como validadores,
 
 La prueba de trabajo consume mucha más energía, porque la actividad de minería conlleva el consumo de electricidad. La prueba de participación, por otro lado, requiere solo una cantidad muy pequeña de energía: los validadores de Ethereum incluso pueden ejecutarse en un dispositivo de baja potencia como Raspberry Pi. Se cree que el mecanismo de prueba de participación de Ethereum es más seguro que la prueba de trabajo, porque el coste del ataque es mayor y las consecuencias para un atacante son más severas.
 
-La prueba de trabajo frente a la prueba de participación es un tema polémico. [El blog de Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) y el debate entre Justin Drake y Lyn Alden dan un buen resumen de los argumentos.
+La prueba de trabajo frente a la prueba de participación es un tema polémico. [El blog de Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work)y el debate entre Justin Drake y Lyn Alden ofrecen un buen resumen de los argumentos.
 
 <YouTube id="1m12zgJ42dI" />