Spanish translation catchup

src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx

@@ -78,12 +78,12 @@ contract GreeterOperator {
 Pasamos el mensaje ejecutando `executeFunctionCrosschain` y pasando los siguientes parámetros:
 
 - `scrollMessengerAddress`: Esto dependerá de dónde hayas desplegado el contrato `GreeterOperator`.
-  - Si lo desplegaste en Sepolia utiliza `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. Si lo has desplegado en Scroll utiliza `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
+  - Si lo desplegaste en Sepolia utiliza `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. Si lo has desplegado en Scroll Sepolia utiliza `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
 - `targetAddress`: La dirección del contrato `Greeter` en la cadena opuesta.
 - `value`: En este caso es `0` porque el `setGreeting` no es de tipo `payable`.
 - `greeting`: Es el parámetro que se enviará a través del mensaje. Prueba pasar `"¡Este mensaje fue ejecutado de manera crosschain!"`.
 - `gasLimit`:
-  - Si estás enviando el mensaje de L1 a L2, alrededor de un límite de gas de `1000000` debería ser más que suficiente.
+  - Si estás enviando el mensaje de L1 a L2, alrededor de un límite de gas de `1000000` debería ser más que suficiente. Habiendo dicho esto, si estableces un valor muy alto, y tu `msg.value` no cubre `gasLimit` * `baseFee`, la transacción revertirá. Si `msg.value` es mayor a la comisión de gas, la porción que no se usó se te devolverá.
   - Si estás enviando el mensaje de L2 a L1, pasa `0`, ya que la transacción se completará ejecutando una transacción adicional en L1.
 
 ### Retransmisión del mensaje al enviar de L2 a L1

src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx

@@ -114,7 +114,7 @@ Deposita tokens ERC1155 desde L1 en la cuenta de un destinatario en L2.
 | to        | Dirección de la cuenta del destinatario en L2.         |
 | tokenId   | Id del NFT a depositar.                            |
 | amount    | Cantidad de tokens a depositar.                  |
-| gasLimit  | Límite de gas necesario para completar el depósito en L2. |
+| gasLimit  | Límite de gas necesario para completar el depósito en L2. La porción de gas que no fué utilizado será automáticamente enviada de vuelta. |
 
 ### updateTokenMapping
 

src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx

@@ -85,7 +85,7 @@ Depósito de un NFT ERC721 desde L1 a la cuenta de un destinatario en L2.
 | token     | Dirección del contrato ERC721 NFT en L1.         |
 | to        | Dirección de la cuenta del destinatario en L2.         |
 | tokenId   | Id del NFT a depositar.                            |
-| gasLimit  | Límite de gas necesario para completar el depósito en L2. |
+| gasLimit  | Límite de gas necesario para completar el depósito en L2. La porción de gas que no fué utilizado será automáticamente enviada de vuelta. |
 
 ### updateTokenMapping
 
@@ -105,7 +105,7 @@ Actualización del mapping que conecta un contrato NFT de L1 a L2.
 ### withdrawERC721
 
 ```solidity
-function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
+function withdrawERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
 ```
 
 Envío de un ERC721 NFT desde L2 a la cuenta de un destinatario en L1.

src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx

@@ -30,10 +30,9 @@ Al enviar tokens ERC20, no tienes que preocuparte de seleccionar la Gateway corr
 Todos los contratos Gateway formarán el mensaje y lo enviarán al `L1ScrollMessenger` que puede enviar mensajes arbitrarios a L2. El `L1ScrollMessenger` pasa el mensaje a la `L1MessageQueue`. Cualquier usuario puede enviar mensajes directamente al Messenger para ejecutar datos arbitrarios en L2. Esto significa que pueden ejecutar cualquier función en L2 desde una transacción realizada en L1 a través del bridge. Aunque una aplicación podría pasar directamente mensajes a los contratos de tokens existentes, el Gateway abstrae los detalles y simplifica las transferencias y llamadas.
 
 <Aside type="tip" title="">
-  Los usuarios también pueden omitir el `L1ScrollMessenger` y enviar mensajes directamente a la `L1MessageQueue`. Si se envía un mensaje
+  En el futuro, los usuarios también podrán omitir el `L1ScrollMessenger` y enviar mensajes directamente a la `L1MessageQueue`. Si se envías un mensaje
   a través de `L1MessageQueue`, el remitente de la transacción será la dirección del usuario que envía la transacción, no la
-  dirección del `L1ScrollMessenger`. Más información sobre el envío de mensajes arbitrarios en [ El Scroll
-  Messenger](/es/developers/l1-and-l2-bridging/the-scroll-messenger).
+  dirección del `L1ScrollMessenger`.
 </Aside>
 
 Cuando se crea un nuevo bloque en L1, el Watcher detectará el mensaje en la `L1MessageQueue` y lo pasará al servicio Relayer, que enviará la transacción a L2 a través del nodo l2geth. Finalmente, el nodo l2geth pasará la transacción al contrato `L2ScrollMessagner` para su ejecución en L2.
@@ -107,7 +106,7 @@ Envía ETH desde L1 a L2.
 | --------- | --------------------------------------------------------------------------------------------------------------------------- |
 | to        | Dirección de la cuenta del destinatario en L2.                                                                                   |
 | amount    | Cantidad de token a transferir, en wei.                                                                                    |
-| gasLimit  | Límite de gas necesario para completar el depósito en la L2. De 4000 a 10000 de gas debería ser suficiente para procesar la transacción. |
+| gasLimit  | Límite de gas necesario para completar el depósito en la L2. De 170000 de gas debería ser suficiente para procesar la transacción. Recuerda que todo el excedente gas que no fue utilizado será automáticamente devuelto. |
 
 ### depositERC20
 
@@ -122,7 +121,7 @@ Envía ERC20 tokens desde L1 a L2.
 | token     | Dirección del token en L1.                                                                                                    |
 | to        | Dirección de la cuenta del destinatario en L2.                                                                                   |
 | amount    | Cantidad de token a transferir, en wei.                                                                                    |
-| gasLimit  | Límite de gas necesario para completar el depósito en la L2. De 4000 a 10000 de gas debería ser suficiente para procesar la transacción. |
+| gasLimit  | Límite de gas necesario para completar el depósito en la L2. 20000 de gas debería ser suficiente para procesar la transacción, dependiendo del Gateway, los fondos que no fueron usados serán devueltos. |
 
 ### getL2ERC20Address
 

src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md

@@ -18,7 +18,7 @@ Un **[esquema de compromiso](https://en.wikipedia.org/wiki/Commitment_scheme)**
 
 Los esquemas de compromiso seguros tienen dos características:
 
-1. **Binding**: una vez publicado el compromiso $c$, el committer no debe ser capaz de encontrar algún otro valor $v'$ distinto de $v$ que también corresponda a $c$. Es decir, el compromiso $c$ vincula al committer a su valor original $v$.
+1. **Binding**: una vez publicado el compromiso $c$, el committer no debe ser capaz de encontrar algún otro valor $v'$ distinto de $v$ que también corresponda a $c$. Es decir, el compromiso $c$ vincula al committer al valor original $v$.
 2. **Hiding**: el verifier no debe poder obtener ninguna información sobre el valor original $v$ a partir del compromiso $c$. Es decir, el compromiso $c$ oculta toda la información sobre el valor original $v$.
 
 ## Esquemas de Compromiso Polinómicos

src/content/docs/es/technology/bridge/cross-domain-messaging.mdx

@@ -93,7 +93,7 @@ function sendMessage(
 </ToggleElement>
 
 
-Ambas funciones requieren que los usuarios proporcionen un límite de gas para la transacción `L1MessageTx` correspondiente en L2 y paguen por adelantado el [Message Relay Fee](#message-relay-fee) en L1, que se calcula en función del importe del límite de gas. La comisión se recoge en un contrato `feeVault` en L1. En caso de que la transacción falle en L2 porque el usuario no ha establecido el límite de gas correcto para su mensaje en L1, el usuario puede repetir el mismo mensaje con un límite de gas más alto. Puedes encontrar más detalles en la sección [Reintento de Mensajes Fallidos](#reintentar-mensajes-fallidos).
+Ambas funciones requieren que los usuarios proporcionen un límite de gas para la transacción `L1MessageTx` correspondiente en L2 y paguen por adelantado el [Message Relay Fee](#message-relay-fee) en L1, que se calcula en función del importe del límite de gas. La comisión se recoge en un contrato `feeVault` en L1. En caso de que la transacción falle en L2 porque el usuario no ha establecido el límite de gas correcto para su mensaje en L1, el usuario puede repetir el mismo mensaje con un límite de gas más alto. Puedes encontrar más detalles en la sección [Reintento de Mensajes Fallidos](#reintentar-mensajes-fallidos), pero dado que la porción de gas de comisiones que no fue usada es devuelta al usuaior, hoy hay penalidad por sobrestimar el límite de gas.
 
 Las funciones `sendMessage` codifican los argumentos en un mensaje entre dominios (véase el fragmento de código siguiente), donde el nonce del mensaje es el siguiente índice de la cola de mensajes en L1. Los datos codificados se utilizan como calldata en la transacción `L1MessageTx` ejecutada en L2. Ten en cuenta que estos mensajes entre dominios siempre llaman a la función `relayMessage` del contrato `L2ScrollMessenger` en L2.
 

src/content/docs/es/technology/chain/accounts.mdx

@@ -20,7 +20,7 @@ La cuenta en Scroll contiene los siguientes campos:
 - `storageRoot`: El hash raíz del trie de almacenamiento. Dado que Scroll utiliza [zkTrie](/es/technology/sequencer/zktrie) para el trie de almacenamiento, `storageRoot` almacena el hash digest de Poseidon en un entero de 256 bits.
 - `codeHash`: El hash digest Keccak del bytecode del contrato.
 - `PoseidonCodeHash` (**nuevo campo**): El hash digest Poseidon del bytecode del contrato en un entero de 256 bits.
-- `CodeSize` (**nuevo campo**): El número de bytes en el bytecode del contrato.
+- `CodeSize` (**nuevo campo**): El tamaño del bytecode del contrato en bytes.
 
 ## Estado
 

src/content/docs/es/technology/security/audits-and-bug-bounty.mdx

@@ -37,8 +37,8 @@ Scroll ha trabajado con varias firmas líderes en auditoría de seguridad de la
   - Wave 2
   - Wave 3
 - Zellic y Kalos
-  - [Wave 1](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%201%20Audit%20Report.pdf)
-  - [Wave 2](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%202%20Audit%20Report.pdf)
+  - [Wave 1](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%201%20-%20Audit%20Report.pdf)
+  - [Wave 2](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%202%20-%20Audit%20Report.pdf)
 
 ### Implementación del Nodo
 

src/content/docs/es/technology/sequencer/zktrie.mdx

@@ -63,7 +63,7 @@ La eliminación de un nodo hoja es similar a la inserción. En la Figura 3 se il
 
 1. El nodo hermano del nodo hoja que se va a eliminar es un nodo rama (Figura 3a).
 En este caso, podemos simplemente reemplazar el nodo `a` por un nodo vacío y actualizar el hash de sus ancestros hasta el nodo raíz.
-2. El nodo hoja a eliminar es un nodo hoja (Figura 3b). De forma similar al caso 1, primero sustituimos el nodo hoja por un nodo vacío y empezamos a contraer su nodo hermano hacia arriba hasta que su nodo hermano no sea un nodo vacío. Por ejemplo, en la figura 3b, sustituimos el nodo hoja `b` por un nodo vacío. Como el hermano del nodo `c` se convierte ahora en un nodo vacío, tenemos que mover el nodo `c` un nivel hacia arriba y reemplazar a su padre. El nuevo hermano del nodo `c`, el nodo `e`, sigue siendo un nodo vacío. Así que de nuevo movemos el nodo `c` hacia arriba. Ahora que el hermano del nodo `c` es el nodo `a`, un nodo hoja, el proceso de borrado ha terminado.
+2. El nodo hermano del nodo a hoja a eliminar (Figura 3b). De forma similar al caso 1, primero sustituimos el nodo hoja por un nodo vacío y empezamos a contraer su nodo hermano hacia arriba hasta que su nodo hermano no sea un nodo vacío. Por ejemplo, en la figura 3b, sustituimos el nodo hoja `b` por un nodo vacío. Como el hermano del nodo `c` se convierte ahora en un nodo vacío, tenemos que mover el nodo `c` un nivel hacia arriba y reemplazar a su padre. El nuevo hermano del nodo `c`, el nodo `e`, sigue siendo un nodo vacío. Así que de nuevo movemos el nodo `c` hacia arriba. Ahora que el hermano del nodo `c` es el nodo `a`, un nodo hoja, el proceso de borrado ha terminado.
 
 Ten en cuenta que el hermano de un nodo hoja en una zkTrie válida no puede ser un nodo vacío. De lo contrario, siempre debemos purgar el subárbol y mover el nodo hoja hacia arriba.