diff --git a/public/locales/en/translation.json b/public/locales/en/translation.json
index 73586261b..506fb40b8 100644
--- a/public/locales/en/translation.json
+++ b/public/locales/en/translation.json
@@ -1,4 +1,14 @@
{
+ "rightSidebar": {
+ "onThisPage": "On This Page",
+ "more": "More",
+ "editThisPage": "Edit this page",
+ "joinOurCommunity": "Join our community",
+ "feedback": "Feedback"
+ },
+ "ui": {
+ "whatsNext": "What's Next"
+ },
"landing": {
"test": "test",
"search": {
diff --git a/public/locales/es/translation.json b/public/locales/es/translation.json
index 73586261b..594b3a610 100644
--- a/public/locales/es/translation.json
+++ b/public/locales/es/translation.json
@@ -1,35 +1,45 @@
{
+ "rightSidebar": {
+ "onThisPage": "En esta página",
+ "more": "Más",
+ "editThisPage": "Editar esta página",
+ "joinOurCommunity": "Únete a nuestro Discord",
+ "feedback": "Feedback"
+ },
+ "ui": {
+ "whatsNext": "¿Qué sigue?"
+ },
"landing": {
"test": "test",
"search": {
- "title": "Welcome to the Scroll Documentation",
- "placeholder": "Search Scroll documentation..."
+ "title": "Bienvenido a la Documentación de Scroll",
+ "placeholder": "Buscar Documentación de Scroll..."
},
"newUserCTA": {
- "title": "New to Scroll and ZK Rollups?",
- "description": "Learn the basics in the Getting Started Guide."
+ "title": "Nuevo en Scroll y los ZK Rollups?",
+ "description": "Aprende lo básico en la Guía de Inicio"
},
"resourcesCTA": {
- "title": "Useful resources"
+ "title": "Recursos Útiles"
},
"nodesCTA": {
- "title": "Need to run your own Scroll Node?",
- "description": "See the Node Operator’s Guide to learn about starting and maintaining Scroll Nodes.",
- "buttonText": "Node Operator’s Guide"
+ "title": "Necesitas correr tu propio Nodo de Scroll?",
+ "description": "Consulte la Guía del Operador de Nodos para obtener más información sobre la puesta en marcha y el mantenimiento de los Nodos de Scroll.",
+ "buttonText": "Guía del Operador de Nodos"
},
"TutorialsCTA": {
- "title": "Watch tutorials",
- "description": "Learn more about the technology we are building. We're constantly uploading new videos to our YouTube channel.",
- "buttonText": "Watch tutorials"
+ "title": "Ver tutoriales",
+ "description": "Obtenga más información sobre la tecnología que estamos construyendo. Subimos constantemente nuevos vídeos a nuestro canal de YouTube.",
+ "buttonText": "Ver tutoriales"
},
"LinksCTA": {
"card1": {
- "title": "Need integration support?",
+ "title": "¿Necesita ayuda para integrarse?",
"description": "Talk to an expert once we TODO: a url"
},
"card2": {
"title": "Discord",
- "description": "Join the community"
+ "description": "Únete a nuestra Comunidad"
},
"card3": {
"title": "TODO: Discourse",
@@ -44,94 +54,94 @@
},
"sidebar": {
"gettingStarted": {
- "gettingStarted": "Getting Started",
- "overview": "Overview",
+ "gettingStarted": "Primeros Pasos",
+ "overview": "Vista General",
"scrollSepoliaTestnet": "Scroll Sepolia Testnet",
- "userGuide": "User Guide",
- "setup": "Setup",
+ "userGuide": "Guía de Usuario",
+ "setup": "Configuración",
"faucet": "Faucet",
"bridge": "Bridge",
- "transferTokens": "Transfer Tokens",
- "commonErrors": "Common Errors",
+ "transferTokens": "Transferencia de Tokens",
+ "commonErrors": "Errores Comunes",
"rollupExplorer": "Rollup Explorer",
"scrollSepoliaBlockExplorer": "Scroll Sepolia Explorer",
"sepoliaBlockExplorer": "Sepolia Explorer",
- "community": "Community",
+ "community": "Comunidad",
"discord": "Discord",
- "communityForum": "Community Forum"
+ "communityForum": "Forum de la Comunidad"
},
"developers": {
- "developers": "Developers",
- "buildingOnScroll": "Building on Scroll",
- "developerQuickstart": "Developer Quickstart",
- "verifyingSmartContracts": "Verifying Smart Contracts",
- "scrollContracts": "Scroll Contracts",
- "ethereumAndScrollDifferences": "Ethereum & Scroll Differences",
- "l1AndL2Bridging": "L1 & L2 Bridging",
- "ethAndErc20TokenBridge": "ETH & ERC20 Token Bridge",
+ "developers": "Desarrolladores",
+ "buildingOnScroll": "Construyendo en Scroll",
+ "developerQuickstart": "Inicio rápido para Desarrolladores",
+ "verifyingSmartContracts": "Verificando Smart Contracts",
+ "scrollContracts": "Contratos de Scroll",
+ "ethereumAndScrollDifferences": "Diferencias entre Scroll y Ethereum",
+ "l1AndL2Bridging": "L1 y L2 Bridging",
+ "ethAndErc20TokenBridge": "ETH y ERC20 Token Bridge",
"erc721NftBridge": "ERC721 NFT Bridge",
"erc1155TokenBridge": "ERC1155 Token Bridge",
- "theScrollMessenger": "The Scroll Messenger",
- "transactionFeesOnScroll": "Transaction Fees on Scroll",
- "l2Fee": "L2 Fee",
- "l1Fee": "L1 Fee",
+ "theScrollMessenger": "El Scroll Messenger",
+ "transactionFeesOnScroll": "Comisiones de Transacciones en Scroll",
+ "l2Fee": "Comisión L2",
+ "l1Fee": "Comisión L1",
"gasOracle": "Gas Oracle",
- "future": "Future",
- "guides": "Guides",
- "contractDeploymentTutorial": "Contract Deployment Tutorial",
- "crossChainInteraction": "Scroll Messenger Cross-chain Interaction",
- "bridgingERC20TokenThroughCustomGateway": "Bridge an ERC20 through the Custom Gateway",
- "bridgingERC721NftThroughCustomGateway": "Bridging ERC721 NFT through Custom Gateway",
- "bridgingERC1155ThroughCustomGateway": "Bridging ERC1155 through Custom Gateway",
- "estimatingGasAndTxFees": "Estimating Gas & Tx Fees",
- "resources": "Resources",
+ "future": "Futuro",
+ "guides": "Guías",
+ "contractDeploymentTutorial": "Tutorial de Despliegue de Contratos",
+ "crossChainInteraction": "Interacción Cross-chain del Scroll Messenger",
+ "bridgingERC20TokenThroughCustomGateway": "Bridging de un ERC20 a través de una Gateway Personalizada",
+ "bridgingERC721NftThroughCustomGateway": "Bridging de un ERC721 NFT a través de una Gateway Personalizada",
+ "bridgingERC1155ThroughCustomGateway": "Bridging de un ERC1155 a través de una Gateway Personalizada",
+ "estimatingGasAndTxFees": "Estimación de las Tarifas de Gas y Tx",
+ "resources": "Recursos",
"rollupExplorer": "Rollup Explorer",
"scrollSepoliaBlockExplorer": "Scroll Sepolia Explorer",
"sepoliaBlockExplorer": "Sepolia Explorer"
},
"technology": {
- "introduction": "Introduction",
- "principles": "Principles",
- "scrollArchitecture": "Scroll Architecture",
- "overview": "Overview",
+ "introduction": "Introducción",
+ "principles": "Principios",
+ "scrollArchitecture": "Arquitectura de Scroll",
+ "overview": "Vista General",
"scrollChain": "Scroll Chain",
- "accountsAndState": "Accounts and State",
- "blocks": "Blocks",
- "transactions": "Transactions",
- "rollupProcess": "Rollup Process",
- "evmDifferencesFromEthereum": "EVM Differences from Ethereum",
+ "accountsAndState": "Cuentas y Estado",
+ "blocks": "Bloques",
+ "transactions": "Transacciones",
+ "rollupProcess": "Proceso del Rollup",
+ "evmDifferencesFromEthereum": "Diferencias de EVM respecto a Ethereum",
"bridge": "Bridge",
"crossDomainMessaging": "Cross-Domain Messaging",
- "depositGateways": "Deposit Gateways",
- "withdrawGateways": "Withdraw Gateways",
+ "depositGateways": "Gateways de Depósito",
+ "withdrawGateways": "Gateways de Retiro",
- "sequencer": "Sequencer",
- "executionNode": "Execution Node",
- "rollupNode": "Rollup Node",
+ "sequencer": "Secuenciador",
+ "executionNode": "Nodo de Ejecución",
+ "rollupNode": "Nodo Rollup",
"zkTrie": "zkTrie",
"zkevm": "zkEVM",
- "introToZkevm": "Intro to zkEVM",
- "zkevmOverview": "zkEVM Overview",
- "bridgeOverview": "Bridge Overview",
+ "introToZkevm": "Intro a la zkEVM",
+ "zkevmOverview": "Vista General de la zkEVM",
+ "bridgeOverview": "Vista General del Bridge",
"prover": "Prover",
"proofGeneration": "Proof Generation",
"cpuProverRepo": "CPU Prover Repo"
},
"learn": {
- "ethereumAndProtocols": "Ethereum & Protocols",
- "theScalabilityProblem": "The Scalability Problem",
- "introToRollups": "Intro to Rollups",
+ "ethereumAndProtocols": "Ethereum y Protocolos",
+ "theScalabilityProblem": "El Problema de la Escalabilidad",
+ "introToRollups": "Intro a los Rollups",
"zeroKnowledge": "Zero Knowledge",
- "introToZeroKnowledge": "Intro to Zero Knowledge",
- "polynomialCommitmentSchemes": "Polynomial Commitment Schemes",
- "kzgCommitmentScheme": "KZG Commitment Scheme",
- "additionalResources": "Additional Resources"
+ "introToZeroKnowledge": "Intro a la Zero Knowledge",
+ "polynomialCommitmentSchemes": "Esquemas de Compromiso Polinómicos",
+ "kzgCommitmentScheme": "Esquema de Compromiso KZG",
+ "additionalResources": "Recursos Adicionales"
}
},
"notTranslated": {
- "notTranslated": "This page has not been translated yet."
+ "notTranslated": "Esta página no ha sido traducida aún."
}
}
diff --git a/src/components/Header/Header.astro b/src/components/Header/Header.astro
index 26c39da59..5dbcbf177 100644
--- a/src/components/Header/Header.astro
+++ b/src/components/Header/Header.astro
@@ -51,13 +51,11 @@ const section = frontmatter?.section ?? ""
{
- /*
MENU[i18next.language].map((link) => (
{link.text}
))
- */
}
-
Feedback
+
{t("rightSidebar.feedback")}
diff --git a/src/components/RightSidebar/TableOfContents/index.tsx b/src/components/RightSidebar/TableOfContents/index.tsx
index 37ab33571..b41dfe426 100644
--- a/src/components/RightSidebar/TableOfContents/index.tsx
+++ b/src/components/RightSidebar/TableOfContents/index.tsx
@@ -3,6 +3,7 @@ import { useStore } from "@nanostores/preact"
import type { FunctionalComponent } from "preact"
import { useState, useEffect, useRef } from "preact/hooks"
import { shouldUpdateToc } from "./tocStore"
+import i18next, { t } from "i18next"
export interface Heading {
depth: number
text: string
@@ -79,7 +80,7 @@ const TableOfContents: FunctionalComponent<{
return (
<>
-
On this page
+
{t("rightSidebar.onThisPage")}
{headings
.filter(({ depth }) => depth > 1 && depth < 4)
diff --git a/src/config/menu.ts b/src/config/menu.ts
index 36636386b..86c993daf 100644
--- a/src/config/menu.ts
+++ b/src/config/menu.ts
@@ -17,6 +17,16 @@ export const MENU: MenuItems = {
{ text: "Technology", link: "/en/technology", section: "technology" },
{ text: "Learn", link: "/en/learn", section: "learn" },
],
+ es: [
+ {
+ text: "¿Cómo empezar?",
+ link: "/es/getting-started/overview",
+ section: "gettingStarted",
+ },
+ { text: "Desarrolladores", link: "/es/developers", section: "developers" },
+ { text: "Tecnología", link: "/es/technology", section: "technology" },
+ { text: "Aprende", link: "/es/learn", section: "learn" },
+ ],
zh: [
{
text: "入门",
diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts
index 281d76fab..dff7ea04d 100644
--- a/src/config/sidebar.ts
+++ b/src/config/sidebar.ts
@@ -62,7 +62,7 @@ export const getSidebar = () => {
],
developers: [
{
- section: "Developers",
+ section: t("sidebar.developers.developers"),
contents: [
{ title: t("sidebar.developers.buildingOnScroll"), url: formatUrl("developers") },
{ title: t("sidebar.developers.developerQuickstart"), url: formatUrl("developers/developer-quickstart") },
@@ -125,7 +125,7 @@ export const getSidebar = () => {
],
},
{
- section: "Guides",
+ section: t("sidebar.developers.guides"),
contents: [
{
title: t("sidebar.developers.contractDeploymentTutorial"),
@@ -154,7 +154,7 @@ export const getSidebar = () => {
],
},
{
- section: "Resources",
+ section: t("sidebar.developers.resources"),
contents: [
{ title: t("sidebar.developers.rollupExplorer"), url: "https://scroll.io/rollupscan" },
{ title: t("sidebar.developers.scrollSepoliaBlockExplorer"), url: "https://sepolia-blockscout.scroll.io/" },
@@ -164,8 +164,8 @@ export const getSidebar = () => {
],
technology: [
{
- section: "Overview",
- contents: [{ title: t("Scroll Architecture"), url: formatUrl("technology") }],
+ section: t("sidebar.technology.overview"),
+ contents: [{ title: t("sidebar.technology.scrollArchitecture"), url: formatUrl("technology") }],
},
{
section: t("sidebar.technology.scrollChain"),
diff --git a/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx b/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx
index 2793510e2..398132087 100644
--- a/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx
+++ b/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx
@@ -5,6 +5,7 @@ title: "Scroll Messenger Cross-chain Interaction"
lang: "en"
permalink: "developers/guides/scroll-messenger-cross-chain-interaction"
excerpt: "In this example, we will launch a dummy smart contract on either Sepolia or Scroll Sepolia testnet and interact with it from the opposite chain."
+whatsnext: { "Bridge ERC20 through the Custom Gateway": "/developers/guides/bridge-erc20-through-the-custom-gateway" }
---
import Aside from "../../../../../components/Aside.astro"
diff --git a/src/content/docs/en/developers/scroll-contracts.mdx b/src/content/docs/en/developers/scroll-contracts.mdx
index 81bac2964..0570b661c 100644
--- a/src/content/docs/en/developers/scroll-contracts.mdx
+++ b/src/content/docs/en/developers/scroll-contracts.mdx
@@ -4,6 +4,7 @@ date: Last Modified
title: "Scroll Sepolia Contracts"
lang: "en"
permalink: "developers/scroll-contracts"
+whatsnext: { "Ethereum & Scroll Differences": "/developers/ethereum-and-scroll-differences" }
excerpt: "The network info and contract addresses you need to start with Scroll Sepolia Testnet."
---
diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx
index 90ac2bfd1..d22a3402a 100644
--- a/src/content/docs/en/technology/chain/transactions.mdx
+++ b/src/content/docs/en/technology/chain/transactions.mdx
@@ -62,15 +62,15 @@ First, users can directly submit transactions to L2 sequencers. To do so, users
Second, deposit and enforced transactions are originated on L1. Scroll L1 bridge contract provides three entry points for users and smart contracts to send transactions from the L1. All messages sent through these three entry points will be appended to the `L1MessageQueue` contract.
-- The `ScrollGatewayRouter` contract and several standard token gateways allow users and contracts to deposit standard tokens to L2. See more details in the [Deposit Token Gateways](/-oscADc8SoKAOxjtpcEqKg).
-- The `L1ScrollMessenger` contract allows users and contracts to send arbitrary messages to L2. See more details in the [Sending Arbitrary Messages](/UPyw7afFQE6q-9CIdIRBag#Sending-Arbitrary-Messages).
-- The `EnforcedTxGateway` contract allows EOAs to initiate an enforced transaction from the same address to withdraw tokens or call other contracts on L2. See more details in the [Sending Enforced Transaction](/UPyw7afFQE6q-9CIdIRBag#Sending-Enforced-Transactions).
+- The `ScrollGatewayRouter` contract and several standard token gateways allow users and contracts to deposit standard tokens to L2. See more details in the [Deposit Token Gateways](/technology/bridge/deposit-gateways).
+- The `L1ScrollMessenger` contract allows users and contracts to send arbitrary messages to L2. See more details in the [Sending Arbitrary Messages](/technology/bridge/cross-domain-messaging#sending-arbitrary-messages).
+- The `EnforcedTxGateway` contract allows EOAs to initiate an enforced transaction from the same address to withdraw tokens or call other contracts on L2. See more details in the [Sending Enforced Transaction](/technology/bridge/cross-domain-messaging#sending-enforced-transactions).
The Scroll sequencer periodically starts a new mining job. It pulls the L1 messages from the `L1MessageQueue` contract and transactions in the L2 mempool and seals a block. Once a transaction is included in a L2 block, its status becomes `Confirmed`.
### Commit Transaction Data
-The rollup node collects new L2 blocks and packs them into chunks and batches (see more details in [Transaction Batching](/RxRWLFtiQ7W_wbc0jMnQNA)). Periodically it sends a _Commit Transaction_ that posts the data of a batch of transactions to the L1 `ScrollChain` contract. After the Commit Transaction is finalized in a L1 block, the status of the transactions in this batch becomes `Committed`. At this time, users can reconstruct L2 state themselves completely based on the committed data from the L1 contract.
+The rollup node collects new L2 blocks and packs them into chunks and batches (see more details in [Transaction Batching](/technology/chain/transactions#transaction-batching)). Periodically it sends a _Commit Transaction_ that posts the data of a batch of transactions to the L1 `ScrollChain` contract. After the Commit Transaction is finalized in a L1 block, the status of the transactions in this batch becomes `Committed`. At this time, users can reconstruct L2 state themselves completely based on the committed data from the L1 contract.
### Finalize Transactions
diff --git a/src/content/docs/en/technology/zkevm/zkevm-overview.mdx b/src/content/docs/en/technology/zkevm/zkevm-overview.mdx
index 19a1b6326..50bc28318 100644
--- a/src/content/docs/en/technology/zkevm/zkevm-overview.mdx
+++ b/src/content/docs/en/technology/zkevm/zkevm-overview.mdx
@@ -5,7 +5,6 @@ title: "zkEVM Overview"
lang: "en"
permalink: "technology/zkevm-overview"
excerpt: "In order to understand how to build a zkEVM, which proves the execution of the EVM, we need to first look at the EVM itself."
-whatsnext: { "Bridge Overview": "/technology/bridge/bridge-overview" }
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
diff --git a/src/content/docs/es/developers/developer-quickstart.mdx b/src/content/docs/es/developers/developer-quickstart.mdx
index fc6b3f563..b30532fc3 100644
--- a/src/content/docs/es/developers/developer-quickstart.mdx
+++ b/src/content/docs/es/developers/developer-quickstart.mdx
@@ -1,11 +1,11 @@
---
section: developers
date: Last Modified
-title: "Developer Quickstart"
-lang: "en"
+title: "Inicio rápido para desarrolladores"
+lang: "es"
permalink: "developers/developer-quickstart"
-excerpt: "Scroll Developer Quickstart helps you acquire testnet Ether, configure your network, and access all of your favorite tooling"
-whatsnext: { "Verify Your Smart Contracts": "/developers/verifying-smart-contracts" }
+excerpt: "Scroll Developer Quickstart te ayuda a adquirir testnet Ether, configurar tu red y acceder a todas tus herramientas favoritas"
+whatsnext: { "Verifica Tus Smart Contracts": "/es/developers/verifying-smart-contracts" }
---
import Aside from "../../../../components/Aside.astro"
@@ -13,39 +13,39 @@ import ClickToZoom from "../../../../components/ClickToZoom.astro"
import networkSelection from "./_images/mmNetworkSelection.png"
import injectedProviderMM from "./_images/injectedProviderMM.png"
-With Scroll, your favorite tools for building and testing smart contracts just work.
+Con Scroll, tus herramientas favoritas para la creación y prueba de smart contracts simplemente funcionan.
-Since Scroll is bytecode equivalent with the EVM, you’ll just need to point your favorite builder tools at a Scroll Sepolia Testnet RPC Provider.
+Dado que Scroll es equivalente en código de bytes con la EVM, sólo tendrás que dirijir tus herramientas de creación favoritas a un proveedor RPC de Scroll Sepolia Testnet.
-If you run into any issues, please reach out in [our Discord](https://discord.gg/scroll).
+Si tiene algún problema, póngase en contacto con nosotros en [nuestro Discord](https://discord.gg/scroll).
-## Acquiring Testnet Ether
+## Adquiriendo Testnet Ether
-To start building on Scroll, you'll first need to acquire some testnet ETH. See the [Faucet](/user-guide/faucet) page for tips on getting test tokens on Sepolia. After this, you can bridge your testnet ETH to the Scroll Sepolia Testnet (Layer 2) using our [Bridge](/user-guide/bridge).
+Para empezar a construir en Scroll, primero tendrás que adquirir algunos ETH de testnet. Consulta la página [Faucet](/es/user-guide/faucet) para obtener consejos sobre la obtención de tokens de la testnet Sepolia. Después de esto, usted puede transferir sus testnet ETH a la Scroll Sepolia Testnet (Capa 2) utilizando nuestro [Bridge](/es/user-guide/bridge).
-For a walkthrough, start with the User Guide's [Setup](/user-guide/setup) page.
+Para obtener más información, consulte la página de [Setup](/es/user-guide/bridge) de la Guía del usuario.
-## Network Configuration
+## Configuración de red
-Use the table below to configure your Ethereum tools to the Scroll Sepolia Testnet.
+Utilice la siguiente tabla para configurar sus herramientas de Ethereum para la Scroll Sepolia Testnet.
-| Network Name | Scroll Sepolia Testnet | Sepolia Testnet |
+| Nombre de red | Scroll Sepolia Testnet | Sepolia Testnet |
| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) |
| Chain ID | 534351 | 11155111 |
| Currency Symbol | ETH | ETH |
| Block Explorer URL | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) |
-## Configure your tooling
+## Configure sus herramientas
- For setting up tooling to verify a smart contract deployment, see [Verifying Smart
- Contracts](/developers/verifying-smart-contracts).
+ Para configurar herramientas para verificar la implementación de un smart contract, consulte [Verificando Smart
+ Contracts](/es/developers/verifying-smart-contracts).
### Hardhat
-Modify your Hardhat config file `hardhat.config.ts` to point at the Scroll Sepolia Testnet public RPC.
+Modifica tu archivo de configuración de Hardhat `hardhat.config.ts` para que se dirija al RPC público de Scroll Sepolia Testnet.
```jsx
...
@@ -66,7 +66,7 @@ const config: HardhatUserConfig = {
### Foundry
-To deploy using the Scroll Sepolia Testnet Public RPC, run:
+Para desplegar utilizando el RPC público de Scroll Sepolia Testnet, ejecute:
```bash
forge create ... --rpc-url=https://sepolia-rpc.scroll.io/ --legacy
@@ -74,19 +74,19 @@ forge create ... --rpc-url=https://sepolia-rpc.scroll.io/ --legacy
### Remix Web IDE
-After compiling your contracts, the easiest way to deploy using Remix is by [setting up Metamask](/user-guide/setup#metamask), then selecting the **Scroll Sepolia Testnet** network.
+Después de compilar sus contratos, la forma más fácil de desplegar usando Remix es [configurando Metamask](/es/user-guide/setup#metamask) y seleccionando la red **Scroll Sepolia Testnet**.
-Now, in the “Deploy and Run Transactions” tab, use the “Environment” drop-down and select “Injected Provider - MetaMask.”
+Ahora, en la pestaña "Deploy and Run Transactions", utilice el desplegable "Environment" y seleccione "Injected Provider - MetaMask."
-Connect your wallet and select the Scroll Sepolia Testnet. Your account should be selected automatically in Remix, and you can click “Deploy.”
+Conecta tu wallet y selecciona el Scroll Sepolia Testnet. Tu cuenta debería seleccionarse automáticamente en Remix, y despues, puedes hacer clic en "Deploy."
### Truffle
-Assuming you already have a Truffle environment setup, go to the Truffle [configuration file](https://trufflesuite.com/docs/truffle/reference/configuration/), `truffle.js`. Make sure to have installed HDWalletProvider: `npm install @truffle/hdwallet-provider@1.4.0`
+Asumiendo que ya tienes un entorno Truffle configurado, ve al [archivo de configuración](https://trufflesuite.com/docs/truffle/reference/configuration/) de Truffle, `truffle.js`. Asegúrate de tener instalado HDWalletProvider: `npm install @truffle/hdwallet-provider@1.4.0`
```js
const HDWalletProvider = require("@truffle/hdwallet-provider")
@@ -104,22 +104,22 @@ module.exports = {
### Brownie
-To add the Scroll Sepolia Testnet, run the following command:
+Para añadir la Scroll Sepolia Testnet, ejecute el siguiente comando:
```bash
brownie networks add Ethereum scrollSepolia host=https://sepolia-rpc.scroll.io/ chainid=534351
```
-To set this as your default network, add the following in your project config file:
+Para establecer esta red como predeterminada, añada lo siguiente en el archivo de configuración del proyecto:
```yaml
networks:
default: scrollSepolia
```
-Another way to add the Scroll Sepolia Testnet is to create a `yaml` file and run a command to add it.
+Otra forma de añadir el Scroll Sepolia Testnet es crear un archivo `yaml` y ejecutar un comando para añadirlo.
-This is an example of a yaml file called `network-config.yaml`
+Este es un ejemplo de un archivo yaml llamado `network-config.yaml`.
```yaml
live:
@@ -132,13 +132,13 @@ live:
name: Scroll Sepolia Testnet
```
-To add the Scroll Sepolia Testnet to the network list, run the following command:
+Para añadir la Scroll Sepolia Testnet a la lista de redes, ejecute el siguiente comando:
```bash
brownie networks import ./network-config.yaml
```
-To deploy on Scroll, run the following command. In this example, `token.py` is the script to deploy the smart contract. Replace this with the name of your script:
+Para desplegar en Scroll, ejecute el siguiente comando. En este ejemplo, `token.py` es el script para desplegar el smart contract. Sustitúyelo por el nombre de tu script:
```bash
brownie run token.py --network scrollSepolia
@@ -146,7 +146,7 @@ brownie run token.py --network scrollSepolia
### ethers.js
-Setting up a Scroll Sepolia Testnet provider in an `ethers` script:
+Configuración de un proveedor de Scroll Sepolia Testnet en un script `ethers`:
```jsx
import { ethers } from "ethers"
@@ -156,11 +156,11 @@ const provider = new ethers.providers.JsonRpcProvider("https://sepolia-rpc.scrol
### scaffold-eth
-To deploy using Scaffold-eth, you’ll need to point both your Hardhat and React settings at the Scroll Sepolia Testnet.
+Para desplegar usando Scaffold-eth, necesitarás dirigir tus configuraciones de Hardhat y React a la Testnet de Scroll Sepolia.
-#### Configure Hardhat
+#### Configure el Hardhat
-In the `packages/hardhat/hardhat.config.js` file, you’ll add the network and select it as the default network.
+En el archivo `packages/hardhat/hardhat.config.js`, añadirás la red y la seleccionarás como red por defecto.
```jsx
...
@@ -184,18 +184,18 @@ module.exports = {
}
```
-Be sure to fund the deployment wallet as well! Run `yarn generate` to create the wallet and `yarn account` to check its funds. Once funded, run `yarn deploy --network scrollSepolia` to deploy on the Scroll Sepolia testnet.
+Asegúrate de financiar también la wallet de despliegue. Ejecute `yarn generate` para crear la wallet y `yarn account` para comprobar sus fondos. Una vez financiado, ejecuta `yarn deploy --network scrollSepolia` para desplegarlo en la Scroll Sepolia testnet.
-
- On some project forks, you'll want to disable the contract verification, which relies on Etherscan. This can be
- commented out in `packages/hardhat/deploy/00_deploy_your_contract.js`
+
+ En algunos forks de proyectos, querrás desactivar la verificación de contratos, que depende de Etherscan. Esto puede ser
+ comentado en `packages/hardhat/deploy/00_deploy_your_contract.js`.
-#### Configure the Frontend
+#### Configure el Frontend
-To configure your frontend, you need to add the Scroll Sepolia Testnet as a network option, then select it as default.
+Para configurar tu frontend, tienes que añadir la Scroll Sepolia Testnet como opción de red, y luego seleccionarlo como predeterminado.
-To add the network, modify `packages/react-app/src/constants.js` .
+Para añadir la red, modifica `packages/react-app/src/constants.js`.
```jsx
...
@@ -212,7 +212,7 @@ export const NETWORKS = {
}
```
-Next, in `packages/react-app/src/App.jsx` modify
+A continuación, en `packages/react-app/src/App.jsx` modifica
```jsx
...
diff --git a/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx b/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
index ad849c063..f62fc2655 100644
--- a/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
+++ b/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
@@ -1,51 +1,51 @@
---
section: developers
date: Last Modified
-title: "Ethereum & Scroll Differences"
-lang: "en"
+title: "Diferencias entre Scroll y Ethereum"
+lang: "es"
permalink: "developers/ethereum-and-scroll-differences"
-whatsnext: { "L1 & L2 Bridging": "/developers/l1-and-l2-bridging/" }
-excerpt: "There are a number of technical details that differ between Ethereum mainnet's EVM and Scroll's modified design for a zkEVM. Below you can see those differences as they exist now."
+whatsnext: { "L1 y L2 Bridging": "/es/developers/l1-and-l2-bridging" }
+excerpt: "Hay una serie de detalles técnicos que difieren entre el EVM de Ethereum mainnet y el diseño modificado de Scroll para un zkEVM. A continuación puedes ver esas diferencias tal y como existen ahora."
---
import Aside from "../../../../components/Aside.astro"
-A number of technical details differ between Ethereum mainnet's EVM and Scroll's modified design for a zkEVM. Below you can see those differences as they exist on Scroll Sepolia.
+Varios detalles técnicos difieren entre el EVM de Ethereum mainnet y el diseño modificado de Scroll para un zkEVM. A continuación puede ver esas diferencias tal y como existen en Scroll Sepolia.
-For open-source contributors and infrastructure builders, please contact our team for additional support.
+Los colaboradores de código abierto y los creadores de infraestructuras pueden ponerse en contacto con nuestro equipo para obtener ayuda adicional.
-
- For the average Solidity developer, these details won't affect your development experience.
+
+ Para el desarrollador Solidity promedio, estos detalles no afectaran la experiencia de desarrollador.
## EVM Opcodes
-| Opcode | Solidity equivalent | Scroll Behavior |
+| Opcode | Solidity equivalente | Comportamiento de Scroll |
| --------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------- |
-| `BLOCKHASH` | `block.blockhash` | Returns `keccak(chain_id \|\| block_number)` for the last 256 blocks. |
-| `COINBASE` | `block.coinbase` | Returns the pre-deployed fee vault contract address. See [Scroll Contracts](/developers/scroll-contracts). |
-| `DIFFICULTY` / `PREVRANDAO` | `block.difficulty` | Returns 0. |
-| `BASEFEE` | `block.basefee` | Disabled.[^eip1559] If the opcode is encountered, the transaction will be reverted. |
-| `SELFDESTRUCT` | `selfdestruct` | Disabled. If the opcode is encountered, the transaction will be reverted.[^willadpot] |
+| `BLOCKHASH` | `block.blockhash` | Regresa un `keccak(chain_id \|\| block_number)` por los últimos 256 bloques. |
+| `COINBASE` | `block.coinbase` | Regresa el pre-deployed fee vault contract address. Observa [Contractos de Scroll](/es/developers/scroll-contracts). |
+| `DIFFICULTY` / `PREVRANDAO` | `block.difficulty` | Regresa 0. |
+| `BASEFEE` | `block.basefee` | Deshabilitado.[^eip1559] Si se encuentra el opcode, la transacción se revertirá. |
+| `SELFDESTRUCT` | `selfdestruct` | Deshabilitado. Si se encuentra el opcode, la transacción se revertirá.[^willadpot] |
-[^eip1559]: We have currently disabled EIP-1559 on Scroll.
-[^willadpot]: Will change to adopt Ethereum’s solution in the future.
+[^eip1559]: Actualmente hemos deshabilitado la EIP-1559 en Scroll.
+[^willadpot]: Cambiará para adoptar la solución de Ethereum en el futuro.
-## EVM Precompiles
+## Precompilados EVM
-The `SHA2-256` (address `0x2`), `RIPEMD-160` (address `0x3`), and `blake2f` (address `0x9`) precompiles are currently not supported. Calls to these precompiled contracts will revert. We plan to enable these three precompiles in a future hard fork.
+Los precompilados `SHA2-256` (address `0x2`), `RIPEMD-160` (address `0x3`), y `blake2f` (address `0x9`) actualmente no estan soportados. Las llamadas a estos contratos precompilados se revertiran. Planeamos habilitar estos tres precompilados en un futuro hard fork.
-The `modexp` precompile is supported but only supports inputs of size less than or equal to 32 bytes (i.e. `u256`).
+El precompilado `modexp` esta habilitado pero solo soporta entradas con un tamaño igual o menor a 32 bytes (i.e. `u256`).
-The `ecPairing` precompile is supported, but the number of points(sets, pairs) is limited to 4, instead of 6.
+El precompilado `ecPairing` esta soportado, pero el número de puntos (sets, pairs) esta limitado a 4, en lugar de 6.
-The other EVM precompiles are all supported: `ecRecover`, `identity`, `ecAdd`, `ecMul`.
+Los todos otros precompilados EVM estan habilitados: `ecRecover`, `identity`, `ecAdd`, `ecMul`.
## State Account
-### **Additional Fields**
+### **Campos Adicionales**
-We added two fields in the current `StateAccount` object: `PoseidonCodehash` and `CodeSize`.
+Hemos añadido 2 campos adicionales al objeto `StateAccount` actual: `PoseidonCodehash` y `CodeSize`.
```go
type StateAccount struct {
@@ -61,43 +61,43 @@ type StateAccount struct {
### **CodeHash**
-Related to this, we maintain two types of codehash for each contract bytecode: Keccak hash and Poseidon hash.
+En relación con esto, mantenemos dos tipos de codehash para cada bytecode de contrato: Keccak hash y Poseidon hash.
-`KeccakCodeHash` is kept to maintain compatibility for `EXTCODEHASH`. `PoseidonCodeHash` is used for verifying correctness of bytecodes loaded in the zkEVM, where Poseidon hashing is far more efficient.
+`KeccakCodeHash` se mantiene para conservar la compatibilidad con `EXTCODEHASH`. `PoseidonCodeHash` se utiliza para verificar la corrección de los bytecodes cargados en la zkEVM, donde Poseidon hashing es mucho más eficiente.
### CodeSize
-When verifying `EXTCODESIZE`, it is expensive to load the whole contract data into the zkEVM. Instead, we store the contract size in storage during contract creation. This way, we do not need to load the code — a storage proof is sufficient to verify this opcode.
+A la hora de verificar el "EXTCODESIZE", resulta costoso cargar todos los datos del contrato en la zkEVM. En su lugar, almacenamos el tamaño del contrato durante la creación del mismo. De esta manera, no necesitamos cargar el código - una storage proof es suficiente para verificar este opcode.
-## Block Time
+## Tiempo de Bloques
-The Sepolia Testnet aims for a constant block time of 3 seconds. This is shorter and more consistent than the 12 seconds used in the Ethereum under ideal conditions.
+El Testnet de Sepolia tiene como objetivo un tiempo de bloque constante de 3 segundos. Esto es más corto y constante que los 12 segundos utilizados en Ethereum en condiciones ideales.
-This was chosen for two reasons:
+Esto se eligió por dos razones:
-- Having faster, constant block time results in quicker feedback and a better user experience.
-- As we optimize the zkEVM circuits in our testnets, even if we maintain a smaller gas limit per block or batch, we can still reach higher throughput than Ethereum.
+- Tener un tiempo de bloque más rápido y constante se traduce en una respuesta más rápida y una mejor experiencia de usuario.
+- A medida que optimizamos los circuitos zkEVM en nuestras redes de prueba, incluso si mantenemos un límite de gas menor por bloque o lote, podemos alcanzar un rendimiento superior al de Ethereum.
-## Future EIPs
+## EIPs Futuros
-We keep a close eye on all emerging EIPs adopted by Ethereum and adopt them when suitable. If you’re interested in more specifics, reach out in [our community forum](https://community.scroll.io) or on the [Scroll Discord](https://discord.gg/scroll).
+Seguimos de cerca todas las EIP emergentes adoptadas por Ethereum y las adoptamos cuando es conveniente. Si está interesado en más detalles, póngase en contacto con nosotros en [nuestro foro de la comunidad](https://community.scroll.io) o en [Scroll Discord](https://discord.gg/scroll).
-## EVM Target version
+## Versión objetivo de la EVM
-To ensure no unexpected behavior happens in your contracts, we recommend using `london` as the target version when compiling your smart contracts.
+Para garantizar que no se produzca ningún comportamiento inesperado en sus contratos, recomendamos utilizar `london` como versión de referencia al compilar sus smart contracts.
-You can read in more detail on Shanghai hard fork differences from London on the [Ethereum Execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) and how the new `PUSH0` instruction [impacts the Solidity compiler](https://blog.soliditylang.org/2023/05/10/solidity-0.8.20-release-announcement/).
+Puedes leer con más detalle las diferencias entre el hard fork de Shanghai y London en la [Ethereum Execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) y cómo la nueva instrucción `PUSH0` [afecta al compilador de Solidity](https://blog.soliditylang.org/2023/05/10/solidity-0.8.20-release-announcement/).
-## Transaction Fees
+## Comisiones de Transacciones
-The fee charged to Scroll Sepolia transactions contains two parts:
+La comisión aplicada a las transacciones de Scroll Sepolia consta de dos partes:
-- **L2 gas fee:** similar to L1, the amount of L2 execution fee equals to `L2_gas_price * L2_gas_used`, covering the following costs:
- - L2 sequencer execution & storage cost
- - Validity proof verification and finalization cost on L1
- - Prover cost
-- **L1 data fee:** additional fee on top of L2 gas fee. The L1 data fee is only charged to L2-initiated transactions, not to L1-initiated transactions. The fee covers the cost of sending data to L1 for data availability. Because we roll up the tx data to L1, the L1 rollup fee is calculated based on the size of tx data.
+- **Tasa de gas L2:** similar a L1, el importe de la comisión de ejecución L2 es igual a `L2_gas_price * L2_gas_used`, cubriendo los siguientes costes:
+ - Coste de ejecución y almacenamiento del secuenciador L2
+ - Coste de verificación y finalización de la prueba de validez en L1
+ - Coste del prover
+- **Tasa de datos L1:** tasa adicional sobre la tasa de gas L2. La tasa de datos L1 sólo se cobra a las transacciones iniciadas en L2, no a las iniciadas en L1. La tarifa cubre el coste del envío de datos a L1 para la disponibilidad de datos. Dado que los datos tx se transfieren a L1, la tasa de transferencia a L1 se calcula en función del tamaño de los datos tx.
-For more information, see [Transaction Fees on Scroll](/developers/transaction-fees-on-scroll).
+Para obtener más información, consulte [Comisiones de Transacciones en Scroll](/es/developers/transaction-fees-on-scroll).
---
diff --git a/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx b/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx
index 866bfe17f..df8430a79 100644
--- a/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx
+++ b/src/content/docs/es/developers/guides/bridge-erc20-through-the-custom-gateway.mdx
@@ -1,25 +1,24 @@
---
section: developers
date: Last Modified
-title: "Bridge ERC20 through the Custom Gateway"
-lang: "en"
+title: "Bridging de un ERC20 a través de una Gateway Personalizada"
+lang: "es"
permalink: "developers/guides/bridge-erc20-through-the-custom-gateway"
-excerpt: "This guide will walk through how to use Scroll's bridge for ERC20s that need custom functionality using the Custom Gateway."
+excerpt: "Esta guía explica cómo utilizar el bridge de Scroll para las ERC20 que necesitan funcionalidades personalizadas utilizando el Custom Gateway.."
---
import Aside from "../../../../../components/Aside.astro"
-This guide will walk through how to use Scroll's bridge for ERC20s that need custom functionality by using the Custom Gateway.
+En esta guía se explica cómo utilizar el bridge de Scroll para los ERC20 que necesitan una funcionalidad personalizada mediante el uso de una Gateway Personalizada.
-
- Remember, for many contexts, you won't need to use the Custom Gateway to add additional features to your token or to
- its bridging logic. See the article on [ETH and ERC20 Token
- Bridge](/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge#deposit-eth-and-erc20-tokens-from-l1) for more info.
+
+ Recuerde que, en muchos contextos, no necesitará utilizar la Gateway personalizada para añadir funciones adicionales a su token o a
+ su lógica de bridging. Consulte el artículo sobre [ETH y ERC20 Token Bridge](/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge#deposit-eth-and-erc20-tokens-from-l1) para más información.
-## Step 1: Launch a token on Sepolia
+## Paso 1: Lanza un token en Sepolia
-First, we need a token to bridge. There is no need for a particular ERC20 implementation in order for a token to be compatible with L2. If you already have a token, feel free to skip this step. If you want to deploy a new token, use the following contract of a simple ERC20 token that mints 1 million tokens to the deployer when launched.
+En primer lugar, necesitamos un token para hacer de bridge. No hay necesidad de una implementación ERC20 en particular para que un token sea compatible con L2. Si ya tienes un token, puedes saltarte este paso. Si desea desplegar un nuevo token, utilice el siguiente contrato de un token ERC20 que emite 1 millón de tokens al deployer cuando se lanza.
```solidity
// SPDX-License-Identifier: MIT
@@ -34,16 +33,16 @@ contract L1Token is ERC20 {
}
```
-## Step 2: Launch the counterpart token on Scroll Sepolia testnet
+## Paso 2: Lanzar el token contraparte en Scroll Sepolia testnet
-Next, launch you'll launch a counterpart to this token on Scroll, which will represent the original token on Sepolia. This token can implement custom logic to match that of the L1 token or even add additional features beyond those of the L1 token.
+A continuación, lanzarás un token homólogo a este token en Scroll, que representará al token original en Sepolia. Este token puede implementar una lógica personalizada para que coincida con la del token L1 o incluso añadir funciones adicionales más allá de las del token L1.
-For this to work:
+Para que funcione:
-- The token must implement the `IScrollStandardERC20`` interface in order to be compatible with the bridge.
-- The contract should provide the gateway address and the counterpart token addresses (the L1 token we just launched) under the `gateway()` and `counterpart()` functions. It should also allow the L2 gateway to call the token `mint()` and `burn()` functions, which are called when a token is deposited and withdrawn.
+- El token debe implementar la interfaz `IScrollStandardERC20`` para ser compatible con el bridge.
+- El contrato debe proporcionar la dirección de la gateway y las direcciones del token homólogo (el token L1 que acabamos de lanzar) bajo las funciones `gateway()` y `counterpart()`. También debe permitir que la gateway L2 llame a las funciones token `mint()` y `burn()`, que se llaman cuando se deposita y se retira un token.
-The following is a complete example of a token compatible with the bridge. To the constructor, you will pass the official Scroll Custom Gateway address (`0x31C994F2017E71b82fd4D8118F140c81215bbb37`) and the address of the token launched on Sepolia.
+A continuación se muestra un ejemplo completo de un token compatible con el bridge. Al constructor se le pasa la dirección oficial de la Gateway Personalizada de Scroll (`0x31C994F2017E71b82fd4D8118F140c81215bbb37`) y la dirección del token lanzado en Sepolia.
```solidity
// SPDX-License-Identifier: MIT
@@ -53,11 +52,11 @@ import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@scroll-tech/contracts@0.1.0/libraries/token/IScrollERC20Extension.sol";
contract L2Token is ERC20, IScrollERC20Extension {
- // We store the gateway and the L1 token address to provide the gateway() and counterpart() functions which are needed from the Scroll Standard ERC20 interface
+ // Almacenamos la gateway y la dirección del token L1 para proporcionar las funciones gateway() y counterpart() que se necesitan desde la interfaz Scroll Standard ERC20
address _gateway;
address _counterpart;
- // In the constructor we pass as parameter the Custom L2 Gateway and the L1 token address as parameters
+ // En el constructor pasaremos como parámetros la Gateway Personalizada L2 y como parámetros la dirección del token L1
constructor(address gateway_, address counterpart_) ERC20("My Token L2", "MTL2") {
_gateway = gateway_;
_counterpart = counterpart_;
@@ -71,19 +70,19 @@ contract L2Token is ERC20, IScrollERC20Extension {
return _counterpart;
}
- // We allow minting only to the Gateway so it can mint new tokens when bridged from L1
+ // Permitimos la emisión sólo a la Gateway para que pueda emitir nuevos tokens cuando se conecte desde L1.
function transferAndCall(address receiver, uint256 amount, bytes calldata data) external returns (bool success) {
transfer(receiver, amount);
data;
return true;
}
- // We allow minting only to the Gateway so it can mint new tokens when bridged from L1
+ // Permitimos la emisión sólo a la Gateway para que pueda emitir nuevos tokens cuando se conecte desde L1.
function mint(address _to, uint256 _amount) external onlyGateway {
_mint(_to, _amount);
}
- // Similarly to minting, the Gateway is able to burn tokens when bridged from L2 to L1
+ // Al igual que en la emisión, la Gateway puede quemar tokens al pasar de L2 a L1.
function burn(address _from, uint256 _amount) external onlyGateway {
_burn(_from, _amount);
}
@@ -95,30 +94,30 @@ contract L2Token is ERC20, IScrollERC20Extension {
}
```
-## Step 3: Add the token to the Scroll Bridge
+## Paso 3: Adición del token al Scroll Bridge
-You need to contact the Scroll team to add the token to `L2CustomERC20Gateway` contract in Scroll and `L1CustomERC20Gateway` contract in L1. In addition, follow the instructions on the [token lists](https://github.com/scroll-tech/token-list) repository to add your token to the Scroll official bridge frontend.
+Debe ponerse en contacto con el equipo de Scroll para añadir el token al contrato `L2CustomERC20Gateway` en Scroll y al contrato `L1CustomERC20Gateway` en L1. Además, siga las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir su token al frontend oficial del Scroll bridge.
-## Step 4: Deposit tokens
+## Paso 4: Depósito de tokens
-Once your token has been approved by the Scroll team, you should be able to deposit tokens from L1. To do so, you must first approve the `L1CustomGateway` contract address on Sepolia (`0x31C994F2017E71b82fd4D8118F140c81215bbb37`). Then, deposit tokens by calling the `depositERC20` function from the `L1CustomGateway` contract. This can be done using [our bridge UI](https://scroll.io/bridge), [Etherscan Sepolia](https://sepolia.etherscan.io/address/0x31C994F2017E71b82fd4D8118F140c81215bbb37#writeProxyContract), or a smart contract.
+Una vez que tu token haya sido aprobado por el equipo de Scroll, deberías poder depositar tokens desde L1. Para ello, primero debe aprobar la dirección del contrato `L1CustomGateway` en Sepolia (`0x31C994F2017E71b82fd4D8118F140c81215bbb37`). Luego, deposita los tokens llamando a la función `depositERC20` desde el contrato `L1CustomGateway`. Esto se puede hacer usando [nuestro bridge](https://scroll.io/bridge), [Etherscan Sepolia](https://sepolia.etherscan.io/address/0x31C994F2017E71b82fd4D8118F140c81215bbb37#writeProxyContract), o un smart contract.
-## Step 5: Withdraw tokens
+## Paso 5: Retiro de tokens
-You will follow similar steps to send tokens back from L2 to L1. First, approve the `L2CustomGateway` address (`0x058dec71E53079F9ED053F3a0bBca877F6f3eAcf`) and then withdraw the tokens calling the `withdrawERC20` from the `L2CustomGateway` contract.
+Deberá seguir pasos similares para enviar tokens de vuelta de L2 a L1. En primer lugar, apruebe la dirección `L2CustomGateway` (`0x058dec71E53079F9ED053F3a0bBca877F6f3eAcf`) y, después retire los tokens llamando al comando `withdrawERC20` del contrato `L2CustomGateway`.
-## Alternative Approach: Launch and set up a custom L1 gateway contract
+## Enfoque Alternativo: Lanzar y configurar un contrato de gateway personalizada L1
-Adding your token to the Scroll official bridge (as described above) is the recommended method of bridging tokens to and from Scroll. This approach will make them easier to discover and safer for holders. However, it will require approval from the Scroll team. If you want to launch a custom token without the official approval process, you can launch a custom gateway yourself. To do so, you will need to deploy an `L1CustomERC20Gateway` contract on L1 and an `L2CustomERC20Gateway` on L2.
+Añadir su token al bridge oficial de Scroll (como se ha descrito anteriormente) es el método recomendado para conectar tokens hacia y desde Scroll. Este método hará que sean más fáciles de descubrir y más seguros para los holders. Sin embargo, requerirá la aprobación del equipo de Scroll. Si desea lanzar un token personalizado sin el proceso de aprobación oficial, puede lanzar una gateway personalizada usted mismo. Para ello, tendrá que desplegar un contrato `L1CustomERC20Gateway` en L1 y un `L2CustomERC20Gateway` en L2.
-### Launch an L1 Custom Gateway
+### Lanzamiento de una Gateway Personalizada en L1
-Let’s start by launching the following contract on Sepolia.
+Empecemos lanzando el siguiente contrato en Sepolia.
```solidity
// SPDX-License-Identifier: MIT
-// Although it's possible to use other Solidity versions, we recommend using version 0.8.16 because that's where our contracts were audited
+// Aunque es posible utilizar otras versiones de Solidity, recomendamos utilizar la versión 0.8.16 porque es en la que se auditaron nuestros contratos
pragma solidity =0.8.16;
import "@openzeppelin/contracts/access/Ownable.sol";
@@ -130,28 +129,28 @@ import { IL1ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L1/gateways/IL1ERC
import { ScrollGatewayBase } from "@scroll-tech/contracts@0.1.0/libraries/gateway/ScrollGatewayBase.sol";
import { L1ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L1/gateways/L1ERC20Gateway.sol";
-// This contract will be used to send and receive tokens from L2
+// Este contrato se utilizará para enviar y recibir tokens de L2
contract L1CustomERC20Gateway is L1ERC20Gateway, Ownable {
- // Tokens must be mapped to "bind" them to a token that represents the original token on the original. This event will be emitted when the token mapping for ERC20 token is updated.
+ // Los tokens deben ser mapeados para "vincularlos" a un token que represente el token original en el original. Este evento se emitirá cuando se actualice el mapeado de tokens para tokens ERC20.
event UpdateTokenMapping(address indexed l1Token, address indexed oldL2Token, address indexed newL2Token);
mapping(address => address) public tokenMapping;
constructor() {}
- // This function must be called once after both the L1 and L2 contract was deployed
+ // Esta función debe llamarse una vez después de haber desplegado el contrato L1 y L2
function initialize(address _counterpart, address _router, address _messenger) external {
require(_router != address(0), "zero router address");
ScrollGatewayBase._initialize(_counterpart, _router, _messenger);
}
- /// This function returns the address of the token on L2
+ /// Esta función devuelve la dirección del token en L2
function getL2ERC20Address(address _l1Token) public view override returns (address) {
return tokenMapping[_l1Token];
}
- // Updates the token mapping that "binds" a token with another one on the other chain
+ // Actualiza el mapeo de tokens que "vincula" un token con otro de la otra cadena.
function updateTokenMapping(address _l1Token, address _l2Token) external onlyOwner {
require(_l2Token != address(0), "token address cannot be 0");
@@ -161,7 +160,7 @@ contract L1CustomERC20Gateway is L1ERC20Gateway, Ownable {
emit UpdateTokenMapping(_l1Token, _oldL2Token, _l2Token);
}
- // Callback called before a token is withdrawn on L1
+ // Callback antes de retirar un token en L1
function _beforeFinalizeWithdrawERC20(
address _l1Token,
address _l2Token,
@@ -175,12 +174,12 @@ contract L1CustomERC20Gateway is L1ERC20Gateway, Ownable {
require(_l2Token == tokenMapping[_l1Token], "l2 token mismatch");
}
- // Token bridged can be "canceled" or dropped. This callback is called before that happens.
+ // Los tokens que han sido transferidos pueden ser "cancelados" o anulados. Esta callback es llamada antes de que eso ocurra.
function _beforeDropMessage(address, address, uint256) internal virtual override {
require(msg.value == 0, "nonzero msg.value");
}
- // Internal function holding the deposit logic
+ // Función interna que mantiene la lógica del depósito
function _deposit(
address _token,
address _to,
@@ -191,17 +190,17 @@ contract L1CustomERC20Gateway is L1ERC20Gateway, Ownable {
address _l2Token = tokenMapping[_token];
require(_l2Token != address(0), "no corresponding l2 token");
- // 1. Transfer token into this contract.
+ // 1. Transfiere el token a este contrato.
address _from;
(_from, _amount, _data) = _transferERC20In(_token, _amount, _data);
- // 2. Generate message passed to L2CustomERC20Gateway.
+ // 2. Genera el mensaje pasado a L2CustomERC20Gateway.
bytes memory _message = abi.encodeCall(
IL2ERC20Gateway.finalizeDepositERC20,
(_token, _l2Token, _from, _to, _amount, _data)
);
- // 3. Send message to L1ScrollMessenger.
+ // 3. Envía el mensaje a L1ScrollMessenger.
IL1ScrollMessenger(messenger).sendMessage{ value: msg.value }(counterpart, 0, _message, _gasLimit, _from);
emit DepositERC20(_token, _l2Token, _from, _to, _amount, _data);
@@ -209,9 +208,9 @@ contract L1CustomERC20Gateway is L1ERC20Gateway, Ownable {
}
```
-### Launch an L2 Custom Gateway
+### Lanzamiento de una Gateway personalizada en L2
-Now let’s launch the counterpart contract on Scroll.
+Ahora vamos a lanzar el contrato homólogo en Scroll.
```solidity
// SPDX-License-Identifier: MIT
@@ -228,7 +227,7 @@ import "@scroll-tech/contracts@0.1.0/libraries/token/IScrollERC20Extension.sol";
import { IL2ERC20Gateway } from "@scroll-tech/contracts@0.1.0/L2/gateways/IL2ERC20Gateway.sol";
-// This contract will be used to send and receive tokens from L1
+// Este contrato se utilizará para enviar y recibir tokens de L1
contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
event UpdateTokenMapping(address indexed l2Token, address indexed oldL1Token, address indexed newL1Token);
@@ -237,24 +236,24 @@ contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
constructor() {}
- // Like with the L1 version of the Gateway, this must be called once after both the L1 and L2 gateways are deployed
+ // Al igual que con la versión L1 de la Gateway, debe ejecutarse una vez que se hayan desplegado las gateways en L1 y L2.
function initialize(address _counterpart, address _router, address _messenger) external {
require(_router != address(0), "zero router address");
ScrollGatewayBase._initialize(_counterpart, _router, _messenger);
}
- /// Returns the address of the token representing the token on L2
+ /// Devuelve la dirección del token que representa el token en L2
function getL1ERC20Address(address _l2Token) external view override returns (address) {
return tokenMapping[_l2Token];
}
- // This returns the L2 token address
+ // Esto devuelve la dirección del token L2
function getL2ERC20Address(address) public pure override returns (address) {
revert("unimplemented");
}
- // This function finalizes the token deposit on L2 when the deposit was not finalized due to not enough gas sent from L1
+ // Esta función finaliza el depósito de tokens en L2 cuando el depósito no se ha finalizado debido a que no se ha enviado suficiente gas desde L1.
function finalizeDepositERC20(
address _l1Token,
address _l2Token,
@@ -274,7 +273,7 @@ contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
emit FinalizeDepositERC20(_l1Token, _l2Token, _from, _to, _amount, _data);
}
- // Same as in the L1 version of this contract, this function "binds" a token with a token on the other chain
+ // Igual que en la versión L1 de este contrato, esta función "vincula" un token con otro token de la otra cadena.
function updateTokenMapping(address _l2Token, address _l1Token) external onlyOwner {
require(_l1Token != address(0), "token address cannot be 0");
@@ -284,7 +283,7 @@ contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
emit UpdateTokenMapping(_l2Token, _oldL1Token, _l1Token);
}
- // Internal function holding the withdraw logic
+ // Función interna que mantiene la lógica de retirada
function _withdraw(
address _token,
address _to,
@@ -297,22 +296,22 @@ contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
require(_amount > 0, "withdraw zero amount");
- // 1. Extract real sender if this call is from L2GatewayRouter.
+ // 1. Extrae el remitente real si esta llamada es desde L2GatewayRouter.
address _from = msg.sender;
if (router == msg.sender) {
(_from, _data) = abi.decode(_data, (address, bytes));
}
- // 2. Burn token.
+ // 2. Quema los tokens
IScrollERC20Extension(_token).burn(_from, _amount);
- // 3. Generate message passed to L1StandardERC20Gateway.
+ // 3. Genera el mensaje pasado a L1StandardERC20Gateway.
bytes memory _message = abi.encodeCall(
IL1ERC20Gateway.finalizeWithdrawERC20,
(_l1Token, _token, _from, _to, _amount, _data)
);
- // 4. send message to L2ScrollMessenger
+ // 4. Envía el mensaje a L2ScrollMessenger
IL2ScrollMessenger(messenger).sendMessage{ value: msg.value }(counterpart, 0, _message, _gasLimit);
emit WithdrawERC20(_l1Token, _token, _from, _to, _amount, _data);
@@ -320,36 +319,36 @@ contract L2CustomERC20Gateway is L2ERC20Gateway, ScrollGatewayBase, Ownable {
}
```
-### Setup your Gateway contract on Sepolia
+### Configure su contrato Gateway en Sepolia
-Once the contracts are deployed, call the following functions to initialize the contracts and bind them to the corresponding tokens and the gateway on the other side of the bridge.
+Una vez desplegados los contratos, llama a las siguientes funciones para inicializar los contratos y vincularlos a los tokens correspondientes y a la gateway al otro lado del bridge.
-First, call the `initialize` function on the `MyL1Gateway` contract with the following parameters:
+Primero, llama a la función `initialize` en el contrato `MyL1Gateway` con los siguientes parámetros:
-- `_counterpart`: The address of `MyL2Gateway` we just launched on Scroll.
-- `_router`: Set it to `0x13FBE0D0e5552b8c9c4AE9e2435F38f37355998a`, the `L1GatewayRouter` contract on Sepolia.
-- `_messenger`: Set it to `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`, the `L1ScrollMessenger` contract on Sepolia.
+- `_counterpart`: La dirección de `MyL2Gateway` que acabamos de lanzar en Scroll.
+- `_router`: Ponlo en `0x13FBE0D0e5552b8c9c4AE9e2435F38f37355998a`, el contrato `L1GatewayRouter` de Sepolia.
+- `_messenger`: Ponlo en `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`, el contrato `L1ScrollMessenger` de Sepolia.
-A custom gateway can host multiple token bridges. In this case, we will only be allowing bridging between L1Token and L2Token by calling the `updateTokenMapping` function on the `MyL1Gateway` contract with the following parameters:
+Una gateway personalizada puede alojar múltiples bridges de tokens. En este caso, sólo permitiremos el bridging entre L1Token y L2Token llamando a la función `updateTokenMapping` en el contrato `MyL1Gateway` con los siguientes parámetros:
-- `_l1Token`: The address of the `L1Token` contract we previously launched on Sepolia.
-- `_l2Token`: The address of the `L2Token` contract we previously launched on Scroll.
+- `_l1Token`: La dirección del contrato `L1Token` que lanzamos previamente en Sepolia.
+- `_l2Token`: La dirección del contrato `L2Token` que lanzamos previamente en Scroll.
-### Setup your Gateway contract on Scroll
+### Configura tu contrato Gateway en Scroll
-Now let’s switch to the Scroll chain and initialize `MyL2Gateway`, following similar steps.
+Ahora cambiemos a la cadena Scroll e inicialicemos `MyL2Gateway`, siguiendo pasos similares.
-First, call the `initialize` function from `MyL2Gateway`:
+Primero, llama a la función `initialize` de `MyL2Gateway`:
-- `_counterpart`: The address of `MyL1Gateway` we just launched on Sepolia.
-- `_router`: Set it to `0x9aD3c5617eCAa556d6E166787A97081907171230`, the `L2GatewayRouter` contract on Scroll.
-- `_messenger`: Set it `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`, the `L2ScrollMessenger` contract on Scroll.
+- `_counterpart`: La dirección de `MyL1Gateway` que acabamos de lanzar en Sepolia.
+- `_router`: Ponlo en `0x9aD3c5617eCAa556d6E166787A97081907171230`, el contrato `L2GatewayRouter` de Scroll.
+- `_messenger`: Ponle `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`, el contrato `L2ScrollMessenger` de Scroll.
-Next, call `updateTokenMapping` on the `MyL2Gateway` contract:
+A continuación, llama a `updateTokenMapping` en el contrato `MyL2Gateway`:
-- `_l2Token`: The address of the `L2Token` contract we previously launched on Scroll.
-- `_l1Token`: The address of the `L1Token` contract we previously launched on Sepolia.
+- `_l2Token`: La dirección del contrato `L2Token` que lanzamos previamente en Scroll.
+- `_l1Token`: La dirección del contrato `L1Token` que lanzamos previamente en Sepolia.
-### Bridging tokens
+### Bridging de tokens
-We can now call `depositERC20` from `MyL1Gateway` and `withdrawERC20` from `MyL2Gateway` just as with the official Scroll bridge.
+Ahora podemos llamar a `depositERC20` desde `MyL1Gateway` y a `withdrawERC20` desde `MyL2Gateway` igual que con el bridge oficial de Scroll.
diff --git a/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx b/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx
index f222c6071..b92d5e245 100644
--- a/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx
+++ b/src/content/docs/es/developers/guides/contract-deployment-tutorial.mdx
@@ -1,28 +1,28 @@
---
section: developers
date: Last Modified
-title: "Contract Deployment Tutorial"
-lang: "en"
+title: "Tutorial de Despliegue de Contratos"
+lang: "es"
permalink: "developers/guides/contract-deployment-tutorial"
-excerpt: "The Scroll Sepolia Testnet allows the community to deploy smart contracts on Scroll. In this tutorial, we will teach you how to deploy a contract on Scroll Sepolia."
-whatsnext: { "Contract Deployment Tutorial": "/developers/developer-quickstart/" }
+excerpt: "La Testnet de Scroll Sepolia permite a la comunidad desplegar smart contracts en Scroll. En este tutorial, te enseñaremos a desplegar un contrato en Scroll Sepolia."
+whatsnext: { "Interacción Cross-chain del Scroll Messenger": "/es/developers/guides/scroll-messenger-cross-chain-interaction" }
---
import Aside from "../../../../../components/Aside.astro"
-The Scroll Sepolia Testnet allows anyone to deploy a smart contract on Scroll. In this tutorial, you will learn how to deploy a contract on Scroll Sepolia using common tools for developing on Ethereum. This [demo repo](https://github.com/scroll-tech/scroll-guides/tree/main/contract-deploy-demo) illustrates contract deployment with [Hardhat](https://hardhat.org/) and [Foundry](https://github.com/foundry-rs/foundry).
+La Testnet de Scroll Sepolia permite a cualquiera desplegar un smart contract en Scroll. En este tutorial, aprenderás a desplegar un contrato en Scroll Sepolia utilizando herramientas comunes para desarrollar en Ethereum. Este [demo repo](https://github.com/scroll-tech/scroll-guides/tree/main/contract-deploy-demo) ilustra el despliegue de contratos con [Hardhat](https://hardhat.org/) y [Foundry](https://github.com/foundry-rs/foundry).
-
- Before you start deploying the contract, you need to request test tokens from a Sepolia faucet and use the
- [bridge](https://scroll.io/bridge) to transfer some test ETH from _Sepolia_ to _Scroll Sepolia_. Alternatively, you
- could acquire Scroll Sepolia ETH directly. See our [Faucet](/user-guide/faucet/) and [Bridge](/user-guide/bridge/)
- guides for help.
+
+ Antes de empezar a desplegar el contrato, tienes que solicitar tokens de la testnet a través de un faucet de Sepolia y utilizar la función
+[bridge](https://scroll.io/bridge) para transferir algunos ETH de prueba de _Sepolia_ a _Scroll Sepolia_. Como alternativa
+ adquirir directamente ETH de Scroll Sepolia. Consulta nuestras guías [Faucet](/es/user-guide/faucet/) y [Bridge](/es/user-guide/bridge/)
+ para obtener ayuda.
-## Deploy contracts with Hardhat
+## Despliegue de contratos con Hardhat
-1. If you haven't already, install [nodejs](https://nodejs.org/en/download/) and [yarn](https://classic.yarnpkg.com/lang/en/docs/install).
-2. Clone the repo and install dependencies:
+1. Si aún no lo ha hecho, instale [nodejs](https://nodejs.org/en/download/) y [yarn](https://classic.yarnpkg.com/lang/en/docs/install).
+2. Clona el repositorio e instala las dependencias:
```shell
git clone https://github.com/scroll-tech/scroll-guides.git
@@ -30,33 +30,33 @@ The Scroll Sepolia Testnet allows anyone to deploy a smart contract on Scroll. I
yarn install
```
-3. Create a `.env` file following the example `.env.example` in the root directory. Change `PRIVATE_KEY` to your own account private key in the `.env`.
+3. Crea un archivo `.env` siguiendo el ejemplo `.env.example` en el directorio raíz. Cambia `PRIVATE_KEY` por la clave privada de tu propia cuenta en el `.env`.
-4. Run `yarn compile` to compile the contract.
+4. Ejecuta `yarn compile` para compilar el contrato.
-5. Run `yarn deploy:scrollTestnet` to deploy the contract on the Scroll Sepolia Testnet.
+5. Ejecuta `yarn deploy:scrollTestnet` para desplegar el contrato en la Scroll Sepolia Testnet.
-6. Run `yarn test` for hardhat tests.
+6. Ejecuta `yarn test` para realizar las pruebas hardhat.
-## Deploy contracts with Foundry
+## Despliegue de contratos con Foundry
-1. Clone the repo:
+1. Clona el repositorio:
```shell
git clone https://github.com/scroll-tech/scroll-guides.git
cd scroll-guides/contract-deploy-demo
```
-2. Install Foundry:
+2. Instala el Foundry:
```shell
curl -L https://foundry.paradigm.xyz | bash
foundryup
```
-3. Run `forge build` to build the project.
+3. Ejecuta `forge build` para construir el proyecto.
-4. Deploy your contract with Foundry:
+4. Despliega tu contrato con Foundry:
```bash
forge create --rpc-url https://sepolia-rpc.scroll.io/ \
@@ -67,10 +67,10 @@ The Scroll Sepolia Testnet allows anyone to deploy a smart contract on Scroll. I
contracts/Lock.sol:Lock
```
- - `` is the amount of test `ETH` to be locked in the contract. Try setting this to some small amount, like `0.0000001ether`.
- - `` is the Unix timestamp after which the funds locked in the contract will become available for withdrawal. Try setting this to some Unix timestamp in the future, like `1696118400` (this Unix timestamp corresponds to October 1, 2023).
+ - `` es la cantidad de `ETH` de prueba que se bloqueará en el contrato. Intente establecer una cantidad pequeña, como `0.0000001ether`.
+ - `` es la marca de tiempo Unix después de la cual los fondos bloqueados en el contrato estarán disponibles para su retirada. Intenta ponerlo en algún timestamp Unix en el futuro, como `1696118400` (este timestamp Unix corresponde al 1 de Octubre de 2023).
- For example:
+ Por ejemplo:
```bash
forge create --rpc-url https://sepolia-rpc.scroll.io/ \
@@ -80,6 +80,6 @@ The Scroll Sepolia Testnet allows anyone to deploy a smart contract on Scroll. I
--legacy contracts/Lock.sol:Lock
```
-## Questions and Feedback
+## Preguntas y Feedback
-Thank you for participating in and developing on the Scroll Sepolia Testnet! If you encounter any issues, join our [Discord](https://discord.gg/scroll) and ask us in the `#testnet-devs` channel.
+Gracias por participar y desarrollar en la Scroll Sepolia Testnet. Si tienes algún problema, únete a nuestro [Discord](https://discord.gg/scroll) y pregúntanos en el canal `#testnet-devs`.
diff --git a/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx b/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
index 2793510e2..13791c65c 100644
--- a/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
+++ b/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
@@ -1,58 +1,58 @@
---
section: developers
date: Last Modified
-title: "Scroll Messenger Cross-chain Interaction"
-lang: "en"
+title: "Interacción Cross-chain del Scroll Messenger"
+lang: "es"
permalink: "developers/guides/scroll-messenger-cross-chain-interaction"
-excerpt: "In this example, we will launch a dummy smart contract on either Sepolia or Scroll Sepolia testnet and interact with it from the opposite chain."
+excerpt: "En este ejemplo, lanzaremos un smart contract ficticio en Sepolia o en Scroll Sepolia testnet e interactuaremos con él desde la cadena opuesta."
+whatsnext: { "Bridging de un ERC20 a través de una Gateway Personalizada": "/es/developers/guides/bridge-erc20-through-the-custom-gateway" }
---
import Aside from "../../../../../components/Aside.astro"
-In this example, we will launch a dummy smart contract on either Sepolia or Scroll and interact
-with it from the opposite chain. We will be using the `ScrollMessenger` that is deployed on both
-Sepolia and Scroll.
+En este ejemplo, lanzaremos un smart contract ficticio en Sepolia o Scroll e interactuaremos con él desde la cadena opuesta. Utilizaremos el `ScrollMessenger` que está desplegado tanto en
+Sepolia como en Scroll.
-## Deploying the Contracts
+## Despliegue de los contratos
-### Target Smart Contract
+### Smart Contract de Destino
-Let’s start by deploying the target smart contract. We will use the Greeter contract for this
-example, but you can use any other contract. Deploy it to either Sepolia or Scroll. On Scroll, L1
-and L2 use the same API, so it’s up to you.
+Empecemos por desplegar el smart contract de destino. Usaremos el contrato Greeter para este
+ejemplo, pero puedes usar cualquier otro contrato. Despliégalo en Sepolia o en Scroll. En Scroll, L1
+y L2 usan la misma API, así que depende de ti.
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.16;
-// This Greeter contract will be interacted with through the ScrollMessenger across the bridge
+// Este contrato Greeter interactuará con el ScrollMessenger a través del bridge
contract Greeter {
string public greeting = "Hello World!";
- // This function will be called by executeFunctionCrosschain on the Operator Smart Contract
+ // Esta función será llamada por executeFunctionCrosschain en el Operador de Smart Contract
function setGreeting(string memory greeting_) public {
greeting = greeting_;
}
}
```
-We will now execute `setGreeting` in a cross-chain way.
+Ahora ejecutaremos `setGreeting` de forma cross-chain.
-### Operator Smart Contract
+### Operador de Smart Contract
-Switch to the other chain and deploy the `GreeterOperator`. So, if you deployed the `Greeter` contract on L1, deploy the `GreeterOperator` on L2 or vice versa.
+Cambia a la otra cadena y despliega el `GreeterOperator`. Así, si desplegaste el contrato `Greeter` en L1, despliega el `GreeterOperator` en L2 o viceversa.
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.16;
-// The Scroll Messenger interface is the same on both L1 and L2, it allows sending cross-chain transactions
-// Let's import it directly from the Scroll Contracts library
+// La interfaz de Scroll Messenger es la misma tanto en L1 como en L2, permite enviar transacciones entre cadenas
+// Importémoslo directamente de la librería Scroll Contracts
import "@scroll-tech/contracts@0.1.0/libraries/IScrollMessenger.sol";
-// The GreeterOperator is capable of executing the Greeter function through the bridge
+// El GreeterOperator es capaz de ejecutar la función Greeter a través del bridge
contract GreeterOperator {
- // This function will execute setGreeting on the Greeter contract
+ // Esta función ejecutará setGreeting en el contrato Greeter
function executeFunctionCrosschain(
address scrollMessengerAddress,
address targetAddress,
@@ -61,7 +61,7 @@ contract GreeterOperator {
uint32 gasLimit
) public payable {
IScrollMessenger scrollMessenger = IScrollMessenger(scrollMessengerAddress);
- // sendMessage is able to execute any function by encoding the abi using the encodeWithSignature function
+ // sendMessage es capaz de ejecutar cualquier función codificando el abi mediante la función encodeWithSignature
scrollMessenger.sendMessage{ value: msg.value }(
targetAddress,
value,
@@ -73,49 +73,48 @@ contract GreeterOperator {
}
```
-## Calling a Cross-chain Function
+## Llamada a una función Cross-Chain
-We pass the message by executing `executeFunctionCrosschain` and passing the following parameters:
+Pasamos el mensaje ejecutando `executeFunctionCrosschain` y pasando los siguientes parámetros:
-- `scrollMessengerAddress`: This will depend on where you deployed the `GreeterOperator` contract.
- - If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
-- `targetAddress`: The address of the `Greeter` contract on the opposite chain.
-- `value`: In this case, it is `0` because the `setGreeting`is not payable.
-- `greeting`: This is the parameter that will be sent through the message. Try passing `“This message was crosschain!”`
+- 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`.
+- `targetAddress`: La dirección del contrato `Greeter` en la cadena opuesta.
+- `value`: En este caso es `0` porque el `setGreeting` no es pagable.
+- `greeting`: Es el parámetro que se enviará a través del mensaje. Prueba a pasar `"¡Este mensaje fue crosschain!"`.
- `gasLimit`:
- - If you are sending the message from L1 to L2, around `5000` gas limit should be more than enough.
- - If you are sending the message from L2 to L1, pass `0`, as the transaction be completed by executing an additional transaction on L1.
+ - Si estás enviando el mensaje de L1 a L2, alrededor de `5000` límite de gas debería ser más que suficiente.
+ - 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.
-### Relay the Message when sending from L2 to L1
+### Retransmisión del mensaje al enviar de L2 a L1
-When a transaction is passed from L2 to L1, an additional "execute withdrawal transaction" must be sent on L1. To do this, you must call `relayMessageWithProof` on the L1 Scroll Messenger
-contract from an EOA wallet.
+Cuando se pasa una transacción de L2 a L1, se debe enviar un "ejecutar transacción de retirada" adicional en L1. Para ello, debe llamar a `relayMessageWithProof` en el contrato L1 Scroll Messenger
+desde un wallet EOA.
-You can do this directly on [Etherscan Sepolia](https://sepolia.etherscan.io/address/0x50c7d3e7f7c656493d1d76aaa1a836cedfcbb16a#writeProxyContract#F3).
-To do so, you will need to pass a Merkle inclusion proof for the bridged transaction and other parameters. You'll query these using the Scroll Bridge API.
+Puedes hacerlo directamente en [Etherscan Sepolia](https://sepolia.etherscan.io/address/0x50c7d3e7f7c656493d1d76aaa1a836cedfcbb16a#writeProxyContract#F3).
+Para ello, necesitarás pasar una prueba de inclusión Merkle para la transacción puenteada y otros parámetros. Los consultará utilizando la API de Scroll Bridge.
{/* TODO: finish looking into API issues */}
-We're finalizing the API specifics, but for now, fetch or curl the following endpoint:
+Estamos ultimando los detalles de la API, pero por ahora, obtenga o curl el siguiente endpoint:
```bash
curl "https://sepolia-api-bridge.scroll.io/api/claimable?page_size=10&page=1&address=GREETER_OPERATOR_ADDRESS_ON_L2"
```
-Replace `GREETER_OPERATOR_ADDRESS_ON_L2` with your GreeterOperator contract address as launched on L2. Read more about Execute Withdraw transactions
-in the [Scroll Messenger](/developers/l1-and-l2-bridging/the-scroll-messenger) article.
+Sustituya `GREETER_OPERATOR_ADDRESS_ON_L2` por la dirección de su contrato GreeterOperator tal y como se lanza en L2. Puedes leer más información sobre Ejecutar transacciones de retirada de fondos
+en el artículo [el Scroll Messenger](/es/developers/l1-and-l2-bridging/the-scroll-messenger).
-
- This API was made for our Bridge UI. It is not yet finalized and may change in the future. We will update this guide
- when the API is finalized.
+
+ Esta API se ha creado para nuestra IU del Bridge. Aún no está finalizada y puede cambiar en el futuro. Actualizaremos esta guía
+ cuando la API esté finalizada.
-
- `relayMessageWithProof` is fully permissionless, so anyone can call it on your behalf if they're willing to pay the L1
- gas fees. This feature allows for additional support infrastructure, including tooling to automate this process for
- applications and users.
+
+ `relayMessageWithProof` es totalmente permissionless, por lo que cualquiera puede llamarlo en su nombre si están dispuestos a pagar el gas de L1. Esta característica permite una infraestructura de soporte adicional, incluidas herramientas para automatizar este proceso para
+ aplicaciones y usuarios.
-After executing and confirming the transaction on both L1 and L2, the new state of `greeting` on the `Greeter` contract should be `“This message was crosschain!”`. Sending a message from one chain to the other should take around 20 minutes after the transactions are confirmed on the origin chain.
+Tras ejecutar y confirmar la transacción tanto en L1 como en L2, el nuevo estado de `greeting` en el contrato `Greeter` debería ser `"¡Este mensaje era crosschain!"`. Enviar un mensaje de una cadena a la otra debería llevar unos 20 minutos después de que se confirmen las transacciones en la cadena de origen.
-Congratulations, you now executed a transaction from one chain to the other using our native bridge!
+Felicitaciones, ¡ya has ejecutado una transacción de una cadena a la otra utilizando nuestro bridge nativo!
diff --git a/src/content/docs/es/developers/index.mdx b/src/content/docs/es/developers/index.mdx
index 5df63925e..05585a7c4 100644
--- a/src/content/docs/es/developers/index.mdx
+++ b/src/content/docs/es/developers/index.mdx
@@ -1,91 +1,94 @@
---
section: developers
date: Last Modified
-title: "Building on Scroll"
-lang: "en"
+title: "Construyendo en Scroll"
+lang: "es"
permalink: "developers/"
-excerpt: "Building on Scroll feels just like Ethereum, and you can bring your favorite tooling and contracts with you."
-whatsnext: { "Developer Quickstart": "/developers/developer-quickstart" }
+excerpt: "Construir en Scroll se siente igual que en Ethereum, y puedes llevar contigo tus herramientas y contratos favoritos."
+whatsnext: { "Inicio rápido para desarrolladores": "/es/developers/developer-quickstart" }
---
import Aside from "../../../../components/Aside.astro"
import ToggleElement from "../../../../components/ToggleElement.astro"
-**Welcome to the Scroll developer documentation!**
+**Bienvenido a la documentación para desarrolladores de Scroll!**
-Scroll is its own Layer 2 network built on Ethereum (more specifically, a “zero-knowledge rollup”).
+Scroll es su propia red de capa 2 construida sobre Ethereum (más concretamente, un "zero-knowledge rollup").
-If you’re experienced in building on Ethereum, your code, dependencies, and tooling work with Scroll out of the box. This is possible because our network is compatible with EVM bytecode and designed to feel just like developing on Ethereum.
+Si tienes experiencia en el desarrollo en Ethereum, su código, dependencias y herramientas funcionarán con Scroll desde el primer momento.
-
-Scroll gains its security and speed by executing transactions off-chain, and also producing a cryptographic proof that
-the transactions were executed correctly. This cryptographic proof is verified in a smart contract on Layer 1,
-ensuring that all code executed on the Scroll Layer 2 behaves just as if it were executed on Ethereum Layer 1.
+Esto es posible porque nuestra red es compatible con el bytecode de EVM y está diseñada para que se sienta igual que desarrollar en Ethereum.
-[Learn more about Scroll’s architecture →](/technology)
+
+Scroll obtiene su seguridad y velocidad ejecutando transacciones fuera de la cadena, y produciendo también una prueba criptográfica que demuestra que las transacciones
+se ejecutaron correctamente. Esta prueba criptográfica se verifica en un smart contract en la Capa 1, asegurando que todo el código ejecutado en la Capa 2 de Scroll se
+comporta como si fuera ejecutado en la Capa 1 de Ethereum.
+
+[Aprende más sobre la arquitectura de Scroll→](/es/technology)
-## Getting Started
+## Primeros Pasos
-**Looking to build on the Scroll Sepolia Testnet?**
+**¿Desea desarrollar en Scroll Sepolia Testnet?**
-- For the essentials: Check out the [Developer Quickstart](/developers/developer-quickstart)
-- For a tutorial walking through deploying your first smart contract on Scroll, read our [contract deployment tutorial](/developers/guides/contract-deployment-tutorial)
-- We also have a number of [deployed contract addresses](/developers/scroll-contracts) to build on.
+- Para lo esencial: Consulta el [Inicio rápido para desarrolladores](/es/developers/developer-quickstart)
+- Para un tutorial sobre el despliegue de su primer smart contract en Scroll, lea nuestro
+[tutorial de despliegue de contratos](/es/developers/guides/contract-deployment-tutorial)
+- También tenemos varias [direcciones de contratos desplegados](/es/developers/scroll-contracts) para poder utilizar.
-## Why Build on Scroll?
+## ¿Por qué Construir en Scroll?
- Throughput — Scroll creates more secure blockspace for Ethereum.
+ Rendimiento - Scroll crea un espacio de bloques más seguro para Ethereum.
- ZK Rollups allow for more activity on the network, minimizing congestion. By inheriting the security of Ethereum,
- which verifies the behavior of the network using zero-knowledge proofs, Scroll can process more transactions without
- compromising on decentralization.
+ Los Rollups ZK permiten una mayor actividad en la red, minimizando la congestión. Al heredar la seguridad de Ethereum,
+ que verifica el comportamiento de la red utilizando zero-knowledge proofs, Scroll puede procesar más transacciones sin comprometer la descentralización.
- Cost — Scroll saves users gas fees.
+ Coste - Scroll ahorra a los usuarios los gastos de gas.
- On Ethereum, competition for blockspace results in higher costs per transaction, as each transaction makes a bid to
- be included in the next block. Scroll leverages recent breakthroughs in zero-knowledge proofs and hardware
- acceleration to vastly increase secure blockspace and minimize transaction costs for users.
+ En Ethereum, la competencia por el espacio de bloque se traduce en mayores costes por transacción, ya que cada
+ transacción hace una oferta para ser incluida en el siguiente bloque. Scroll aprovecha los recientes avances en
+ zero-knowledge proofs y aceleración de hardware para aumentar enormemente la seguridad del espacio de bloque y minimizar
+ los costes de transacción para los usuarios.
- Speed — Scroll delivers feedback to users, faster.
+ Velocidad - Scroll proporciona información a los usuarios con mayor rapidez.
- After the merge, Ethereum blocks reliably confirm every 12 seconds. Scroll blocks are minted every 3 seconds, and
- for the sake of lower-risk operations, transactions can be assumed to be final once included in a block. This opens
- up new possibilities for on-chain interaction in social and gaming applications.
+ Tras el merge, los bloques de Ethereum se confirman de forma fiable cada 12 segundos. Los bloques de Scroll se mintean cada 3 segundos, y
+ en favor de las operaciones de menor riesgo, se puede suponer que las transacciones son definitivas una vez incluidas en un bloque.
+ Esto abre nuevas posibilidades para la interacción en la cadena en aplicaciones sociales y de juegos.
- Alignment — Scroll builds on Ethereum's vision.
+ Alineamiento - Scroll se basa en la visión de Ethereum.
- Scroll builds on Ethereum’s vision. Our ethos is to build Ethereum, not to splinter it. Decentralization,
- permissionlessness, censorship-resistance, and community ownership are the core of what we do and the roadmap we’re
- building. We believe in open-source software, and we work closely with the Ethereum Foundation’s Privacy and Scaling
- Explorations team to support their work on a zkEVM that might someday be the heart of Ethereum.
+ Scroll se basa en la visión de Ethereum. Nuestra filosofía es construir Ethereum, no fragmentarlo. La descentralización,
+ el ideal permissionless, la resistencia a la censura, y la propiedad de la comunidad son el núcleo de lo que hacemos y
+ la hoja de ruta que estamos construyendo. Creemos en el software de código abierto y colaboramos estrechamente con el
+ equipo Privacy and Scaling Explorations de la Fundación Ethereum para apoyar su trabajo en un zkEVM que algún día podría ser el corazón de Ethereum.
- We also work with governance DAOs and other open-source protocols to make sure that as applications are deployed,
- we’re working to grow their impact — whether that be in public goods, core infrastructure, or the next generation of
- zero-knowledge use cases.
+ También trabajamos con DAOs de gobernanza y otros protocolos de código abierto para asegurarnos de que, a medida que se despliegan las aplicaciones,
+ trabajamos para aumentar su impacto, ya sea en bienes públicos, infraestructura básica o la próxima generación de casos de uso de zero-knowledge.
- Community — Scroll brings together users and builders.
+ Comunidad - Scroll reúne a usuarios y builders.
- We know the challenges of building in the open and getting user engagement before mainnet release! Scroll has a
- blossoming community of users and builders, and with a Discord community of over 100,000 users eager to try out
- applications on our testnet, we’re excited to connect builders with users that can provide real-world feedback.
+ Conocemos los retos de construir en abierto y conseguir la participación de los usuarios antes del lanzamiento de la mainnet.
+ Scroll cuenta con una comunidad de Discord de más de 100.000 usuarios deseosos de probar aplicaciones en nuestra testnet.
+ Estamos encantados de poner en contacto a los creadores con usuarios que puedan aportar feedback del mundo real.
-## Thank you for building with us.
+## Gracias por construir con nosotros
-We’re working to bring more integrations and support infrastructure to the network, and are excitedly working towards our Mainnet release.
+Estamos trabajando para traer más integraciones e infraestructura de apoyo a la red, y estamos trabajando con entusiasmo hacia el lanzamiento de nuestra Mainnet.
-Join our growing developer community. You can find us on [Discord](https://discord.gg/scroll), join our [discussion forum](https://community.scroll.io/), or follow our progress on [Twitter](https://twitter.com/Scroll_ZKP).
+Únete a nuestra creciente comunidad de desarrolladores. Puedes encontrarnos en [Discord](https://discord.gg/scroll),
+unirte a nuestro [foro de debate](https://community.scroll.io/) o seguir nuestros progresos en [Twitter](https://twitter.com/Scroll_ZKP).
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging.mdx b/src/content/docs/es/developers/l1-and-l2-bridging.mdx
index e5555ad54..8a44c5cf1 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging.mdx
@@ -4,23 +4,32 @@ date: Last Modified
title: "L1 y L2 Bridging"
lang: "es"
permalink: "developers/l1-and-l2-bridging"
-excerpt: "An overview of Scroll's Bridging architecture"
+whatsnext: { "ETH y ERC20 Token Bridge": "/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge" }
+excerpt: "Visión general de la arquitectura de puentes de Scroll"
---
-The Scroll bridge enables the transfer of ETH, ERC20 tokens, NFTs, and arbitrary messages between L1 and L2. It serves as a secure mechanism for moving various digital assets across L1 and L2.
+import ClickToZoom from "../../../../components/ClickToZoom.astro"
+import L1GatewayWHITE from "../../../../assets/images/developers/L1GatewayWHITE.png"
+import withdrawWHITE from "../../../../assets/images/developers/withdrawWHITE.png"
-To facilitate the transfer of ETH and ERC20 tokens, the Scroll bridge utilizes the Gateway Router. This contract ensures the smooth passage of these assets between L1 and L2, allowing users to transfer their Ethereum-based tokens seamlessly.
+El puente Scroll permite la transferencia de ETH, tokens ERC20, NFT y mensajes arbitrarios entre L1 y L2. Sirve como mecanismo seguro para mover diversos activos digitales entre L1 y L2.
-The ERC721 and ERC1155 Gateway enables the transfer of non-fungible assets between the two networks, allowing users to move their NFTs across L1 and L2.
+Para facilitar la transferencia de tokens ETH y ERC20, el puente Scroll utiliza el Gateway Router. Este contrato garantiza el paso fluido de estos activos entre L1 y L2, permitiendo a los usuarios transferir sus tokens basados en Ethereum sin problemas.
-In addition to token transfers, the Scroll Messenger contract enables cross-chain contract interaction. This means that contracts on one network can interact with contracts on the other network through the Scroll Messenger contract. This functionality expands the possibilities for decentralized applications and smart contracts to operate seamlessly across both networks.
+La Gateway ERC721 y ERC1155 permite la transferencia de activos no fungibles entre las dos redes, permitiendo a los usuarios mover sus NFT entre L1 y L2.
-## L1 Gateway architecture
+Además de las transferencias de tokens, el contrato Scroll Messenger permite la interacción de contratos cross-chain. Esto significa que los contratos de una red pueden interactuar con los contratos de la otra red a través del contrato Scroll Messenger. Esta funcionalidad amplía las posibilidades de que las aplicaciones descentralizadas y los smart contracts operen sin problemas en ambas redes.
-There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter` . If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion.
+## Arquitectura de la Gateway L1
-## L2 Gateway arquitectura
+
-Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger` . All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1.
+Hay muchos puntos de entrada del usuario al Scroll bridge. Esto dependerá de lo que quieras hacer y cómo quieras hacerlo. Si quieres enviar tokens ETH o ERC20, deberías usar el `GatewayRouter` . Si quieres enviar NFTs, deberías usar `L1ERC721Gateway` o `L1ERC1155Gateway`. Si desea enviar datos arbitrarios, utilice `L1ScrollMessenger`. Todas las transferencias de Gateway utilizan el Scroll Messenger para enviar activos a través de la cadena, cuyo trabajo consiste en anexar las transacciones a la cola de mensajes para su inclusión en L2.
-In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities.
+## Arquitectura de la Gateway L2
+
+
+
+En cuanto a los posibles puntos de entrada accesibles sin permiso, la Arquitectura de la Gateway L2 es muy similar a la de la L1. La diferencia es que cuando se envía un mensaje desde L2, si se llama a la función `appendMessage`, el mensaje se almacenará en un merkle tree binario sólo para anexarlo (también conocido como withdraw tree) en la `L2MessageQueue`. Cuando se envía un nuevo mensaje a la `L2MessageQueue`, el relayer lo detecta y lo almacena en la base de datos. Cuando finalice el bloque, generará una prueba de el nuevo merkle path y la pasará al nodo L1geth para que la ejecute en `L1ScrollMessenger` . Todas las roots de retirada finalizadas se almacenarán en el contrato de rollup para que podamos verificar la prueba con ellas. En las próximas versiones de Scroll, el Relayer no será necesario, ya que todos los usuarios podrán finalizar la transacción en L1.
+
+En las próximas secciones, exploraremos los aspectos técnicos del puente, incluida la API de smart contract necesaria para utilizar sus capacidades. En la sección Guías para desarrolladores se ofrecen guías detalladas con ejemplos de código para ayudar a desarrolladores y usuarios a comprender e implementar estas funcionalidades.
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
index 3a83794d7..fd463ca99 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
@@ -2,29 +2,29 @@
section: developers
date: Last Modified
title: "ERC1155 Token Bridge"
-lang: "en"
+lang: "es"
permalink: "developers/l1-and-l2-bridging/erc1155-token-bridge"
-whatsnext: { "The Scroll Messenger": "/developers/l1-and-l2-bridging/the-scroll-messenger/" }
-excerpt: "ERC1155 bridging from L1 to L2 is done via the L1ERC1155Gateway."
+whatsnext: { "El Scroll Messenger": "/es/developers/l1-and-l2-bridging/the-scroll-messenger" }
+excerpt: "El bridging ERC1155 de L1 a L2 se realiza a través del L1ERC1155Gateway."
---
import Aside from "../../../../../components/Aside.astro"
-## Deposit ERC1155 tokens from L1
+## Depósito de tokens ERC1155 de L1
-ERC1155 bridging from L1 to L2 is done via the L1ERC1155Gateway. Similarly to ERC721 bridging, we don't use a router but the `depositERC1155` function on the Gateway directly.
+El bridging ERC1155 de L1 a L2 se realiza a través del L1ERC1155Gateway. Al igual que en el bridging ERC721, no se utiliza un router, sino la función `depositERC1155` directamente en la Gateway.
- **`depositERC1155`** is a payable function, and the amount of ETH sent to this function will be used to pay for L2
- fees. If the amount is not enough, the transaction will not be sent. All excess eth will be sent back to sender.
- `0.00001 ETH` should be more than enough to process a token deposit.
+ **`depositERC1155`** es una función de pago, y la cantidad de ETH enviada a esta función se utilizará para pagar L2
+ tasas. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será enviado de vuelta al remitente.
+ Un importe de `0.00001 ETH` debería ser más que suficiente para procesar un depósito de tokens.
-### Creating an ERC1155 token on L2
+### Creación de un token ERC1155 en L2
-Similar to ERC721 bridging, in order to bridge ERC1155 tokens, a contract compatible with the `IScrollERC1155` standard has to be launched and mapped on a `L1ERC1155Gateway` and `L2ERC1155Gateway` on both L1 and L2 respectively. This contract has to grant permission to the Gateway on L2 to mint when a token is deposited and burn when the token is withdrawn.
+De forma similar al bridging ERC721, para realizar el bridging de tokens ERC1155 es necesario lanzar un contrato compatible con el estándar `IScrollERC1155` y asignarlo a una `L1ERC1155Gateway` y una `L2ERC1155Gateway` en L1 y L2 respectivamente. Este contrato tiene que conceder permiso a la Gateway en L2 para emitir cuando un token es depositado y quemar cuando el token es retirado.
-The following interface is the `IScrollERC1155` needed for deploying ERC1155 tokens compatible with the `L2ERC1155Gateway` on L2.
+La siguiente interfaz es el `IScrollERC1155` necesario para desplegar tokens ERC1155 compatibles con el `L2ERC1155Gateway` en L2.
```solidity
interface IScrollERC1155 {
@@ -71,29 +71,28 @@ interface IScrollERC1155 {
}
```
-### Adding an ERC1155 token to the Scroll Bridge
+### Añadiendo un token ERC1155 al Scroll Bridge
-All assets can be bridged securely and permissionlessly through Gateway contracts deployed by any developer. However, Scroll also manages an ERC1155 Gateway contract where all NFTs created by the community are welcome. Being part of the Scroll-managed Gateway means you won't need to deploy the Gateway contracts, and your token will appear in the Scroll frontend. To be part of the Scroll Gateway, you must contact the Scroll team to add the token to both L1 and L2 Gateway contracts. To do so, follow the instructions on the [token lists](https://github.com/scroll-tech/token-list) repository to add your token to the Scroll official frontend.
+Todos los activos pueden ser transferidos de forma segura y sin permisos a través de contratos Gateway desplegados por cualquier desarrollador. Sin embargo, Scroll también gestiona un contrato Gateway ERC1155 en el que todos los NFT creados por la comunidad son bienvenidos. Formar parte del Gateway gestionado por Scroll significa que no necesitarás desplegar los contratos Gateway, y tu token aparecerá en el frontend de Scroll. Para formar parte de la Gateway de Scroll, debe ponerse en contacto con el equipo de Scroll para añadir el token a los contratos de Gateway L1 y L2. Para ello, siga las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir su token al frontend oficial de Scroll.
-## Withdraw ERC1155 tokens from L2
+## Retiro de tokens ERC1155 de L2
-The `L2ERC1155Gateway` contract is used to send tokens from L2 to L1. Before bridging, the `L2ERC1155Gateway` contract has to be approved by the token contract. Once that is done, `withdrawERC1155` can be called to perform the asset bridge.
+El contrato `L2ERC1155Gateway` se utiliza para enviar tokens de L2 a L1. Antes de realizar el bridging, el contrato `L2ERC1155Gateway` tiene que ser aprobado por el contrato de tokens. Una vez hecho esto, se puede llamar a `withdrawERC1155` para realizar el intercambio de activos.
- **`withdrawERC1155`** is a payable function, and the amount of ETH sent to this function will be used to pay for L1
- fees. If the amount is not enough, the transaction will not be sent. All excess ETH will be sent back to sender. Fees
- depend on L1 activity but `0.005 ETH` should be enough to process a token withdrawal.
+ **`withdrawERC1155`** es una función de pago, y la cantidad de ETH enviada a esta función se utilizará para pagar las tasas de L1. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será devuelto al remitente. Las tasas
+ dependen de la actividad de L1 pero `0.005 ETH` debería ser suficiente para procesar una retirada de tokens.
- **Make sure the transaction won't revert on L1** while sending from L2. There is no way to recover tokens bridged if
- you're transaction reverts on L1. All assets are burnt on L2 when the transaction is sent, and it's impossible to mint
- them again.
+ **Asegúrate de que la transacción no se revertirá en L1** mientras envías desde L2. No hay forma de recuperar los tokens puenteados si
+ tu transacción revierte en L1. Todos los activos se queman en L2 cuando se envía la transacción, y es imposible recuperarlos
+ de nuevo.
-## L1ERC1155Gateway API
+## API de L1ERC1155Gateway
-Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) for the complete Scroll contract API documentation.
+Visite la biblioteca [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de los contratos de Scroll.
### depositERC1155
@@ -107,15 +106,15 @@ function depositERC1155(
) external payable;
```
-Deposit an ERC1155 token from L1 to a recipient's account on L2.
+Depósito de un token ERC1155 desde L1 en la cuenta de un destinatario en L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------- |
-| token | The address of ERC1155 token contract on L1. |
-| to | The address of recipient's account on L2. |
-| tokenId | The NFT id to deposit. |
-| amount | The amount of tokens to deposit. |
-| gasLimit | Gas limit required to complete the deposit on L2. |
+| token | La dirección del contrato de tokens ERC1155 en L1. |
+| to | La dirección de la cuenta del destinatario en L2. |
+| tokenId | El id del NFT a depositar. |
+| amount | La cantidad de tokens a depositar. |
+| gasLimit | Límite de gas necesario para completar el depósito en L2. |
### updateTokenMapping
@@ -123,14 +122,14 @@ Deposit an ERC1155 token from L1 to a recipient's account on L2.
function updateTokenMapping(address _l1Token, address _l2Token) external;
```
-Update the mapping that connects an ERC1155 token contract from L1 to L2.
+Actualización del mapping que conecta un contrato de tokens ERC1155 de L1 a L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------- |
-| \_l1Token | The address of the ERC1155 token in L1. |
-| \_l2Token | The address of corresponding ERC1155 token in L2. |
+| \_l1Token | La dirección del token ERC1155 en L1. |
+| \_l2Token | La dirección del token ERC1155 correspondiente en L2. |
-## L2ERC1155Gateway API
+## API de L2ERC1155Gateway
### withdrawERC1155
@@ -138,15 +137,15 @@ Update the mapping that connects an ERC1155 token contract from L1 to L2.
function withdrawERC1155(address token, address to, uint256 tokenId, uint256 amount, uint256 gasLimit) external payable;
```
-Send ERC1155 tokens from L2 to a recipient's account on L1.
+Envío de tokens ERC1155 desde L2 a la cuenta de un destinatario en L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------------------------------ |
-| token | The address of ERC1155 token contract on L2. |
-| to | The address of recipient's account on L1. |
-| tokenId | The NFT id to withdraw. |
-| amount | The amount of tokens to withdraw. |
-| gasLimit | Unused, but included for potential forward compatibility considerations. |
+| token | La dirección del contrato de tokens ERC1155 en L2. |
+| to | La dirección de la cuenta del destinatario en L1. |
+| tokenId | El id del NFT a retirar. |
+| amount | La cantidad de tokens a retirar. |
+| gasLimit | No se utiliza, pero se incluye por posibles consideraciones de compatibilidad futura. |
### updateTokenMapping
@@ -154,9 +153,9 @@ Send ERC1155 tokens from L2 to a recipient's account on L1.
function updateTokenMapping(address _l1Token, address _l2Token) external;
```
-Update the mapping that connects an ERC1155 token contract from L2 to L1.
+Actualización del mapping que conecta un contrato de tokens ERC1155 de L2 a L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------- |
-| \_l1Token | The address of th ERC1155 token in L1. |
-| \_l2Token | The address of corresponding ERC1155 token in L2. |
+| \_l1Token | La dirección del token ERC1155 en L1. |
+| \_l2Token | La dirección del token ERC1155 correspondiente en L2. |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
index fcd496682..b9459b5c1 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
@@ -2,31 +2,31 @@
section: developers
date: Last Modified
title: "ERC721 NFT Bridge"
-lang: "en"
+lang: "es"
permalink: "developers/l1-and-l2-bridging/erc721-nft-bridge"
-excerpt: "NFT bridging from L1 to L2 is done via the L1ERC721Gateway contract instead of using a router."
-whatsnext: { "ERC1155 Token Bridge": "/developers/l1-and-l2-bridging/erc721-nft-bridge/" }
+excerpt: "El bridging de NFTs de L1 a L2 se realiza a través del contrato L1ERC721Gateway en lugar de utilizar un router."
+whatsnext: { "ERC1155 Token Bridge": "/es/developers/l1-and-l2-bridging/erc1155-token-bridge" }
---
import Aside from "../../../../../components/Aside.astro"
-## Deposit ERC721 tokens from L1
+## Depósito de tokens ERC721 de L1
-NFT bridging from L1 to L2 is done via the `L1ERC721Gateway` contract instead of using a router. Similarly to bridging ERC20 tokens, we use the `depositERC721` function to send tokens to L2, and we can later retrieve them back to L1 using `withdrawERC721` on the `L2ERC721Gateway` contract deployed on L2.
+El bridging NFTs de L1 a L2 se realiza a través del contrato `L1ERC721Gateway` en lugar de utilizar un router. De forma similar a el bridging de tokens ERC20, utilizamos la función `depositERC721` para enviar tokens a L2, y posteriormente podemos recuperarlos de vuelta a L1 utilizando `withdrawERC721` en el contrato `L2ERC721Gateway` desplegado en L2.
-NFT contracts on both L1 and l2 must be launched and connected through the Gateways to enable bridging. This means deposit and withdraw transactions will revert if a contract on either L1 or L2 is missing or not mapped through the `updateTokenMapping` function.
+Los contratos NFT tanto en L1 como en L2 deben lanzarse y conectarse a través de las Gateways para permitir el bridging. Esto significa que las transacciones de depósito y retirada se revertirán si falta un contrato en L1 o L2 o si no se asigna a través de la función `updateTokenMapping`.
- **`depositERC721`** is a payable function. The amount of ETH sent to this function will be used to pay for L2 fees. If
- the amount is not enough, the transaction will not be sent. All excess eth will be sent back to the sender. `0.00001
- ETH` should be more than enough to process a token deposit.
+ **`depositERC721`** es una función de pago. La cantidad de ETH enviada a esta función se utilizará para pagar las tasas de la L2. Si
+ la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será devuelto al remitente. `0.00001
+ ETH` debería ser más que suficiente para procesar un depósito de tokens.
-### Creating a ScrollERC721 token on L2
+### Creación de un token ScrollERC721 en L2
-To deposit an ERC721 token to L2, a token contract compatible with the `IScrollERC721` standard has to be launched and mapped on a `L1ERC721Gateway` and `L2ERC721Gateway` on both L1 and L2, respectively. This contract has to grant permission to the Gateway on L2 to mint when a token is deposited and burn when the token is withdrawn.
+Para depositar un token ERC721 en L2, debe lanzarse un contrato de token compatible con el estándar `IScrollERC721` y asignarse a una `L1ERC721Gateway` y una `L2ERC721Gateway` en L1 y L2, respectivamente. Este contrato tiene que conceder permiso a la Gateway en L2 para emitir cuando un token es depositado y quemar cuando el token es retirado.
-The following interface is the `IScrollERC721` needed for deploying ERC721 tokens compatible with the `L2ERC721Gateway` on L2.
+La siguiente interfaz es el `IScrollERC721` necesario para desplegar tokens ERC721 compatibles con el `L2ERC721Gateway` en L2.
```solidity
interface IScrollERC721 {
@@ -49,29 +49,28 @@ interface IScrollERC721 {
}
```
-### Adding ERC721 NFTs to the Scroll Bridge
+### Añadiendo NFTs ERC721 al Scroll Bridge
-All assets can be bridged securely and permissionlessly through Gateway contracts deployed by any developer. However, Scroll also manages an ERC721 Gateway contract where all NFTs created by the community are welcome. Being part of the Scroll-managed Gateway means you won't need to deploy the Gateway contracts, and your token will appear in the Scroll frontend. To be part of the Scroll Gateway, you must contact the Scroll team to add the NFT on both L1 and L2 Gateway contracts. To do so, follow the instructions on the [token lists](https://github.com/scroll-tech/token-list) repository to add a new token to the Scroll official frontend.
+Todos los activos pueden ser transferidos de forma segura y sin permisos a través de contratos Gateway desplegados por cualquier desarrollador. Sin embargo, Scroll también gestiona un contrato Gateway ERC721 en donde todos los NFTs creados por la comunidad son bienvenidas. Formar parte del Gateway gestionado por Scroll significa que no necesitará desplegar los contratos Gateway, y su token aparecerá en el frontend de Scroll. Para formar parte de la Gateway gestionada por Scroll, debe ponerse en contacto con el equipo de Scroll para añadir el NFT en los contratos Gateway L1 y L2. Para ello, siga las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir un nuevo token al frontend oficial de Scroll.
-## Withdraw ERC721 tokens from Scroll
+## Retiro de tokens ERC721 de Scroll
-The `L2ERC721Gateway` contract is used to send tokens from L2 to L1. Before bridging, the `L2ERC721Gateway` contract has to be approved by the NFT contract. Once that is done, `withdrawERC721` can be called to perform the asset bridge.
+El contrato `L2ERC721Gateway` se utiliza para enviar tokens de L2 a L1. Antes de realizar el bridging, el contrato `L2ERC721Gateway` tiene que ser aprobado por el contrato NFT. Una vez hecho esto, se puede llamar a `withdrawERC721` para realizar el intercambio de activos.
- **`withdrawERC721`** is a payable function, and the amount of ETH sent to this function will be used to pay for L1
- fees. If the amount is not enough, the transaction will not be sent. All excess ETH will be sent back to sender. Fees
- depend on L1 activity but `0.005 ETH` should be enough to process a token withdrawal.
+ **`withdrawERC721`** es una función de pago, y la cantidad de ETH enviada a esta función se utilizará para pagar las tasas de L1. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será devuelto al remitente. Las tasas
+ dependen de la actividad de L1 pero `0.005 ETH` debería ser suficiente para procesar una retirada de tokens.
- **Make sure the transaction won't revert on L1** while sending from L2. There is no way to recover the NFT bridged if
- you're transaction reverts on L1. All assets are burnt on L2 when the transaction is sent, and it's impossible to mint
- them again.
+ **Asegúrate de que la transacción no se revertirá en L1** mientras envías desde L2. No hay forma de recuperar el NFT puenteado si
+ tu transacción revierte en L1. Todos los activos se queman en L2 cuando se envía la transacción, y es imposible recuperarlos
+ de nuevo.
-## L1ERC721Gateway API
+## API de L1ERC721Gateway
-Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) for the complete Scroll contract API documentation.
+Visite la biblioteca [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de los contratos de Scroll.
### depositERC721
@@ -79,14 +78,14 @@ Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contra
function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
```
-Deposit an ERC721 NFT from L1 to a recipient's account on L2.
+Depósito de un ERC721 NFT desde L1 a la cuenta de un destinatario en L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------- |
-| token | The address of ERC721 NFT contract on L1. |
-| to | The address of recipient's account on L2. |
-| tokenId | The NFT id to deposit. |
-| gasLimit | Gas limit required to complete the deposit on L2. |
+| token | La dirección del contrato ERC721 NFT en L1. |
+| to | La dirección de la cuenta del destinatario en L2. |
+| tokenId | El id del NFT a depositar. |
+| gasLimit | Límite de gas necesario para completar el depósito en L2. |
### updateTokenMapping
@@ -94,14 +93,14 @@ Deposit an ERC721 NFT from L1 to a recipient's account on L2.
function updateTokenMapping(address _l1Token, address _l2Token) external;
```
-Update the mapping that connects an NFT contract from L1 to L2.
+Actualización del mapping que conecta un contrato NFT de L1 a L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------ |
-| \_l1Token | The address of ERC721 token in L1. |
-| \_l2Token | The address of corresponding ERC721 token in L2. |
+| \_l1Token | La dirección del token ERC721 en L1. |
+| \_l2Token | La dirección del token ERC721 correspondiente en L2. |
-## L2ERC721Gateway API
+## API de L2ERC721Gateway
### withdrawERC721
@@ -109,14 +108,14 @@ Update the mapping that connects an NFT contract from L1 to L2.
function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
```
-Send an ERC721 NFT from L2 to a recipient's account on L1.
+Envío de un ERC721 NFT desde L2 a la cuenta de un destinatario en L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------------------------------ |
-| token | The address of ERC721 NFT token contract on L2. |
-| to | The address of recipient's account on L1. |
-| tokenId | The NFT id to deposit. |
-| gasLimit | Unused, but included for potential forward compatibility considerations. |
+| token | La dirección del contrato de tokens ERC721 NFT en L2. |
+| to | La dirección de la cuenta del destinatario en L1. |
+| tokenId | El id del NFT a depositar. |
+| gasLimit | No se utiliza, pero se incluye por posibles consideraciones de compatibilidad futura. |
### updateTokenMapping
@@ -124,9 +123,9 @@ Send an ERC721 NFT from L2 to a recipient's account on L1.
function updateTokenMapping(address _l1Token, address _l2Token) external;
```
-Update the mapping that connects an NFT contract from L2 to L1.
+Actualización del mapping que conecta un contrato NFT de L2 a L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------ |
-| \_l2Token | The address of ERC721 token in L2. |
-| \_l1Token | The address of corresponding ERC721 token in L1. |
+| \_l2Token | La dirección del token ERC721 en L2. |
+| \_l1Token | La dirección del token ERC721 correspondiente en L1. |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
index ff083a97e..480c9a0e9 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
@@ -1,62 +1,64 @@
---
section: developers
date: Last Modified
-title: "ETH and ERC20 Token Bridge"
-lang: "en"
+title: "ETH y ERC20 Token Bridge"
+lang: "es"
permalink: "developers/l1-and-l2-bridging/eth-and-erc20-token-bridge"
-whatsnext: { "ERC721 NFT Bridge": "/developers/l1-and-l2-bridging/erc721-nft-bridge/" }
-excerpt: "The Gateway Router allows ETH and ERC20 token bridging from L1 to L2 using the depositETH and depositERC20 functions respectively."
+whatsnext: { "ERC721 NFT Bridge": "/es/developers/l1-and-l2-bridging/erc721-nft-bridge" }
+excerpt: "El Gateway Router permite puentear tokens ETH y ERC20 de L1 a L2 utilizando las funciones depositETH y depositERC20 respectivamente."
---
import Aside from "../../../../../components/Aside.astro"
-## Deposit ETH and ERC20 tokens from L1
+## Depositar ETH y tokens ERC20 de L1
-The Gateway Router allows ETH and ERC20 token bridging from L1 to L2 using the `depositETH` and `depositERC20` functions respectively. It is a permissionless bridge deployed on L1. Notice that ERC20 tokens will have a different address on L2, you can use the `getL2ERC20Address` function to query the new address.
+El Gateway Router permite el puenteo de tokens ETH y ERC20 desde L1 a L2 utilizando las funciones `depositETH` y `depositERC20` respectivamente. Se trata de un puente permissionless desplegado en L1. Tenga en cuenta que los tokens ERC20 tendrán una dirección diferente en L2, puede utilizar la función `getL2ERC20Address` para consultar la nueva dirección.
- **`depositETH`** and **`depositERC20`** are payable functions, the amount of ETH sent to these functions will be used
- to pay for L2 fees. If the amount is not enough, the transaction will not be sent. All excess ETH will be sent back to
- the sender. `0.00001 ETH` should be more than enough to process a token deposit.
+ **`depositETH`** y **`depositERC20`** son funciones de pago, la cantidad de ETH enviada a estas funciones se utilizará
+para pagar las tarifas de L2. Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH se devolverá al
+ al remitente. Una cantidad de ETH de `0,00001` debería ser más que suficiente para procesar un depósito de tokens.
-When bridging ERC20 tokens, you don’t have to worry about selecting the right Gateway. This is because the `L1GatewayRouter` will choose the correct underlying entry point to send the message:
+Al puentear tokens ERC20, no tienes que preocuparte de seleccionar la Gateway correcta. Esto se debe a que el `L1GatewayRouter` elegirá el punto de entrada subyacente correcto para enviar el mensaje:
-- **`L1StandardERC20Gateway`:** This Gateway permits any ERC20 deposit and will be selected as the default by the L1GatewayRouter for an ERC20 token that doesn’t need custom logic on L2. On the very first token bridging, a new token will be created on L2 that implements the ScrollStandardERC20. To bridge a token, call the `depositERC20` function on the `L1GatewayRouter`.
-- **`L1CustomERC20Gateway`:** This Gateway will be selected by the `L1GatewayRouter` for tokens with custom logic. For an L1/L2 token pair to work on the Scroll Custom ERC20 Bridge, the L2 token contract has to implement `IScrollStandardERC20`. Additionally, the token should grant `mint` or `burn` capability to the `L2CustomERC20Gateway`. Visit the [Bridge an ERC20 through the Custom Gateway](/developers/developer-guides/bridge-erc20-through-the-custom-gateway) guide for a step-by-step example of how to bridge a custom token.
+- **`L1StandardERC20Gateway`:** Esta Gateway permite cualquier depósito ERC20 y será seleccionada por defecto por el L1GatewayRouter para un token ERC20 que no necesite lógica personalizada en L2. En el primer puenteo de tokens, se creará un nuevo token en L2 que implemente el ScrollStandardERC20. Para puentear un token, llame a la función `depositERC20` en el `L1GatewayRouter`.
+- **`L1CustomERC20Gateway`:** Esta Gateway será seleccionada por el `L1GatewayRouter` para tokens con lógica personalizada. Para que un pair de token L1/L2 funcione en el puente ERC20 personalizado de Scroll, el contrato de token L2 tiene que implementar `IScrollStandardERC20`. Además, el token debe conceder la capacidad `mint` o `burn` a la `L2CustomERC20Gateway`.
-All Gateway contracts will form the message and send it to the `L1ScrollMessenger` which can send arbitrary messages to L2. The `L1ScrollMessenger` passes the message to the `L1MessageQueue`. Any user can send messages directly to the Messenger to execute arbitrary data on L2. This means they can execute any function on L2 from a transaction made on L1 via the bridge. Although an application could directly pass messages to existing token contracts, the Gateway abstracts the specifics and simplifies making transfers and calls.
+ Visite la guía [Bridge ERC20 a través de una Gateway Personalizada](/developers/developer-guides/bridge-erc20-through-the-custom-gateway) para ver un ejemplo paso a paso de cómo puentear un token personalizado.
+
+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 la realización de transferencias y llamadas.
- Users can also bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. If a message is sent
- via the `L1MessageQueue`, the transaction's sender will be the address of the user sending the transaction, not the
- address of the `L1ScrollMessenger`. Learn more about sending arbitrary messages in the [Scroll
- Messenger](/developers/l1-and-l2-bridging/the-scroll-messenger) article.
+ Los usuarios también pueden omitir el `L1ScrollMessenger` y enviar mensajes directamente al `L1MessageQueue`. Si se envía 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 de `L1ScrollMessenger`.
+ 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).
-When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessagner` contract for execution on L2.
+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.
-## Withdraw ETH and ERC20 tokens from L2
+## Retiro de ETH y ERC20 tokens desde L2
-The L2 Gateway is very similar to the L1 Gateway. We can withdraw ETH and ERC20 tokens back to L1 using the `withdrawETH` and `withdrawERC20` functions. The contract address is deployed on L2. We use the `getL1ERC20Address` to retrieve the token address on L1.
+La Gateway L2 es muy similar a la Gateway L1. Podemos retirar tokens ETH y ERC20 de vuelta a L1 utilizando las funciones `withdrawETH` y `withdrawERC20`. La dirección del contrato se despliega en L2. Usamos la función `getL1ERC20Address` para conseguir la dirección del token en L1.
- **`withdrawETH`** and **`withdrawERC20`** are payable functions, and the amount of ETH sent to these functions will be
- used to pay for L1 fees. If the amount is not enough, the transaction will not be sent. All excess ETH will be sent
- back to the sender. Fees will depend on L1 activity but `0.005 ETH` should be enough to process a token withdrawal.
+ **`withdrawETH`** y **`withdrawERC20`** son funciones de pago, y la cantidad de ETH enviada a estas funciones será
+utilizado para pagar las tarifas Si la cantidad no es suficiente, la transacción no será enviada. Todo el exceso de ETH será enviado
+ al remitente. Las tasas dependerán de la actividad de L1, pero `0,005 ETH` debería ser suficiente para procesar una retirada de tokens.
- **Make sure the transactions won't revert on L1** while sending from L2. There is no way to recover bridged ETH,
- tokens, or NFTs if your transaction reverts on L1. All assets are burnt on Scroll when the transaction is sent, and
- it's impossible to mint them again.
+ **Asegúrate de que las transacciones no se revertirán en L1** mientras envías desde L2. No hay forma de recuperar ETH,
+ tokens, o NFTs si tu transacción revierte en L1. Todos los activos se queman en Scroll cuando se envía la transacción, y
+ es imposible volver recuperarlos.
-## Creating an ERC20 token with custom logic on L2
+## Creación de un token ERC20 con lógica personalizada en L2
-If a token needs custom logic on L2, it will need to be bridged through a `L1CustomERC20Gateway` and `L2CustomERC20Gateway` respectively. The custom token on L2 will need to give permission to the Gateway to mint new tokens when a deposit occurs and to burn when tokens are withdrawn
+Si un token necesita una lógica personalizada en L2, deberá puentearse a través de `L1CustomERC20Gateway` y `L2CustomERC20Gateway` respectivamente. El token personalizado en L2 deberá dar permiso a la Gateway para emitir nuevos tokens cuando se produzca un depósito y para quemarlos cuando se retiren.
-The following interface is the `IScrollStandardERC20` needed for deploying tokens compatible with the `L2CustomERC20Gateway` on L2.
+La siguiente interfaz es el `IScrollStandardERC20` necesario para desplegar tokens compatibles con el `L2CustomERC20Gateway` en L2.
```solidity
interface IScrollStandardERC20 {
@@ -85,13 +87,13 @@ interface IScrollStandardERC20 {
}
```
-### Adding a Custom L2 ERC20 token to the Scroll Bridge
+### Añadir un token L2 ERC20 personalizado al Scroll Bridge
-Tokens can be bridged securely and permissionlessly through Gateway contracts deployed by any developer. However, Scroll also manages an ERC20 Router and a Gateway where all tokens created by the community are welcome. Being part of the Scroll-managed Gateway means you won't need to deploy the Gateway contracts, and your token will appear in the Scroll frontend. To be part of the Scroll Gateway, you must contact the Scroll team to add the token to both L1 and L2 bridge contracts. To do so, follow the instructions on the [token lists](https://github.com/scroll-tech/token-list) repository to add your new token to the official Scroll frontend.
+Los tokens pueden ser puenteados de forma segura y de manera permissionless a través de contratos Gateway desplegados por cualquier desarrollador. Sin embargo, Scroll también gestiona un Router ERC20 y un Gateway donde todos los tokens creados por la comunidad son bienvenidos. Formar parte del Gateway gestionado por Scroll significa que no necesitarás desplegar los contratos Gateway, y tu token aparecerá en el frontend de Scroll. Para formar parte de la Gateway de Scroll, debe ponerse en contacto con el equipo de Scroll para añadir el token a los contratos puente L1 y L2. Para ello, siga las instrucciones del repositorio [token lists](https://github.com/scroll-tech/token-list) para añadir su nuevo token al frontend oficial de Scroll.
-## L1 Gateway API
+## API de la Gateway L1
-Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) for the complete Scroll contract API documentation.
+Visite la biblioteca [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de contratos de Scroll.
### depositETH
@@ -99,13 +101,13 @@ Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contra
function depositETH(address _to, uint256 _amount, uint256 _gasLimit) public payable;
```
-Sends ETH from L1 to L2.
+Envia ETH desde L1 a L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | --------------------------------------------------------------------------------------------------------------------------- |
-| to | The address of recipient's account on L2. |
-| amount | The amount of token to transfer, in wei. |
-| gasLimit | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
+| to | Dirección de la cuenta del destinatario en L2. |
+| amount | La 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. |
### depositERC20
@@ -113,14 +115,14 @@ Sends ETH from L1 to L2.
function depositERC20(address _token, address _to, uint256 _amount, uint256 _gasLimit) payable;
```
-Sends ERC20 tokens from L1 to L2.
+Enviar ERC20 tokens desde L1 a L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | --------------------------------------------------------------------------------------------------------------------------- |
-| token | The token address on L1. |
-| to | The address of recipient's account on L2. |
-| amount | The amount of token to transfer, in wei. |
-| gasLimit | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
+| token | La dirección del token en L1. |
+| to | Dirección de la cuenta del destinatario en L2. |
+| amount | La 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. |
### getL2ERC20Address
@@ -128,11 +130,11 @@ Sends ERC20 tokens from L1 to L2.
function getL2ERC20Address(address _l1Token) external view returns (address);
```
-Returns the corresponding L2 token address given L1 token address.
+Devuelve la dirección de token L2 correspondiente dada la dirección de token L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------ |
-| \_l1Token | The address of l1 token. |
+| \_l1Token | La dirección del token l1. |
### updateTokenMapping
@@ -140,14 +142,14 @@ Returns the corresponding L2 token address given L1 token address.
function updateTokenMapping(address _l1Token, address _l2Token) external;
```
-Update the mapping that connects an ERC20 token from L1 to L2.
+Actualiza el mapping que conecta un token ERC20 de L1 a L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ----------------------------------------------- |
-| \_l1Token | The address of the ERC20 token in L1. |
-| \_l2Token | The address of corresponding ERC20 token in L2. |
+| \_l1Token | Dirección del token ERC20 en L1. |
+| \_l2Token | La dirección del token ERC20 correspondiente en L2. |
-## L2 Gateway API
+## API de la Gateway L2
### withdrawETH
@@ -155,13 +157,13 @@ Update the mapping that connects an ERC20 token from L1 to L2.
function withdrawETH(address to, uint256 amount, uint256 gasLimit) external payable;
```
-Sends ETH from L2 to L1.
+Envia ETH desde L2 a L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------------------------------------------------------------- |
-| to | The address of recipient's account on L1. |
-| amount | The amount of token to transfer, in wei. |
-| gasLimit | Gas limit required to complete the deposit on L1. This is optional, send 0 if you don’t want to set it. |
+| to | Dirección de la cuenta del destinatario en L1. |
+| amount | Cantidad de token a transferir, en wei. |
+| gasLimit | Límite de gas necesario para completar el depósito en L1. Esto es opcional, envíe 0 si no desea establecerlo. |
### withdrawERC20
@@ -169,14 +171,14 @@ Sends ETH from L2 to L1.
function withdrawERC20(address token, address to, uint256 amount, uint256 gasLimit) external payable;
```
-Sends ERC20 tokens from L2 to L1.
+Envia tokens ERC20 desde L2 a L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ------------------------------------------------------------------------------------------------------- |
-| token | The token address on L2. |
-| to | The address of recipient's account on L1. |
-| amount | The amount of token to transfer, in wei. |
-| gasLimit | Gas limit required to complete the deposit on L1. This is optional, send 0 if you don’t want to set it. |
+| token | La dirección del token en L2. |
+| to | Dirección de la cuenta del destinatario en L1. |
+| amount | Cantidad de token a transferir, en wei. |
+| gasLimit | Límite de gas necesario para completar el depósito en L1. Esto es opcional, envíe 0 si no desea establecerlo. |
### getL1ERC20Address
@@ -184,11 +186,11 @@ Sends ERC20 tokens from L2 to L1.
function getL1ERC20Address(address l2Token) external view returns (address);
```
-Returns the corresponding L1 token address given an L2 token address.
+Devuelve la dirección de token L1 correspondiente dada una dirección de token L2.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ---------------------------- |
-| l2Token | The address of the L2 token. |
+| l2Token | La dirección del token L2. |
### updateTokenMapping
@@ -196,9 +198,9 @@ Returns the corresponding L1 token address given an L2 token address.
function updateTokenMapping(address _l1Token, address _l2Token) external;
```
-Update the mapping that connects an ERC20 contract from L2 to L1.
+Actualizar el mapping que conecta un contrato ERC20 de L2 a L1.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ----------------------------------------------- |
-| \_l2Token | The address of the ERC20 token in L2. |
-| \_l1Token | The address of corresponding ERC20 token in L1. |
+| \_l2Token | La dirección del token ERC20 en L2. |
+| \_l1Token | La dirección del token ERC20 correspondiente en L1. |
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx
index 10ee9b867..84b0457d5 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/the-scroll-messenger.mdx
@@ -1,45 +1,44 @@
---
section: developers
date: Last Modified
-title: "The Scroll Messenger"
-lang: "en"
+title: "El Scroll Messenger"
+lang: "es"
permalink: "developers/l1-and-l2-bridging/the-scroll-messenger"
-whatsnext: { "Transaction Fees on Scroll": "/developers/transaction-fees-on-scroll/" }
-excerpt: "The Scroll Messenger documentation for arbitrary message passing between L1 and L2."
+whatsnext: { "Comisiones de Transacciones en Scroll": "/es/developers/transaction-fees-on-scroll/" }
+excerpt: "La documentación de Scroll Messenger para el paso arbitrario de mensajes entre L1 y L2."
---
import Aside from "../../../../../components/Aside.astro"
-The Scroll Messenger contracts allow for sending arbitrary messages from L1 to L2 or vice versa. This enables executing functions on another chain in a secure and permissionless way. To send a message from L1 to L2, use
-the messenger smart contract deployed on L1, `L1ScrollMessenger`. To send a message from L2 to L1, use the contract deployed on L2, `L2ScrollMessenger`.
+Los contratos Scroll Messenger permiten enviar mensajes arbitrarios de L1 a L2 o viceversa. Esto permite ejecutar funciones en otra cadena de forma segura y sin permisos. Para enviar un mensaje de L1 a L2, utilice
+el smart contract desplegado en L1, `L1ScrollMessenger`. Para enviar un mensaje de L2 a L1, utilice el contrato desplegado en L2, `L2ScrollMessenger`.
- When sending a transaction through the **Scroll Messenger** deployed on L1 and L2, the resulting transaction sender
- (`CALLER` or `msg.sender`) will be the Messenger Contract address deployed on the receiving chain.
+ Cuando se envia una transacción a través del **Scroll Messenger** desplegado en L1 y L2, el remitente de la transacción resultante
+ (`CALLER` o `msg.sender`) será la dirección del contrato de Messenger desplegado en la cadena receptora.
- In future Scroll versions, enforced transactions from the L1 will allow setting the sender on L2 as the original EOA
- on L1. It will also allow 3rd parties to relay signed transactions securely.
+ En futuras versiones de Scroll, las transacciones forzadas desde el L1 permitirán establecer el remitente en L2 como el EOA original
+ original en L1. También permitirá a terceros retransmitir transacciones firmadas de forma segura.
-## Finalizing transactions on L1
+## Finalización de transacciones en L1
-Any upcoming transactions from L2 need to be finalized using the `relayMessageWithProof` function on the Scroll Messenger
-contract. We call this process "submitting an Execute Withdrawal transaction," and it is required for both sending arbitrary messages and transferring assets through a gateway or the router. When you use `relayMessageWithProof`, you'll have to provide a Merkle inclusion proof showing your transaction is included in the trie of "withdrawal" messages, along with other parameters. Producing this proof and these values can be done locally and permissionlessly, but at the moment, the easiest way to retrieve these parameters is through our backend API hosted at https://sepolia-api-bridge.scroll.io/api/.
+Cualquier transacción futura de L2 necesita ser finalizada usando la función `relayMessageWithProof` en el contrato Scroll Messenger. Llamamos a este proceso "enviar una transacción de Ejecutar Retirada", y es necesario tanto para enviar mensajes arbitrarios como para transferir activos a través de una gateway o del router. Cuando utilices `relayMessageWithProof`, tendrás que proporcionar una prueba de inclusión Merkle que demuestre que tu transacción está incluida en el trie de mensajes de "retirada", junto con otros parámetros. La producción de esta prueba y estos valores se puede hacer localmente y sin permisos, pero por el momento, la forma más fácil de recuperar estos parámetros es a través de nuestra API backend alojada en https://sepolia-api-bridge.scroll.io/api/.
-
- This API was made for our Bridge UI. It is not yet finalized and may change in the future. We will update this guide
- when the API is finalized.
+
+ Esta API se ha creado para nuestra IU del Bridge. Aún no está finalizada y puede cambiar en el futuro. Actualizaremos esta guía
+ cuando la API esté finalizada.
-Supply the address of the EOA or contract responsible for initiating the original transaction on L2 to the `/claimable`
-endpoint. The API backend will provide you with all the necessary information to successfully conclude the transaction on L1.
-Take a look at the following example:
+Proporcione la dirección de la EOA o del contrato responsable de iniciar la transacción original en L2 al punto final `/claimable`.
+reclamable. El backend de la API le proporcionará toda la información necesaria para concluir con éxito la transacción en L1.
+Eche un vistazo al siguiente ejemplo:
```bash
https://sepolia-api-bridge.scroll.io/api/claimable?address=0x031407eaaffFB4f1EC2c999bE4477E52C81de3c5&page_size=10&page=1
```
-The API should return your transaction data in the following format:
+La API debería devolverle los datos de su transacción en el siguiente formato:
```json
{
@@ -82,20 +81,17 @@ The API should return your transaction data in the following format:
}
```
-The `claimInfo` object under the `result` json returned has all the information needed to execute your transaction on L1. The
-parameters needed by the `relayMessageWithProof` are: `from`, `to`, `value`, `nonce`, `message` and `proof`. Supply these to
-the `relayMessageWithProof` function on L1 to execute and finalize your transaction on L1.
+El objeto `claimInfo` bajo el json `result` devuelto tiene toda la información necesaria para ejecutar su transacción en L1. Los parámetros que necesita `relayMessageWithProof` son: `from`, `to`, `value`, `nonce`, `message` y `proof`. Introduzca estos datos en
+la función `relayMessageWithProof` en L1 para ejecutar y finalizar tu transacción en L1.
- All L2 transactions are bundled into batches – you have to wait for the batch that includes your transaction to
- finalize before calling `relayMessageWithProof`. Your transaction batch index is returned in the `batch_index` value
- on the `/claimable` endpoint, and you can follow the progress on the [Scroll Rollup
+ Todas las transacciones L2 se agrupan en lotes: debe esperar a que finalice el lote que incluye su transacción antes de llamar a `relayMessageWithProof`. El index del lote de su transacción se devuelve en el valor `batch_index` en el endpoint `/claimable`, y puede seguir el progreso en el [Scroll Rollup
Explorer](https://scroll.io/rollupscan?page=1&per_page=10).
-## Messenger API
+## API del Messenger
-Please visit the [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) for the complete Scroll contract API documentation.
+Visite la biblioteca [npm library](https://www.npmjs.com/package/@scroll-tech/contracts?activeTab=code) para consultar la documentación completa de la API de los contratos de Scroll.
### sendMessage
@@ -109,15 +105,15 @@ function sendMessage(
) external payable;
```
-Sends arbitrary data from one chain to another. It allows us to execute functions cross-chain.
+Envía datos arbitrarios de una cadena a otra. Nos permite ejecutar funciones entre cadenas.
-| Parameter | Description |
+| Parámetros | Descripción |
| ------------- | ------------------------------------------------------------------------------------------------------------------- |
-| target | The address of the account that receives the message. The receiver can be either a smart contract or an EOA wallet. |
-| value | The amount of ether passed when calling the target contract. |
-| message | The content of the message. This is the arbitrary calldata to be executed. |
-| gasLimit | Gas limit required to complete the message relay on the corresponding chain. |
-| refundAddress | The address of the account that will receive the refunded fee. |
+| target | La dirección de la cuenta que recibe el mensaje. El receptor puede ser un smart contract o una wallet de EOA. |
+| value | La cantidad de ETH pasado al llamar al contrato destino. |
+| message | El contenido del mensaje. Este es el calldata arbitrario a ejecutar. |
+| gasLimit | Límite de gas necesario para completar la retransmisión del mensaje en la cadena correspondiente. |
+| refundAddress | La dirección de la cuenta que recibirá la tarifa reembolsada. |
### relayMessageWithProof
@@ -132,13 +128,13 @@ function relayMessageWithProof(
) external;
```
-Relay a L2 => L1 message with message proof.
+Retransmite un mensaje L2 => L1 con prueba de mensaje.
-| Parameter | Description |
+| Parámetros | Descripción |
| --------- | ------------------------------------------------------------ |
-| from | The address of the sender of the message. |
-| to | The address of the recipient of the message. |
-| value | The msg.value passed to the message call. |
-| nonce | The nonce of the message to avoid replay attack. |
-| message | The content of the message. |
-| proof | The proof used to verify the correctness of the transaction. |
+| from | La dirección del remitente del mensaje. |
+| to | Dirección del destinatario del mensaje. |
+| value | El msg.value pasado a la llamada del mensaje. |
+| nonce | El nonce del mensaje para evitar replay attacks. |
+| message | El contenido del mensaje. |
+| proof | La prueba utilizada para verificar la corrección de la transacción. |
diff --git a/src/content/docs/es/developers/scroll-contracts.mdx b/src/content/docs/es/developers/scroll-contracts.mdx
index 81bac2964..a43981fe5 100644
--- a/src/content/docs/es/developers/scroll-contracts.mdx
+++ b/src/content/docs/es/developers/scroll-contracts.mdx
@@ -1,35 +1,36 @@
---
section: developers
date: Last Modified
-title: "Scroll Sepolia Contracts"
-lang: "en"
+title: "Contratos de Scroll Sepolia"
+lang: "es"
permalink: "developers/scroll-contracts"
+whatsnext: { "Diferencias entre Scroll y Ethereum": "/es/developers/ethereum-and-scroll-differences" }
excerpt: "The network info and contract addresses you need to start with Scroll Sepolia Testnet."
---
import Aside from "../../../../components/Aside.astro"
-## Network Info
+## Información de la Red
-| Network Name | Scroll Sepolia Testnet | Sepolia Testnet |
+| Nombre de Red | Scroll Sepolia Testnet | Sepolia Testnet |
| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) |
| Chain ID | 534351 | 11155111 |
| Currency Symbol | ETH | ETH |
| Block Explorer URL | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) |
-## Scroll Sepolia Contracts
+## Contratos de Scroll Sepolia
### Rollup
- L1 Rollup (Scroll Chain): `0x2D567EcE699Eabe5afCd141eDB7A4f2D0D6ce8a0`
-### ETH and ERC20 Bridge
+### ETH y ERC20 Bridge
- L1 ERC20 Gateway Router: `0x13FBE0D0e5552b8c9c4AE9e2435F38f37355998a`
- L2 ERC20 Gateway Router: `0x9aD3c5617eCAa556d6E166787A97081907171230`
-### Advanced Bridge Contracts
+### Contratos de Bridge Avanzados
- Scroll Messenger
- L1 Messenger: `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`
@@ -51,7 +52,7 @@ import Aside from "../../../../components/Aside.astro"
- L1 ERC1155 Gateway: `0xa5Df8530766A85936EE3E139dECE3bF081c83146`
- L2 ERC1155 Gateway: `0xe17C9b9C66FAF07753cdB04316D09f52144612A5`
- Gas Oracle
- - L2 Gas Oracle (deployed on Sepolia): `0x247969F4fad93a33d4826046bc3eAE0D36BdE548`
+ - L2 Gas Oracle (Implementado en Sepolia): `0x247969F4fad93a33d4826046bc3eAE0D36BdE548`
### L2 Predeploys
@@ -61,7 +62,7 @@ import Aside from "../../../../components/Aside.astro"
- WETH L2: `0x5300000000000000000000000000000000000004`
- Transaction Fee Vault: `0x5300000000000000000000000000000000000005`
-## Protocols on Sepolia
+## Protocolos en Sepolia
### Uniswap v3
@@ -83,17 +84,17 @@ import Aside from "../../../../components/Aside.astro"
### Aave
-See this [Github gist](https://gist.github.com/dghelm/7fe68f0a524f30846e1142721c081d84).
+Observa este [Github gist](https://gist.github.com/dghelm/7fe68f0a524f30846e1142721c081d84).
-## Additional Useful Contracts
+## Contratos Útiles Adicionales
- Multicall3: `0xcA11bde05977b3631167028862bE2a173976CA11`
## Tokens
- Bridged tokens from Sepolia using the native bridge can be added to the
- [token-list](https://github.com/scroll-tech/token-list) repo.
+ Los tokens transferidos desde Sepolia utilizando el bridge nativo pueden añadirse al repositorio
+ [token-list](https://github.com/scroll-tech/token-list).
- Gho Token: `0xD9692f1748aFEe00FACE2da35242417dd05a8615`
diff --git a/src/content/docs/es/developers/transaction-fees-on-scroll.mdx b/src/content/docs/es/developers/transaction-fees-on-scroll.mdx
index f9c4a48ea..22385a8f5 100644
--- a/src/content/docs/es/developers/transaction-fees-on-scroll.mdx
+++ b/src/content/docs/es/developers/transaction-fees-on-scroll.mdx
@@ -1,106 +1,106 @@
---
section: developers
date: Last Modified
-title: "Transaction Fees on Scroll"
-lang: "en"
+title: "Comisiones de Transacciones en Scroll"
+lang: "es"
permalink: "developers/transaction-fees-on-scroll"
-whatsnext: { "Contract Deployment Tutorial": "/developers/guides/contract-deployment-tutorial/" }
-excerpt: "Understand how L1 and L2 transaction fees work on Scroll "
+whatsnext: { "Tutorial de Despliegue de Contratos": "/es/developers/guides/contract-deployment-tutorial" }
+excerpt: "Aprende cómo funcionan las comisiones de las transacción en L1 y L2 de Scroll "
---
import Aside from "../../../../components/Aside.astro"
-## Overview
+## Vista General
-Scroll Sepolia Testnet fees are notably lower than on its supporting layer. For users and developers, transaction fees on Scroll appear to work similarly to those on Ethereum mainnet, and existing tools, wallets, and code will likely work as if they were. However, the transaction fee shown in the wallet isn't the whole picture unless the software is specifically aware of Scroll's fee calculations.
+Las comisiones de Scroll Sepolia Testnet son notablemente inferiores a las de su capa de soporte. Para usuarios y desarrolladores, las comisiones por transacción en Scroll parecen funcionar de forma similar a las de la mainnet de Ethereum, y las herramientas, wallets y código existentes probablemente funcionarán como si lo fueran. Sin embargo, la comisión por transacción que se muestra en el monedero no es la imagen completa, a menos que el software conozca específicamente los cálculos de comisiones de Scroll.
-Due to the design of L2 rollups, transaction costs depend on the L1's costs. To leverage Ethereum's security, Scroll must account for the cost of the transaction data and proofs that must be stored and verified on the L1.
+Debido al diseño de los rollups L2, los costes de transacción dependen de los costes del L1. Para aprovechar la seguridad de Ethereum, Scroll debe tener en cuenta el coste de los datos de las transacciones y las pruebas que deben almacenarse y verificarse en la L1.
-Compared to Ethereum mainnet, Scroll Sepolia introduces some new dimensions to transaction fee calculation to do this. The final cost of a transaction is constructed from several parts:
+En comparación con la mainnet de Ethereum, Scroll Sepolia introduce algunas nuevas dimensiones en el cálculo de la comisión de transacción para hacer esto. El coste final de una transacción se construye a partir de varias partes:
-- **L2 fee**
- - Calculated in the same manner as on the L1, equaling `gas_price * gas_used`
-- **L1 fee**
- - This additional fee covers sending data to L1 for data availability. Transactions initiated on the L1 do not pay this fee.
- - It is calculated based on the size of the transaction's calldata
- - ETH is automatically deducted from the user’s balance on Scroll for the fee
+- **Comisión L2**
+ - Calculada de la misma manera que en la L1, igual a `gas_price * gas_used`.
+- **Comisión L1**
+- Esta comisión adicional cubre el envío de datos al L1 para la disponibilidad de datos. Las transacciones iniciadas en el L1 no pagan esta comisión.
+ - Se calcula en función del tamaño de los datos de llamada de la transacción.
+ - ETH se deduce automáticamente del saldo del usuario en Scroll para el pago de comisión
-At a high level, the **L2 fee** is the cost of executing your transaction on the L2 sequencer, and the **L1 fee** is the cost of committing that transaction onto L1.
+A un alto nivel, la **comisión L2** es el coste de ejecutar su transacción en el secuenciador L2, y la **comisión L1** es el coste de comprometer esa transacción en L1.
-In short, `totalTxFee = l2Fee + l1Fee`, all denominated in ETH, the native gas token for the Scroll network.
+En resumen, `totalTxFee = l2Fee + l1Fee`, todo ello denominado en ETH, el token de gas nativo de la red Scroll.
-
-All tx fees are collected into the `L2ScrollFeeVault` contract balance. This contract also tracks the amount we’ve historically withdrawn to L1 using `totalProcessed()(uint256)`.
+
+Todas las comisiones de transferencia se recogen en el saldo del contrato `L2ScrollFeeVault`. Este contrato también realiza un seguimiento de la cantidad que hemos retirado históricamente a L1 utilizando `totalProcessed()(uint256)`.
-The block producer receives no direct reward, and the `COINBASE` opcode returns the fee vault address.
+El productor del bloque no recibe ninguna recompensa directa, y el opcode `COINBASE` devuelve la dirección de la vault de la comisión.
-## L2 Fee
+## Comisiones de L2
-Transactions on Scroll, like on Ethereum, must pay the cost of executing their computations and storing the data they produce.
+Las transacciones en Scroll, como en Ethereum, deben pagar el coste de ejecutar sus cálculos y almacenar los datos que producen.
-### Calculating the Execution Fee
+### Cálculo de la comisión de ejecución
-The L2 execution fee is straightforward:
+La comisión de ejecución L2 es sencilla:
```javascript
l2TransactionExecutionFee = l2TransactionGasUsed * l2TransactionGasPrice
```
-The total fee depends on what the transaction does (`l2TransactionGasUsed`) as well as the current market conditions (`l2TransactionGasPrice`). Users set the gas price, and the "gas used" is assessed by calling the `estimateGas` endpoint on a Scroll node.
+La comisión total depende de lo que haga la transacción (`l2TransactionGasUsed`), así como de las condiciones actuales del mercado (`l2TransactionGasPrice`). Los usuarios fijan el precio del gas, y el "gas utilizado" se evalúa llamando al endpoint `estimateGas` en un nodo Scroll.
-In other words, the execution fee is calculated precisely like pre-[EIP1559](https://eips.ethereum.org/EIPS/eip-1559) Ethereum.
+En otras palabras, la comisión de ejecución se calcula exactamente igual que antes de [EIP1559](https://eips.ethereum.org/EIPS/eip-1559) Ethereum.
-## L1 Fee
+## Comisiones de L1
-Every transaction's calldata must be committed to Ethereum, which incurs an additional transaction fee, referred to as the "L1 Fee". Without doing this, Scroll couldn't be reconstructed from only L1 data.
+La calldata de cada transacción deben confirmarse en Ethereum, lo que conlleva una comisión adicional por transacción, denominada "comisión L1". De lo contrario, no se podría reconstruir Scroll a partir únicamente de datos L1.
-Transactions aren't committed 1-by-1 -- they are collected in batches of blocks (and blocks of transactions). The cost of an individual transaction is computed based on the zeros and non-zero bytes in its payload.
+Las transacciones no se consignan de 1 en 1, sino en lotes de bloques (y bloques de transacciones). El coste de una transacción individual se calcula en función de los bytes ceros y no ceros de su payload.
-### Estimating the L1 Data Fee
+### Estimación de la Comisión de Datos L1
-Scroll has a pre-deployed `L1GasPriceOracle`, accessible on Scroll Sepolia at ([`0x5300000000000000000000000000000000000002`](https://sepolia-blockscout.scroll.io/address/0x5300000000000000000000000000000000000002)). It provides a `getL1Fee` method to estimate the L1 data fee for a given transaction's raw data.
+Scroll tiene un `L1GasPriceOracle` pre-desplegado, accesible en Scroll Sepolia en ([`0x5300000000000000000000000000000000000000000000000002`](https://sepolia-blockscout.scroll.io/address/0x5300000000000000000000000000000000000002)). Proporciona un método `getL1Fee` para estimar la comisión de datos L1 para la raw data de una transacción dada.
```solidity
function getL1Fee(bytes memory _data) external view override returns (uint256);
```
-
+
-Once the sequencer has processed a transaction, a user's L1 fee is locked in, and any fluctuations will not affect what a user pays.
+Una vez que el secuenciador ha procesado una transacción, la comisión de L1 de un usuario queda bloqueada, y cualquier fluctuación no afectará a lo que paga el usuario.
-Because of Scroll's short block times, any L1 gas changes between a transaction's submission and its inclusion in a block
-should be minimal. The sequencer will absorb any changes to L1 gas costs between a transaction's inclusion in a block and
-when the sequencer commits the data to L1.
+Debido a los cortos tiempos de bloque de Scroll, cualquier cambio de gas L1 entre el envío de una transacción y su inclusión en un bloque
+debería ser mínimo. El secuenciador absorberá cualquier cambio en los costes de gas L1 entre la inclusión de una transacción en un bloque y
+cuando el secuenciador consigna los datos en L1.
-### Calculating the L1 Data Fee with Gas Oracle
+### Cálculo de la Comisión de Datos L1 con Gas Oracle
-As mentioned, the `L1GasPriceOracle` is used to estimate the L1 gas fee given raw transaction data. This is a **push oracle**, updated by a relayer run by Scroll.
+Como ya se ha mencionado, el `L1GasPriceOracle` se utiliza para estimar la comisión de gas L1 dados la raw data de la transacción. Se trata de un **push oracle**, actualizado por un relayer ejecutado por Scroll.
-The data fee is based on multiple factors:
+La tarifa de datos se basa en múltiples factores:
-- The bytes which are `zeros` and `nonzeros` of an RLP-encoded transaction with Signature
-- `l1BaseFee` - Current base fee on the L1
-- `overhead` - Additional gas overhead of a data commitment transaction
-- `scalingFactor` - A scaling factor used to account for price spikes
-- `PRECISION` - A constant used to scale the final fee
+- Los bytes que son `ceros` y `no ceros` de una transacción codificada RLP con Firma
+- `l1BaseFee` - Comisión base actual en el L1
+- `overhead` - Sobrecarga de gas adicional de una transacción de compromiso de datos
+- `scalingFactor` - Factor de escala utilizado para tener en cuenta los picos de precios.
+- `PRECISION` - Constante utilizada para escalar la comisión final
-The following steps are taken to calculate the L1 data fee:
+Para calcular la comisión por datos L1 se realizan los siguientes pasos:
-1. Read three fields `l1BaseFee`, `overhead`, `scalar` from the `L1GasPriceOracle` contract. The slots for these fields in the contract are:
+1. Se leen tres campos `l1BaseFee`, `overhead`, `scalar` del contrato `L1GasPriceOracle`. Los slots para estos campos en el contrato son:
- | Field | Slot |
+ | Campo | Slot |
| --------- | ---- |
| l1BaseFee | 1 |
| overhead | 2 |
| scalar | 3 |
-2. Count the number of zero bytes and non-zero bytes from the transaction.
-3. Calculate the L1 data fee, given `TX_DATA_ZERO_GAS = 4` and `TX_DATA_NON_ZERO_GAS = 16`[^eip-2028] and `PRECISION = 1e9`:
+2. Se cuenta el número de bytes cero y bytes no cero de la transacción.
+3. Se Calcula la comisión de datos L1, dados `TX_DATA_ZERO_GAS = 4` y `TX_DATA_NON_ZERO_GAS = 16`[^eip-2028] y `PRECISION = 1e9`:
```javascript
l1Gas = zeros * TX_DATA_ZERO_GAS + (nonzeros + 4) * TX_DATA_NON_ZERO_GAS
@@ -109,9 +109,9 @@ The following steps are taken to calculate the L1 data fee:
We reserve an additional 4 bytes in the non-zero bytes to store the number of bytes in the RLP-encoded transaction.
-[^eip-2028]: See [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) for more info.
+[^eip-2028]: Para más información, véase [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028).
-### L1GasPriceOracle API
+### API de L1GasPriceOracle
#### overhead
@@ -119,7 +119,7 @@ The following steps are taken to calculate the L1 data fee:
function overhead() external view returns (uint256);
```
-Returns the current L1 fee overhead
+Devuelve el exceso de comisión L1 actual
#### scalar
@@ -127,7 +127,7 @@ Returns the current L1 fee overhead
function scalar() external view returns (uint256);
```
-Returns the current l1 fee scalar
+Devuelve el escalar de comisión l1 actual
#### l1BaseFee
@@ -135,7 +135,7 @@ Returns the current l1 fee scalar
function l1BaseFee() external view returns (uint256);
```
-Returns the latest known l1 base fee
+Devuelve la última comisión base l1 conocida
#### getL1Fee
@@ -143,13 +143,13 @@ Returns the latest known l1 base fee
function getL1Fee(bytes memory _data) external view returns (uint256);
```
-Computes the L1 portion of the fee based on the size of the RLP encoded input transaction, the current L1 base fee, and the various dynamic parameters.
+Calcula la parte L1 de la comisión en función del tamaño de la transacción de entrada codificada en RLP, la comisión base L1 actual y los distintos parámetros dinámicos.
-**Returns:** L1 fee that should be paid for the transaction
+**Devuelve:** La comisión de L1 que debe pagarse por la transacción
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ----------------------------------------------------------- |
-| data | Signed fully RLP-encoded transaction to get the L1 fee for. |
+| data | Transacción firmada totalmente codificada en RLP para obtener la comisión de L1. |
#### getL1GasUsed
@@ -157,18 +157,18 @@ Computes the L1 portion of the fee based on the size of the RLP encoded input tr
function getL1GasUsed(bytes memory data) external view returns (uint256);
```
-Computes the amount of L1 gas used for a transaction. Adds the overhead which represents the per-transaction gas overhead of posting the transaction and state roots to L1. Adds 74 bytes of padding to account for the fact that the input does not have a signature.
+Calcula la cantidad de gas L1 utilizado para una transacción. Añade el exceso que representa la sobrecarga de gas por transacción de publicar la transacción y las state roots en L1. Añade 74 bytes de relleno para tener en cuenta el hecho de que la entrada no tiene una firma.
-**Returns:** Amount of L1 gas used to publish the transaction.
+**Devuelve:** Cantidad de gas L1 utilizado para publicar la transacción.
-| Parameter | Description |
+| Parámetro | Descripción |
| --------- | ----------------------------------------------------------- |
-| data | Signed fully RLP-encoded transaction to get the L1 fee for. |
+| data | Transacción firmada totalmente codificada en RLP para obtener la comisión L1. |
-## Future Roadmap
+## Roadmap Futuro
-Currently, the computation required for proof generation is completed by and subsidized by Scroll and various proving partners.
+En la actualidad, el cálculo necesario para la generación de pruebas es completado y financiado por Scroll y varios socios.
-As the prover network becomes decentralized, incentives for proof generation will need to be incorporated into the protocol for the system to be sustainable and scalable.
+A medida que la red de probadores se descentralice, será necesario incorporar incentivos a la generación de pruebas en el protocolo para que el sistema sea sostenible y escalable.
-We expect the final gas cost will include the cost of this proof generation. With further protocol optimization, this cost for the user should be minimal, as each proof covers many transactions.
+Esperamos que el coste final del gas incluya el coste de esta generación de pruebas. Con una mayor optimización del protocolo, este coste para el usuario debería ser mínimo, ya que cada prueba cubre muchas transacciones.
diff --git a/src/content/docs/es/developers/verifying-smart-contracts.mdx b/src/content/docs/es/developers/verifying-smart-contracts.mdx
index aa609eabe..f2f786b1e 100644
--- a/src/content/docs/es/developers/verifying-smart-contracts.mdx
+++ b/src/content/docs/es/developers/verifying-smart-contracts.mdx
@@ -1,11 +1,11 @@
---
section: developers
date: Last Modified
-title: "Verifying Smart Contracts"
-lang: "en"
+title: "Verificando Smart Contracts"
+lang: "es"
permalink: "developers/verifying-smart-contracts"
-whatsnext: { "Scroll Contracts": "/developers/scroll-contracts" }
-excerpt: "Easily verify your smart contracts with Scroll-supported developer tooling or the Blockscout Web API"
+whatsnext: { "Scroll Contracts": "/es/developers/scroll-contracts" }
+excerpt: "Verifique fácilmente sus smart contracts con herramientas para desarrolladores compatibles con Scroll o con la Blockscout Web API."
---
import Aside from "../../../../components/Aside.astro"
@@ -13,21 +13,20 @@ import ClickToZoom from "../../../../components/ClickToZoom.astro"
import verify1 from "./_images/verify1.png"
import CodeSample from "../../../../components/CodeSample/CodeSample.astro"
-After deploying your smart contracts, it's important to verify your code on [our block explorer](https://sepolia-blockscout.scroll.io/). This can be done in an automated way using your developer tooling or using Blockscout's Web UI.
+Después de desplegar tus smart contracts, es importante verificar tu código en [nuestro block explorer](https://sepolia-blockscout.scroll.io/). Esto se puede hacer de forma automatizada utilizando tus herramientas de desarrollo o la IU web de Blockscout.
-
- Our Blockscout instance currently has inconsistent behavior in verifying contracts with Foundry. We're working on a
- fix, along with other stability improvements. Don't hesitate to come ask for help [on
- Discord](https://discord.com/channels/853955156100907018/1028102371894624337) though.
+
+ Nuestra instancia de Blockscout tiene actualmente un comportamiento inconsistente en la verificación de contratos con Foundry. Estamos trabajando en
+ junto con otras mejoras de estabilidad. No dudes en pedir ayuda en [nuestro
+ Discord](https://discord.com/channels/853955156100907018/1028102371894624337)
-## Using Developer Tools
-
-Most smart contract tooling has plugins for verifying your contracts easily on Etherscan. Blockscout supports Etherscan's contract verification APIs, and it's straightforward to use these tools with the Scroll Sepolia Testnet.
+## Uso de las herramientas para desarrolladores
+La mayoría de las herramientas de smart contracts tienen plugins para verificar tus contratos fácilmente en Etherscan. Blockscout soporta las APIs de verificación de contratos de Etherscan, y es sencillo utilizar estas herramientas con la Scroll Sepolia Testnet.
### Hardhat
-First, modify `hardhat.config.ts` to point to Scroll's RPC and `sepolia-blockscout.scroll.io/api`. A dummy `apyKey` value is required, but anything works for its value.
+Primero, modifica `hardhat.config.ts` para que apunte al RPC de Scroll y a `sepolia-blockscout.scroll.io/api`. Se requiere un valor `apyKey` ficticio, pero cualquier cosa sirve como valor.
```javascript
...
@@ -61,27 +60,27 @@ const config: HardhatUserConfig = {
...
```
-Now you can verify the smart contract by running the following command.
+Ahora puedes verificar el smart contract ejecutando el siguiente comando.
```solidity
npx hardhat verify --network scrollSepolia
```
-For example, this is how a smart contract that receives two uint parameters in the constructor should look:
+Por ejemplo, así es como debería verse un smart contract que recibe dos parámetros uint en el constructor:
```solidity
npx hardhat verify --network scrollSepolia 0xD9880690bd717189cC3Fbe7B9020F27fae7Ac76F 123 456
```
-
- You may receive an error stating `etherscan.apiKey.trim is not a function` . If so, you need to update
- `@nomiclabs/hardhat-etherscan` to be able to support custom chains. Try running `npm update
- @nomiclabs/hardhat-etherscan`
+
+ Es posible que reciba un error que indica que `etherscan.apiKey.trim no es una función` . Si es así, es necesario actualizar
+ `@nomiclabs/hardhat-etherscan` para poder soportar cadenas personalizadas. Intenta ejecutar `npm update
+ @nomiclabs/hardhat-etherscan`.
### Foundry
-When using Foundry, the `verify-contract` helps automate the process of verifying contracts.
+Cuando se utiliza Foundry, la función `verify-contract` ayuda a automatizar el proceso de verificación de los contratos.
```bash
forge verify-contract : --chain-id 534351 --verifier-url --verifier blockscout
diff --git a/src/content/docs/es/getting-started/overview.md b/src/content/docs/es/getting-started/overview.md
index 72be95150..f0c3c474a 100644
--- a/src/content/docs/es/getting-started/overview.md
+++ b/src/content/docs/es/getting-started/overview.md
@@ -1,43 +1,44 @@
---
section: gettingStarted
date: Last Modified
-title: "Scroll Overview"
-lang: "en"
+title: "Vista General de Scroll"
+lang: "es"
permalink: "docs/conceptual-overview/"
excerpt: "ZK Rollups and Scroll"
-whatsnext: { "User Guide": "/user-guide/", "Building on Scroll": "/developers/" }
+whatsnext: { "Guía de Usuario": "/es/user-guide/", "Construyendo en Scroll": "/es/developers/" }
---
-#### Welcome to the Scroll docs!
+#### Bienvenido a la documentación de Scroll!
-Scroll is a security-focused scaling solution for Ethereum, using innovations in scaling design and zero-knowledge proofs to build a new layer on Ethereum. The Scroll network is more accessible, more responsive, and can support more users at once than Ethereum alone, and if you've ever used or developed an application on Ethereum, you'll be right home on Scroll.
+Scroll es una solución de escalabilidad centrada en la seguridad de Ethereum, que utiliza innovaciones en el diseño de escalado y pruebas de “zero-knowledge” para construir una nueva capa en Ethereum. La red de Scroll es más accesible, más receptiva y puede soportar a más usuarios a la vez que Ethereum por sí solo, y si alguna vez has utilizado o desarrollado una aplicación en Ethereum, te sentirás como en casa.
-Want to try out the Scroll Sepolia testnet? Check out our [User Guide](/user-guide/).
+¿Quieres probar la Scroll Sepolia Testnet? Echa un vistazo a nuestra. [Guía de Usuario](/es/user-guide/).
-## What is Scroll building?
+## ¿Qué está construyendo Scroll?
-Scroll is building the technology to scale Ethereum.
+Scroll está construyendo la tecnología para escalar Ethereum.
-While Ethereum is the leading blockchain network for powering decentralized applications, its popularity also brings higher costs, creating a barrier to adoption for the next wave of users and developers.
+Aunque Ethereum es la principal red blockchain para alimentar aplicaciones descentralizadas, su popularidad también conlleva costos más altos, lo que crea una barrera para la adopción de la próxima ola de usuarios y desarrolladores.
-Leveraging cutting-edge research in zero-knowledge proofs (”zk”), Scroll is building a Layer 2 rollup network on Ethereum. The team, in open-source collaboration with others in the Ethereum community, has created a “zkEVM” that allows for all activity on the network, which behaves just like Ethereum, to be secured by smart contracts _on_ Ethereum. The network publishes all of the transactions to Ethereum, and the zkEVM creates and publishes cryptographic "proofs" that the Scroll network is following the rules of Ethereum.
+Aprovechando investigaciones punteras en pruebas de “zero-knowledge” ("zk"), Scroll está construyendo una red de segunda capa (Layer 2 rollup) en Ethereum. El equipo, en colaboración de código abierto con otros en la comunidad de Ethereum, ha creado un "zkEVM" que permite que toda la actividad en la red, que se comporta de manera similar a Ethereum, esté asegurada por smart contracts en Ethereum. La red publica todas las transacciones en Ethereum, y el zkEVM crea y publica "pruebas" criptográficas de que la red de Scroll sigue las reglas de Ethereum.
-Ultimately, Ethereum smart contracts verify that every transaction on Scroll is valid for these proofs, lending the network incredible security, decentralization, and censorship resistance. This level of security and scalability for Ethereum is only possible with recent breakthroughs in zero-knowledge cryptography, blockchain protocol design, and hardware acceleration.
+En última instancia, los smart contracts de Ethereum verifican que cada transacción en Scroll sea válida para estas pruebas, brindando a la red una increíble seguridad, descentralización y resistencia a la censura. Este nivel de seguridad y escalabilidad para Ethereum solo es posible gracias a avances recientes en criptografía de “zero-knowledge”, diseño de protocolos blockchain y aceleración de hardware.
-For more information on our architecture, see [Scroll Architecture](/technology/).
+Para obtener más información sobre nuestra arquitectura, consulta. [Arquitectura de Scroll](/es/technology/).
-## Can I use Scroll today?
+## ¿Puedo usar Scroll hoy?
-Our Scroll Sepolia testnet is live. Although we have a [comprehensive guide](/user-guide/), if you're familiar with using Ethereum, you can get started in minutes:
+Nuestra Scroll Sepolia testnet está funcionando. Aunque tenemos una [guía completa](/es/user-guide/), si estás familiarizado/a con el uso de Ethereum, puedes comenzar en minutos:
-- Visit our [Bridge](https://scroll.io/bridge) and connect your wallet
-- Send tokens from Sepolia to Scroll Sepolia testnet (or use a [faucet](/user-guide/faucet))
-- Test out a dapp like our [Uniswap Showcase](http://uniswap-showcase.sepolia.scroll.xyz/) -- just be sure to select the Scroll Sepolia network!
+- Visita nuestro [Bridge](https://scroll.io/bridge) y conecta tu wallet
+- Envía tokens de Ethereum Sepolia Testnet a la Scroll Sepolia Testnet
+ (o usa un [faucet](/es/user-guide/faucet))
+- Prueba una aplicación descentralizada (dapp) con nuestra [Uniswap Showcase](http://uniswap-showcase.sepolia.scroll.xyz/) -- ¡solo asegúrate de seleccionar la red Scroll Sepolia!
-## Where is Scroll headed?
+## ¿Hacia dónde se dirige Scroll?
-We're currently in our final testnet before launching our mainnet on Ethereum. Next up -- decentralizing each component of the stack. Check out [our roadmap](https://scroll.io) or follow along in [our Discord](https://discord.gg/scroll) or on [Twitter](https://twitter.com/scroll_zkp).
+Actualmente nos encontramos en nuestra red de pruebas final antes de lanzar nuestra mainnet en Ethereum. A continuación, descentralizaremos cada componente de la infraestructura. Echa un vistazo a [nuestro roadmap](https://scroll.io), síguenos en [nuestro Discord](https://discord.gg/scroll) o en [Twitter](https://twitter.com/scroll_zkp) para estar al tanto.
diff --git a/src/content/docs/es/glossary.md b/src/content/docs/es/glossary.md
new file mode 100644
index 000000000..bbab022a8
--- /dev/null
+++ b/src/content/docs/es/glossary.md
@@ -0,0 +1,59 @@
+---
+section: developers
+date: Last Modified
+title: "English to Spanish Glosary"
+lang: "es"
+permalink: "glossary"
+excerpt: "Translation of English terms into Spanish"
+---
+
+| English | Spanish |
+| ----------------------------------------------- | -------------------------------------------- |
+| Mapping | Mapeo |
+| Bridge | Puente |
+| Token | Token |
+| zero-knowledge Proof | Prueba Conocimiento Cero |
+| Rollup | Rollup |
+| Bytecode | Bytecode |
+| Testnet | Red de Prueba |
+| Smart Contract | Contrato Inteligente |
+| Merge | Merge |
+| Mainnet | Red Principal |
+| Builders | Constructores |
+| RPC | RPC |
+| Faucet | Faucet |
+| Setup | Configuración |
+| Chain ID | Identificador de Cadena |
+| Currency Symbol | Símbolo de Moneda |
+| Block Explorer URL | URL de Explorador de Bloques |
+| HartHat | HartHat |
+| Foundry | Foundry |
+| IDE | Entorno de Desarrollo Integrado |
+| Deploy | Desplegar |
+| Run | Ejecutar |
+| Transactions | Transacciones |
+| Environment | Entorno |
+| Injected Provider | Proveedor de Inyecciones |
+| Truffle | Truffle |
+| Brownie | Brownie |
+| Script | Script |
+| Wallet | Billetera |
+| Frontend | Frontend |
+| IU | Interfaz de Usuario |
+| Plugins | Complementos |
+| API | API |
+| Gateway | Gateway |
+| Router | Enrutador |
+| Scroll | Scroll |
+| Ethereum | Ethereum |
+| Zero-knowledge | Conocimiento cero |
+| Layer 2 rollup | Rollup de capa 2 |
+| Smart contracts | Contratos inteligentes |
+| Mainnet | Red principal |
+| Polynomial commitment scheme | Esquema de compromiso de polinomios |
+| Commitment | Compromiso |
+| Proof of validity | Prueba de validez |
+| Proof of fraud | Prueba de fraude |
+| Optimistic rollup | Rollup optimista |
+| zkVM (Zero-Knowledge Virtual Machine) | Máquina Virtual zk (Zero-Knowledge) |
+| zkEVM (Zero-Knowledge Ethereum Virtual Machine) | Máquina Virtual Ethereum zk (Zero-Knowledge) |
diff --git a/src/content/docs/es/learn/index.mdx b/src/content/docs/es/learn/index.mdx
index 55b8184ed..92b3c1a87 100644
--- a/src/content/docs/es/learn/index.mdx
+++ b/src/content/docs/es/learn/index.mdx
@@ -1,28 +1,28 @@
---
section: learn
-title: "Learn"
-lang: "en"
+title: "Aprende"
+lang: "es"
permalink: "learn/"
excerpt: "Learn more about Ethereum scalability and zero knowledge cryptography."
---
import NavCard from "../../../../components/NavCard.astro"
-Scroll pulls together research and engineering from Blockchain Protocols and Zero Knowledge Cryptography. If you want to dive deeper, keep reading and check out the additional resources.
+Scroll reúne la investigación y la ingeniería de Blockchain Protocols y Criptografía Zero Knowledge. Si quieres profundizar más, sigue leyendo y consulta los recursos adicionales.
-Want to see a specific topic covered? Create [an issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E) in our Github repo.
+¿Desea que se trate un tema específico? Crea [una issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E) en nuestro repositorio de Github.
diff --git a/src/content/docs/es/learn/intro-to-rollups.md b/src/content/docs/es/learn/intro-to-rollups.md
index 68e9b4c19..6b8ac34bb 100644
--- a/src/content/docs/es/learn/intro-to-rollups.md
+++ b/src/content/docs/es/learn/intro-to-rollups.md
@@ -1,51 +1,51 @@
---
section: learn
date: Last Modified
-title: "Intro to Rollups"
-lang: "en"
+title: "Intro a los Rollups"
+lang: "es"
permalink: "learn/intro-to-rollups"
-excerpt: "Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem."
-whatsnext: { "Scroll Rollup Process": "/technology/chain/rollup" }
+excerpt: "Los rollups son la solución de escalado de capa 2 más predominante en el ecosistema Ethereum."
+whatsnext: { "Proceso del Rollup": "/es/technology/chain/rollup" }
---
-## What’s a rollup?
+## ¿Qué es un rollup?
-Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem, and are viewed as a [central part](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) of the Ethereum roadmap.
+Los rollups son la solución de escalado de capa 2 más predominante en el ecosistema Ethereum, y se consideran una [parte central](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) de la hoja de ruta de Ethereum.
-A rollup processes batches of transactions off-chain (i.e. not on layer 1), and then posts the resulting data on-chain (i.e. on layer 1).
+Un rollup procesa lotes de transacciones fuera de la cadena (es decir, no en la capa 1), y luego publica los datos resultantes en la cadena (es decir, en la capa 1).
-The execution of each transaction is performed off-chain, and does not need to be re-executed layer 1 nodes. This allows for high transaction throughput, without impacting the decentralization of layer 1.
+La ejecución de cada transacción se realiza fuera de la cadena, y no es necesario que los nodos de la capa 1 vuelvan a ejecutarla. Esto permite un alto rendimiento de las transacciones, sin afectar a la descentralización de la capa 1.
-In order for a rollup to be secure, it must prove that its off-chain computation (the processing of transactions) was performed correctly. There are predominantly two mechanisms to prove the validity of off-chain computation: validity proofs and fraud proofs.
+Para que un rollup sea seguro, debe demostrar que su cálculo fuera de la cadena (el procesamiento de las transacciones) se ha realizado correctamente. Existen principalmente dos mecanismos para demostrar la validez del cálculo fuera de la cadena: las pruebas de validez y las pruebas de fraude.
-## What’s an optimistic rollup?
+## ¿Qué es un optimistic rollup?
-An optimistic rollup is a rollup that uses fraud proofs to assert the validity of its computation.
+Un optimistic rollup es un rollup que utiliza pruebas de fraude para afirmar la validez de sus cálculos.
-Fraud proofs are a mechanism that allow users to challenge and prove the invalidity of any computation performed on the L2. If a fraud proof is successfully submitted, the L2 can be rolled back to a previous state and the invalid computation can be corrected. Fraud proofs depend on at least one honest party checking that the L2 transactions have been correctly executed.
+Las pruebas de fraude son un mecanismo que permite a los usuarios cuestionar y demostrar la invalidez de cualquier cálculo realizado en el L2. Si una prueba de fraude se presenta con éxito, la L2 puede volver a un estado anterior y el cálculo no válido puede ser corregido. Las pruebas de fraude dependen de que al menos una parte honesta compruebe que las transacciones de la L2 se han ejecutado correctamente.
-## What’s a ZK rollup?
+## ¿Qué es un ZK rollup?
-A ZK rollup is a rollup that uses validity proofs to assert the validity of its computation.
+Un ZK rollup es un rollup que utiliza pruebas de validez para afirmar la legitimidad de sus cálculos.
-When a ZK rollup executes a batch of transactions and posts the resulting state to L1, it also posts a validity proof. This mathematical proof proves that the resulting state is indeed the state which results from correctly executing the batch of transactions.
+Cuando un ZK rollup ejecuta un lote de transacciones y publica el estado resultante en L1, también publica una prueba de validez. Esta prueba matemática demuestra que el estado resultante es efectivamente el estado resultante de ejecutar correctamente el lote de transacciones.
-Today, there are multiple types of ZK rollups, broadly defined as either zkVMs (zk Virtual Machines) or zkEVMs (zk Ethereum Virtual Machines).
+En la actualidad, existen múltiples tipos de ZK rollups, definidos en términos generales como zkVMs (zk Virtual Machines) o zkEVMs (zk Ethereum Virtual Machines).
-zkVMs are designed from the ground up to work well with ZK circuits and require different development workflows compared to a zkEVM. Some examples of these include Starkware and Aztec.
+Los zkVMs están diseñados desde cero para trabajar bien con circuitos ZK y requieren diferentes flujos de trabajo de desarrollo en comparación con un zkEVM. Algunos ejemplos son Starkware y Aztec.
-zkEVMs are designed to emulate the EVM. There are two major types of zkEVMs: bytecode-compatible, and language-compatible. Bytecode-compatible zkEVMs emulate the EVM at a very low level, allowing for a near-identical development and user experience compared to Ethereum Layer 1. Language-compatible zkEVMs compile Solidity and other high-level languages down into different bytecode, which can result in changes to workflow. zkSync is the most popular language-compatible zkEVM.
+Los zkEVMs están diseñados para emular la EVM. Existen dos tipos principales de zkEVMs: compatibles con bytecode y compatibles con lenguaje. Las zkEVM compatibles con bytecode emulan la EVM a un nivel muy bajo, permitiendo un desarrollo y una experiencia de usuario casi idénticos en comparación con Ethereum Layer 1. Los zkEVMs compatibles con lenguajes compilan Solidity y otros lenguajes de alto nivel en diferentes bytecodes, lo que puede resultar en cambios en el flujo de trabajo. zkSync es el zkEVM compatible con lenguajes más popular.
-Scroll is bytecode-compatible. This approach was chosen because it brings certain benefits:
+Scroll es compatible con bytecode. Se eligió este enfoque porque aporta ciertas ventajas:
-- Solidity, Vyper, and Huff work out of the box
-- No re-auditing necessary
-- Most existing tooling is inherited
-- Near-identical UX and DevX as Ethereum
+- Solidity, Vyper y Huff funcionan desde el primer momento.
+- No es necesario volver a auditar
+- Se hereda la mayoría de las herramientas existentes
+- UX y DevX casi idénticos a los de Ethereum.
-More detail on Scroll’s approach is found in the Technology section.
+Encontrará más información sobre el enfoque de Scroll en la sección Tecnología.
-## Further reading
+## Lecturas adicionales
- [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html) - Vitalik Buterin
- [Scaling](https://ethereum.org/en/developers/docs/scaling/) - Ethereum Docs
diff --git a/src/content/docs/es/learn/the-scalability-problem.md b/src/content/docs/es/learn/the-scalability-problem.md
index 984d28c29..470401d81 100644
--- a/src/content/docs/es/learn/the-scalability-problem.md
+++ b/src/content/docs/es/learn/the-scalability-problem.md
@@ -1,27 +1,27 @@
---
section: learn
date: Last Modified
-title: "The Scalability Problem"
-lang: "en"
+title: "El Problema de la Escalabilidad"
+lang: "es"
permalink: "learn/intro-to-rollups"
-excerpt: "Ethereum’s strong decentralization and security come at the cost of sacrificing scalability: to ensure that all the participating nodes can keep up with the network, the network’s throughput is limited. This limit ultimately results in higher costs and latencies for users."
-whatsnext: { "Intro to Rollups": "/learn/intro-to-rollups" }
+excerpt: "La fuerte descentralización y seguridad de Ethereum se consigue a costa de sacrificar la escalabilidad: para garantizar que todos los nodos participantes puedan seguir el ritmo de la red, el rendimiento de ésta es limitado. Este límite se traduce en costes y latencias más elevados para los usuarios."
+whatsnext: { "Intro a los Rollups": "/es/learn/intro-to-rollups" }
---
-## Ethereum’s scaling problem
+## El problema de escalabilidad de Ethereum
-[Ethereum](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) is a general-purpose blockchain that supports the deployment and execution of [smart contracts](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts).
+[Ethereum](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) es una blockchain de propósito general que soporta el despliegue y ejecución de [smart contracts](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts).
-One of the defining features of Ethereum is its unwavering commitment to security and decentralization. Ethereum is designed such that computers all across the world (even cheap ones, like a [Raspberry Pi](https://ethereum-on-arm-documentation.readthedocs.io/)) can participate in the network, running local copies of the blockchain and processing new transactions.
+Una de las características que definen a Ethereum es su compromiso inquebrantable con la seguridad y la descentralización. Ethereum está diseñado para que ordenadores de todo el mundo (incluso los más baratos, como una [Raspberry Pi](https://ethereum-on-arm-documentation.readthedocs.io/)) puedan participar en la red, ejecutar copias locales de la blockchain y procesar nuevas transacciones.
-However, Ethereum’s strong decentralization and security come at the cost of sacrificing scalability: to ensure that all the participating nodes can keep up with the network, the network’s throughput is limited. This limit ultimately results in higher costs and latencies for users.
+Sin embargo, la fuerte descentralización y seguridad de Ethereum se consigue a costa de sacrificar la escalabilidad: para garantizar que todos los nodos participantes puedan seguir el ritmo de la red, el rendimiento de ésta es limitado. En última instancia, este límite se traduce en mayores costes y latencias para los usuarios.
-## Scaling solutions
+## Soluciones de Escalabilidad
-Ethereum’s scaling solutions aim to increase the throughput of the network without sacrificing decentralization or security.
+Las soluciones de escalabilidad de Ethereum tienen como objetivo aumentar el rendimiento de la red sin sacrificar la descentralización o la seguridad.
-There are primarily two types of scaling solutions: layer 1 scaling solutions and layer 2 scaling solutions.
+Existen principalmente dos tipos de soluciones de escalado: soluciones de escabilidad de capa 1 y soluciones de escabilidad de capa 2.
-**Layer 1** (or **L1**) scaling solutions attempt to scale the network by making modifications to the Ethereum blockchain directly. The term “layer 1” here refers to the main Ethereum blockchain. In general, it is very difficult to design layer 1 scaling solutions that increase throughput and at the same time preserve high levels of security and decentralization. Thus, recent scaling efforts have shifted away from layer 1 solutions and towards layer 2 solutions.
+**La Capa 1** (o **L1**) intenta escalar la red modificando directamente la blockchain de Ethereum. El término "capa 1" se refiere aquí a la cadena de bloques principal de Ethereum. En general, es muy difícil diseñar soluciones de escalado de capa 1 que aumenten el rendimiento y, al mismo tiempo, preserven altos niveles de seguridad y descentralización. Por ello, los recientes esfuerzos de escalado se han alejado de las soluciones de capa 1 y se han orientado hacia soluciones de capa 2.
-**Layer 2** (or **L2**) scaling solutions are networks that live **on top** of Ethereum layer 1 - they are essentially separate blockchains which are “anchored” to the underlying Ethereum blockchain in some way. These layer 2 networks can generally process transactions at a higher rate than the underlying layer 1 network, as they are not subject to the same limitations. The “anchoring” mechanism, the specifics of which differ across various layer 2s, enables the layer 2 network to inherit the strong security and decentralization properties of Ethereum layer 1.
+**La Capa 2** (o **L2**) de soluciones de escalado son redes que viven **en la parte superior** de la capa 1 de Ethereum - son esencialmente blockchains separadas que están "ancladas" a la blockchain subyacente de Ethereum de alguna manera. Estas redes de capa 2 generalmente pueden procesar transacciones a un ritmo mayor que la red de capa 1 subyacente, ya que no están sujetas a las mismas limitaciones. El mecanismo de "anclaje", cuyos detalles varían según la capa 2, permite a la red de capa 2 heredar las sólidas propiedades de seguridad y descentralización de la capa 1 de Ethereum.
diff --git a/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md
index adf1558b5..415705887 100644
--- a/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md
+++ b/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md
@@ -1,26 +1,26 @@
---
section: learn
date: Last Modified
-title: "Additional ZK Learning Resources"
-lang: "en"
+title: "Recursos de Aprendizaje ZK Adicionales"
+lang: "es"
permalink: "learn/zero-knowledge/additional-zk-learning-resources"
-excerpt: "Looking to dive deeper into ZK? Here are some of our favorite resources."
+excerpt: "¿Quieres profundizar en ZK? Éstos son algunos de nuestros recursos favoritos."
---
-Looking to dive deeper into ZK? Here are some of our favorite resources.
+¿Quieres profundizar en el ZK? Aquí tienes algunos de nuestros recursos favoritos.
-## Video
+## Vídeo
- [ZK Whiteboard Sessions](https://youtube.com/playlist?list=PLj80z0cJm8QErn3akRcqvxUsyXWC81OGq)
- - These whiteboard sessions are a fantastic way to learn about ZK. The first three lectures by Dan Boneh provide a great foundational understanding, on which the following lectures build, discussing more recent developments.
+ - Estas sesiones de whiteboard son una forma fantástica de aprender sobre ZK. Las tres primeras conferencias de Dan Boneh proporcionan una gran base sobre la que se construyen las siguientes, en las que se analizan los desarrollos más recientes.
- [Zero Knowledge Proofs MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs)
- - A MOOC that covers zero knowledge proofs from first principles, all the way to modern industry topics.
+ - Un MOOC que cubre las pruebas zero knowledge desde los primeros principios, hasta los temas modernos de la industria.
- [The 9th BIU Winter School on Cryptography - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K)
- - These lectures lay the theoretical foundations for zero knowledge - they are targeted towards academics and audiences with mathematical maturity.
+ - Estas conferencias sientan las bases teóricas zero knowledge - están dirigidas a académicos y público con madurez matemática.
- [ZK Symposium](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY)
- - A mix of applied and theoretical presentations from some of the top researchers and product builders in the zero-knowledge space.
+ - Una mezcla de presentaciones teóricas y aplicadas de algunos de los mejores investigadores y creadores de productos en el ámbito zero-knowledge.
-## Text
+## Texto
- [Proofs, Arguments, and Zero-Knowledge](https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html) - Justin Thaler
- - A comprehensive textbook on the theory of zero-knowledge.
+ - Un libro de texto completo sobre la teoría zero-knowledge.
diff --git a/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx
index 58ef7edeb..16a0ad857 100644
--- a/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx
+++ b/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx
@@ -1,75 +1,75 @@
---
section: learn
date: Last Modified
-title: "Introduction to Zero Knowledge"
-lang: "en"
+title: "Introducción a Zero Knowledge"
+lang: "es"
permalink: "learn/zero-knowledge/introduction-to-zero-knowledge"
-whatsnext: { "Polynomial Commitment Schemes": "/learn/zero-knowledge/polynomial-commitment-schemes" }
-excerpt: 'Over the past decade, a field of cryptography called "zero-knowledge" has been rapidly advancing. It promises new ways to build applications and enables protocols to increase efficiency, security, and privacy.'
+whatsnext: { "Polynomial Commitment Schemes": "/es/learn/zero-knowledge/polynomial-commitment-schemes" }
+excerpt: 'En la última década, un campo de la criptografía llamado "zero-knowledge" ha avanzado rápidamente. Promete nuevas formas de crear aplicaciones y permite que los protocolos aumenten la eficacia, la seguridad y la privacidad.'
---
import Aside from "../../../../../components/Aside.astro"
-Over the past decade, a field of cryptography called "zero-knowledge" has been rapidly advancing. It promises new ways to build applications and enables protocols to increase efficiency, security, and privacy.
+En la última década, un campo de la criptografía llamado "zero-knowledge" ha avanzado rápidamente. Promete nuevas formas de crear aplicaciones y permite que los protocolos aumenten la eficacia, la seguridad y la privacidad.
-Let's look at what makes the field of zero-knowledge proofs so exciting and what problems it helps engineers solve.
+Examinemos qué hace que el campo de las pruebas "zero-knowledge" sea tan interesantes y qué problemas ayuda a resolver a los ingenieros.
-## Trustless Blockchains & Verifiability
+## Blockchains Trustless y Verificabilidad
-Blockchains generally work by processing transactions submitted by users. These transactions usually trigger some computation for the blockchain to perform.
+Las blockchains suelen funcionar procesando transacciones enviadas por los usuarios. Estas transacciones suelen desencadenar algún tipo de cálculo que la blockchain debe realizar.
-For the blockchain to be trustless (i.e. not reliant on trusting some individual party), participants in the network must verify that transactions are valid and that their resulting computations were performed correctly.
+Para que la blockchain sea "trustless" (es decir, no dependa de la confianza en una parte concreta), los participantes en la red deben verificar que las transacciones son válidas y que los cálculos resultantes se han realizado correctamente.
-Verifying that the transaction is valid generally requires digital signature verification - this verifies that the transaction’s reported sender is indeed the author of the transaction. Verifying that a transaction’s computation was performed correctly generally requires re-executing the transaction locally.
+Comprobar que la transacción es válida suele requerir la verificación de la firma digital, que comprueba que el remitente de la transacción es realmente el autor de la misma. La verificación de que el cálculo de una transacción se ha realizado correctamente suele requerir la reejecución local de la transacción.
-## Limitations to Verifiability
+## Limitaciones de la Verificabilidad
-This methodology of verifying each transaction breaks down in situations where a participant can’t rerun the computation. A participant may not be able to re-execute the computation for a couple of reasons: (1) it could be that certain data shouldn’t be made available (for privacy reasons), or (2) it may be too expensive for a participating computer to re-execute all the transactions - this second reason is especially relevant when considering high-throughput blockchains with a large number of transactions per second.
+Esta metodología de verificación de cada transacción se rompe en situaciones en las que un participante no puede volver a ejecutar el cálculo. Un participante puede no ser capaz de volver a ejecutar el cálculo por un par de razones: (1) podría ser que ciertos datos no estén disponibles (por razones de privacidad), o (2) puede ser demasiado caro para un ordenador participante volver a ejecutar todas las transacciones - esta segunda razón es especialmente relevante cuando se consideran blockchains de alto rendimiento con un gran número de transacciones por segundo.
-## The Power of Zero-Knowledge Proofs
+## El Poder de las Zero-Knowledge Proofs
-Zero-knowledge proofs (ZKPs) have the power to overcome these limitations.
+Las Zero-knowledge proofs (ZKP) permiten superar estas limitaciones.
-ZKPs allow participants to verify the results of a computation while (1) preserving the privacy of any sensitive data used in the computation, and (2) having the verification be significantly cheaper than re-executing the computation. These two properties of ZKPs are called **zero-knowledge** and **succinctness**, respectively.
+Las ZKP permiten a los participantes verificar los resultados de un cálculo (1) preservando la privacidad de cualquier dato sensible utilizado en el cálculo, y (2) haciendo que la verificación sea significativamente más barata que volver a ejecutar el cálculo. Estas dos propiedades de las ZKP se denominan **zero-knowledge** y **succinctness**, respectivamente.
-The above properties of ZKPs are extremely useful in the context of verifiability for trustless blockchains. Without ZKPs, participants need to re-execute every transaction’s resulting computation. This requires all participants to see all the (potentially sensitive) data used in each computation, and it also limits the throughput of the entire system. With ZKPs, one party can perform the computation, and then generate a proof that the computation was performed correctly. Other participants can verify that the computation was performed correctly by _verifying that the proof is valid_, rather than re-executing the computation themselves. Verifying the proof (1) does not leak information about sensitive data used in the original computation, and (2) is significantly computationally cheaper than re-executing the original computation. These two properties have the potential to enable privacy and scalability for trustless blockchains.
+Estas propiedades de las ZKP son extremadamente útiles en el contexto de la verificabilidad de las blockchains "trustless". Sin ZKP, los participantes tienen que volver a ejecutar el cálculo resultante de cada transacción. Esto requiere que todos los participantes vean todos los datos (potencialmente sensibles) utilizados en cada cálculo, y también limita el rendimiento de todo el sistema. Con las ZKP, una parte puede realizar el cálculo y, a continuación, generar una prueba de que el cálculo se ha realizado correctamente. Otros participantes pueden verificar que el cálculo se ha realizado correctamente _verificando que la prueba es válida_, en lugar de volver a ejecutar el cálculo ellos mismos. Verificar la prueba (1) no filtra información sobre datos sensibles utilizados en el cálculo original, y (2) es significativamente más barato computacionalmente que volver a ejecutar el cálculo original. Estas dos propiedades tienen el potencial de permitir la privacidad y la escalabilidad de las blockchains trustless.
-## Circuits, Proofs, and Verifiers
+## Circuitos, Pruebas y Verificadores
-In practice, ZKPs can be quite complex to implement into a system, but at a high level, you’ll want to understand that zero-knowledge proofs have a few components: a circuit, a proof, and a verifier.
+En la práctica, las ZKP pueden ser bastante complejas de implementar en un sistema, pero a un alto nivel, usted querrá entender que las pruebas de zero-knowledge tienen unos pocos componentes: un circuito, una prueba y un verificador.
-The circuit is a program that takes in input data, and asserts that the input data is valid according to some “constraints” that the input data must satisfy. The input data can be public (known to everyone), private (know to only the prover), or mixed (some inputs are public and some are private).
+El circuito es un programa que recibe datos de entrada y afirma que los datos de entrada son válidos de acuerdo con algunas "restricciones" que los datos de entrada deben satisfacer. Los datos de entrada pueden ser públicos (conocidos por todos), privados (conocidos sólo por el verificador) o mixtos (algunos datos de entrada son públicos y otros privados).
-A proof can be generated, claiming that an input satisfies the circuit. The proof reveals no information about the private inputs, and is quite small in size.
+Se puede generar una prueba, afirmando que una entrada satisface el circuito. La prueba no revela información sobre las entradas privadas y es bastante pequeña.
-The verifier can check (1) that the proof is valid, (2) that the proof matches the constraints laid out by the circuit (and isn’t just a phony proof), and (3) that the public inputs used to generate the proof match those being used by the verifier. Note that this check performed by the verifier is generally a cheap computation.
+El verificador puede comprobar (1) que la prueba es válida, (2) que la prueba coincide con las restricciones establecidas por el circuito (y no es sólo una prueba falsa), y (3) que las entradas públicas utilizadas para generar la prueba coinciden con las utilizadas por el verificador. Tenga en cuenta que esta comprobación realizada por el verificador suele ser un cómputo barato.
- You might notice that the verifier doesn’t have an output beyond “valid proof” or “invalid proof.” Remember, the
- verifier just confirms other computations — in practice, the “outputs” of a function might actually end up being
- additional inputs to a circuit and verifier.
+ Puedes notar que el verificador no tiene una salida más allá de "prueba válida" o "prueba inválida". Recuerde, el
+ verificador sólo confirma otros cálculos - en la práctica, las "salidas" de una función en realidad podría terminar siendo
+ entradas adicionales a un circuito y verificador.
-### Circuits, Proof, and Verifiers — an example
+### Circuitos, Pruebas y Verificadores — un ejemplo
-Let’s take Sudoku as an example. Suppose that there’s a Sudoku puzzle, and Alice wants to prove to Bob that she knows a solution to the puzzle, but does not want to reveal what the solution is.
+Tomemos el Sudoku como ejemplo. Supongamos que hay un rompecabezas Sudoku, y Alice quiere demostrar a Bob que conoce una solución al rompecabezas, pero no quiere revelar cuál es la solución.
-In this case, the particular puzzle will be a public input (both Alice and Bob know about it), and the solution is a private input (Alice knows it, but will keep it private from Bob). The **circuit** would take both these inputs and assert that the solution is correct by checking it in the standard way, row-by-row, column-by-column, etc. The circuit in this way “constrains” that the private input solution really is a valid solution for the public input puzzle, and is “satisfied” only when the solution check passes.
+En este caso, el rompecabezas en particular será una entrada pública (tanto Alice como Bob lo saben), y la solución es una entrada privada (Alice lo sabe, pero lo mantendrá en privado de Bob). El **circuito** tomaría ambas entradas y afirmaría que la solución es correcta comprobándola de la forma estándar, fila a fila, columna a columna, etc. De este modo, el circuito "restringe" que la solución de la entrada privada sea realmente una solución válida para el puzzle de la entrada pública, y sólo se "satisface" cuando se supera la comprobación de la solución.
-A **proof** can then be generated that states that Alice knows an input that satisfies the circuit for the particular puzzle (the public input).
+Entonces se puede generar una **prueba** que establezca que Alice conoce una entrada que satisface el circuito para el puzzle en particular (la entrada pública).
-The proof, along with the puzzle, could be passed to Bob, who could then use a **verifier** corresponding to the Sudoku-checking circuit to assess if the proof is valid, and thereby that Alice indeed knows a solution to the puzzle. Critically, Bob doesn’t gain any knowledge of Alice’s solution, but he can still verify that she knows a valid solution!
+La prueba, junto con el puzzle, podría pasarse a Bob, que podría utilizar un **verificador** correspondiente al circuito de comprobación del Sudoku para evaluar si la prueba es válida y, por tanto, si Alice conoce la solución del puzzle. Bob no obtiene ningún conocimiento de la solución de Alice, pero puede verificar que ella conoce una solución válida.
-## Zero-Knowledge Proofs and Blockchains
+## Zero-Knowledge Proofs y Blockchains
-One of the primary motivations for recent advances in ZKPs is its application to blockchains. Two of the key challenges that decentralized blockchains face are privacy and scalability - all the data is public, and every node in the network has to re-run every computation on the network. ZKPs can help solve both these challenges.
+Una de las principales motivaciones de los recientes avances en las ZKP es su aplicación a las cadenas de bloques. Dos de los principales retos a los que se enfrentan las blockchains descentralizadas son la privacidad y la escalabilidad: todos los datos son públicos y cada nodo de la red tiene que volver a ejecutar cada cálculo en la red. Las ZKP pueden ayudar a resolver ambos problemas.
-While there are several projects utilizing the zero-knowledge property of ZKPs to build privacy-preserving applications, we at Scroll use only the succinctness property of ZKPs to scale Ethereum.
+Aunque hay varios proyectos que utilizan la característica de zero-knowledge de las ZKP para crear aplicaciones que preserven la privacidad, en Scroll sólo utilizamos la característica de concisión de las ZKP para escalar Ethereum.
-## Scroll & Zero Knowledge Proofs
+## Scroll y Zero Knowledge Proofs
-The idea that powers Scroll is quite simple. What if we could use an Ethereum smart contract to verify all of the computation of another version of Ethereum? We could run another network that provides faster and cheaper access to an Ethereum Virtual Machine (”EVM”), and Ethereum itself would provide the security needed for validating all the computation and making sure this other network isn’t breaking the EVM rules.
+La idea que impulsa Scroll es bastante simple. ¿Qué pasaría si pudiéramos utilizar un Smart Contract de Ethereum para verificar todos los cálculos de otra versión de Ethereum? Podríamos ejecutar otra red que proporcionara un acceso más rápido y barato a una máquina virtual de Ethereum ("EVM"), y Ethereum proporcionaría la seguridad necesaria para validar todos los cálculos y asegurarse de que esta otra red no infringe las reglas de la EVM.
-The rest of the Learn and Technology sections break down how this works in greater detail, but at a simple level, remember that zero-knowledge relies on having a circuit, proof, and verifier.
+El resto de las secciones de Aprende y Tecnología explican cómo funciona esto con más detalle, pero a un nivel sencillo, recuerda que las zero-knowledge se basan en tener un circuito, una prueba y un verificador.
-In our construction, the circuit (actually a set of circuits) encodes the rules of the EVM to “constrain” acceptable behavior for processing input transactions relative to the chain state. Using this “zkEVM”, a network of GPUs takes the transactions for a set of blocks and generates a proof. And back on Ethereum, a smart contract verifies that, for a set of transactions, this proof matches the circuit enshrined in the smart contract. If it does, those transactions can be considered “finalized,” the network moves forward, and we’ve created fast, secure, and affordable blockspace for growing Ethereum.
+En nuestra construcción, el circuito (en realidad un conjunto de circuitos) codifica las reglas de la EVM para "restringir" el comportamiento aceptable para procesar las transacciones de entrada relativas al estado de la cadena. Utilizando esta "zkEVM", una red de GPUs toma las transacciones de un conjunto de bloques y genera una prueba. Y de vuelta a Ethereum, un smart contract verifica que, para un conjunto de transacciones, esta prueba coincide con el circuito consagrado en el smart contract. Si es así, esas transacciones pueden considerarse "finalizadas", la red avanza y hemos creado un espacio de bloques rápido, seguro y asequible para el crecimiento de Ethereum.
diff --git a/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md
index a94257daf..d6c27057a 100644
--- a/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md
+++ b/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md
@@ -1,57 +1,57 @@
---
section: learn
date: Last Modified
-title: "KZG Commitment Scheme"
-lang: "en"
+title: "Esquema de Compromiso KZG"
+lang: "es"
permalink: "learn/zero-knowledge/kzg-commitment-scheme"
-excerpt: "KZG is used Ethereum’s Proto-Danksharding, and is also used in Scroll’s proof system. This article will give an overview of the KZG commitment scheme."
-whatsnext: { "Additional Resources": "/learn/zero-knowledge/additional-zk-learning-resources" }
+excerpt: "KZG se utiliza Proto-Danksharding de Ethereum, y también se utiliza en el sistema de pruebas de Scroll. Este artículo dará una visión general del esquema de compromiso KZG."
+whatsnext: { "Recursos Adicionales": "/es/learn/zero-knowledge/additional-zk-learning-resources" }
---
-One of the most widely used polynomial commitment schemes is the KZG commitment scheme. The scheme was originally [published](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) in 2010 by Kate, Zaverucha, and Goldberg.
+Uno de los esquemas de compromiso polinómico más utilizados es el esquema de compromiso KZG. El esquema fue originalmente [publicado](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) en 2010 por Kate, Zaverucha y Goldberg.
-KZG is used Ethereum’s [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq), and is also used in Scroll's proof system.
+KZG se utiliza en [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) de Ethereum, y también se utiliza en el sistema de pruebas de Scroll.
-This article will give an overview of the KZG commitment scheme.
+Este artículo dará una visión general del esquema de compromiso KZG.ç
-## Preliminaries and notation
+## Preliminares y notaciones
-Recall the premise of polynomial commitment schemes. We have some polynomial $P(x)$ that we would like to commit to. We’ll assume the polynomial has a degree less than $l$.
+Recordemos la premisa de los esquemas de compromiso polinómico. Tenemos algún polinomio $P(x)$ que nos gustaría comprometer. Asumiremos que el polinomio tiene un grado menor que $l$.
-KZG commitments rely on [elliptic curve pairings](https://vitalik.ca/general/2017/01/14/exploring_ecp.html). Let $\mathbb{G}_1$ and $\mathbb{G}_2$ be two elliptic curve groups of order $p$, with a non-trivial [bilinear mapping](https://en.wikipedia.org/wiki/Bilinear_map) $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$. Let $g$ be a generator of $\mathbb{G}_1$, and $h$ a generator of $\mathbb{G}_2$. We will use the notation $[x]_1 := x \cdot g$ and $[x]_2 := x \cdot h$, where $x \in \mathbb{F}_p$.
+KZG compromisos se basan en una [curva elíptica de pares](https://vitalik.ca/general/2017/01/14/exploring_ecp.html). Sean $\mathbb{G}_1$ y $\mathbb{G}_2$ dos grupos de curvas elípticas de orden $p$, con un no trivial [mapeo bilineal](https://en.wikipedia.org/wiki/Bilinear_map) $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$. Sea $g$ un generador de $\mathbb{G}_1$, y $h$ un generador de $\mathbb{G}_2$. Utilizaremos la notación $[x]_1 := x \cdot g$ y $[x]_2 := x \cdot h$, donde $x \in \mathbb{F}_p$.
-## 1. Trusted setup
+## 1. Ceremonia o Trusted Setup
-Before computing any KZG commitments, a one-time trusted setup must be performed. Once the trusted setup is completed, it can be reused to commit and reveal as many different polynomials as desired. The trusted setup works as follows:
+Antes de calcular cualquier compromiso KZG, se debe realizar una única trusted setup. Una vez completada, puede reutilizarse para comprometer y revelar tantos polinomios diferentes como se desee. La trusted setup funciona de la siguiente manera:
-- Pick some random field element $\tau \in \mathbb{F}_p$
-- Let $l \in \mathbb{Z}$ be the maximum degree of the polynomials we want to commit to
- - The trusted setup will only enable commitments to polynomials of degree $\leq l$
-- Compute $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ and $([\tau]_2)$, and release these values publicly.
+- Elija algún elemento de campo aleatorio $\tau \in \mathbb{F}_p$
+- Sea $l \in \mathbb{Z}$ el grado máximo de los polinomios que queremos comprometer a
+ - La trusted setup sólo permitirá compromisos con polinomios de grado $\leq l$
+- Se calcula $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ y $([\tau]_2)$, y se dan a conocer estos valores públicamente.
-Note that $\tau$ should not be revealed - it is a secret parameter of the setup, and should be discarded after the trusted setup ceremony is completed so that nobody can figure out its value.
+Tenga en cuenta que $\tau$ no debe ser revelado - es un parámetro secreto de la configuración, y debe ser desechado después de la ceremonia haya sido completada para que nadie pueda averiguar su valor.
-There are established methods of conducting trusted setup ceremonies with weak trust assumptions (1-out-of-N trust assumption) using [multi-party computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation) (MPC). For more on how trusted setups work, see this [post](https://vitalik.ca/general/2022/03/14/trustedsetup.html) by Vitalik.
+Existen métodos establecidos para llevar a cabo trusted setups con suposiciones de confianza débiles (suposición de confianza 1-de-N) utilizando [multi-party computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation) (MPC). Para más información sobre cómo funcionan las trusted setups, véase este [post](https://vitalik.ca/general/2022/03/14/trustedsetup.html) de Vitalik.
-## 2. Committing to a polynomial
+## 2. Compromiso con un polinomio
-- Given a polynomial $P(x) = \sum_{i=0}^{l} p_i x^i$
-- Compute and output the commitment $c = [P(\tau)]_1$
- - Although the committer cannot compute $P(\tau)$ directly (since he doesn’t know $\tau$), he can compute it using the output of the trusted setup:
- - $[P(\tau)]_1 = [\sum_{i=0}^{l} p_i \tau^i]_1 = \sum_{i=0}^{l} p_i [\tau^i]_1$
+- Dado un polinomio $P(x) = \sum_{i=0}^{l} p_i x^i$
+- Se computa y emite el compromiso $c = [P(\tau)]_1$.
+- Aunque el committer no puede computar $P(\tau)$ directamente (ya que no conoce $\tau$), puede computarlo utilizando la salida de la trusted setup:
+ - $[P(\tau)]_1 = [\sum_{i=0}^{l} p_i \tau^i]_1 = \sum_{i=0}^{l} p_i [\tau^i]_1$.
-## 3. Prove an evaluation
+## 3. Probar una evaluación
-- Given an evaluation $P(a) = b$
-- Compute and output the proof $\pi = [Q(\tau)]_1$
- - Where $Q(x) := \frac{P(x)-b}{x-a}$
- - This is called the “quotient polynomial.”Note that such a $Q(x)$ exists if and only if $P(a) = b$. The existence of this quotient polynomial therefore serves as a proof of the evaluation.
+- Dada una evaluación $P(a) = b$
+- Se computa y emite la prueba $\pi = [Q(\tau)]_1$
+ - Donde $Q(x) := \frac{P(x)-b}{x-a}$
+ - Obsérvese que tal $Q(x)$ existe si y sólo si $P(a) = b$. Por tanto, la existencia de este polinomio cociente sirve como prueba de la evaluación.
-## 4. Verify an evaluation proof
+## 4. Verificación de una prueba de evaluación
-- Given a commitment $c = [P(\tau)]_1$, an evaluation $P(a) = b$, and a proof $\pi = [Q(\tau)]_1$
-- Verify that $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$
- - Some algebra shows that this is equivalent to checking that that the quotient polynomial is correctly formed at $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$
+- Dado un compromiso $c = [P(\tau)]_1$, una evaluación $P(a) = b$, y una prueba $\pi = [Q(\tau)]_1$
+- Se Verifica que $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$
+ - Algo de álgebra muestra que esto es equivalente a comprobar que el polinomio cociente está correctamente formado en $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$
$$
\begin{align*}
& e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff
@@ -60,10 +60,10 @@ There are established methods of conducting trusted setup ceremonies with weak t
& Q(\tau) \cdot (\tau -a) = P(\tau) - b
\end{align*}
$$
- - The bilinear mapping $e$ enables us to check this property without knowing the secret setup parameter $\tau$
-- Once this verification is complete, we can conclude that (with overwhelmingly high probability) the quotient polynomial is correctly formed, and therefore that the evaluation is correct.
+ - El mapeo bilineal $e$ nos permite comprobar esta propiedad sin conocer el parámetro secreto de configuración $\tau$
+- Una vez realizada esta comprobación, podemos concluir que (con una probabilidad abrumadoramente alta) el polinomio cociente está correctamente formado, y por tanto que la evaluación es correcta.
-## Learn more
+## Aprende Más
- [https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)
- [https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html](https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html)
diff --git a/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md b/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md
index 07c830f65..74bc0ff9e 100644
--- a/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md
+++ b/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md
@@ -1,35 +1,35 @@
---
section: learn
date: Last Modified
-title: "Polynomial Commitment Schemes"
-lang: "en"
+title: "Esquemas de Compromiso Polinómicos"
+lang: "es"
permalink: "learn/zero-knowledge/polynomial-commitment-schemes"
-excerpt: "Polynomial commitment schemes are a core building block of zero-knowledge proof system"
-whatsnext: { "KZG Commitment Scheme": "/learn/zero-knowledge/kzg-commitment-scheme" }
+excerpt: "Los Polynomial commitment schemea son un componente básico de los sistemas de pruebas de zero-knowledge."
+whatsnext: { "Esquema de Compromiso KZG": "/es/learn/zero-knowledge/kzg-commitment-scheme" }
---
-Polynomial commitment schemes are a core building block of zero-knowledge proof systems (as well as other cryptographic protocols).
+Los Esquemas de Compromiso Polinómicos son un componente básico de los sistemas de pruebas de zero-knowledge (así como de otros protocolos criptográficos).
-As the name suggests, polynomial commitment schemes are commitment schemes where the object to be committed is a polynomial. These schemes also have a special property where an evaluation of the polynomial can be verified with access only to the polynomial’s commitment.
+Como su nombre indica, los esquemas de compromiso polinómicos son esquemas de compromiso en los que el objeto a comprometer es un polinomio. Estos esquemas también tienen una propiedad especial por la que una evaluación del polinomio puede verificarse con acceso únicamente al compromiso del polinomio.
-## Commitment schemes
+## Esquemas de Compromiso
-A **[commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme)** is a cryptographic primitive involving two parties: a _committer_ and a _verifier_. The committer commits to a value $v$ by computing a commitment $c$ and revealing it to the verifier. At a later point in time, the committer can reveal the original value, and the verifier can verify that the commitment corresponds to this revealed value.
+Un **[esquema de compromiso](https://en.wikipedia.org/wiki/Commitment_scheme)** es una primitiva criptográfica que implica a dos partes: un _committer_ y un _verifier_. El committer se compromete con un valor $v$ computando un compromiso $c$ y revelándolo al verifier. En un momento posterior, el committer puede revelar el valor original, y el verifier puede verificar que el compromiso corresponde a este valor revelado.
-Secure commitment schemes have two properties:
+Los esquemas de compromiso seguros tienen dos características:
-1. **Binding**: once publishing the commitment $c$, the committer should not be able to find some other value $v’$ distinct from $v$ that also corresponds to $c$. I.e., the commitment $c$ binds the committer to his original value $v$.
-2. **Hiding**: the verifier should not be able to learn any information about the original value $v$ from the commitment $c$. I.e., the commitment $c$ hides all information about the original value $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 a su 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$.
-## Polynomial commitment schemes
+## Esquemas de Compromiso Polinómicos
-A **polynomial commitment scheme** is a commitment scheme where the committer commits to a polynomial $P(x)$ by computing a commitment $c$. As in normal commitment schemes, the committer can later reveal the original polynomial, and the verifier can check that the commitment corresponds to the revealed polynomial. However, polynomial commitment schemes have an additional property: the committer can prove particular evaluations of the committed polynomial without revealing the polynomial itself. For example, the committer can prove that $P(a) = b$, and the verifier can verify such a proof using just the commitment $c$.
+Un **esquema de compromiso polinómicos** es un esquema de compromiso en el que el committer se compromete con un polinomio $P(x)$ calculando un compromiso $c$. Como en los esquemas de compromiso normales, el committer puede revelar más tarde el polinomio original, y el verifier puede comprobar que el compromiso corresponde al polinomio revelado. Sin embargo, los esquemas de compromiso polinómico tienen una propiedad adicional: el committer puede probar evaluaciones particulares del polinomio comprometido sin revelar el propio polinomio. Por ejemplo, el committer puede probar que $P(a) = b$, y el verifier puede verificar dicha prueba utilizando sólo el compromiso $c$.
-Polynomial commitment schemes are extremely useful for zero-knowledge applications. A prover can use such a scheme to prove that he knows some polynomial which satisfies certain properties (e.g. that it passes through a certain point $(a,b)$), without revealing the underlying polynomial.
+Los esquemas de compromiso polinómicos son extremadamente útiles para aplicaciones que usan zero-knowledge. Un prover puede utilizar un esquema de este tipo para demostrar que conoce un polinomio que satisface ciertas propiedades (por ejemplo, que pasa por un cierto punto $(a,b)$), sin revelar el polinomio subyacente.
-Another reason why polynomial schemes are useful is that the commitment $c$ is generally much smaller than the polynomial it represents, and can thus be thought of as a **compression** of the polynomial $P(x)$. The magnitude of compression depends on the particular scheme. For example, in the KZG polynomial commitment scheme, a polynomial of arbitrarily large degree can be compressed down to a commitment consisting of a single group element.
+Otra razón por la que los esquemas polinómicos son útiles es que el compromiso $c$ es generalmente mucho más pequeño que el polinomio que representa, y por lo tanto se puede considerar como una **compresión** del polinomio $P(x)$. La magnitud de la compresión depende del esquema concreto. Por ejemplo, en el esquema de compromiso polinómico KZG, un polinomio de grado arbitrariamente grande puede comprimirse hasta un compromiso consistente en un único elemento de grupo.
-## Learn more
+## Aprende Más
- [https://en.wikipedia.org/wiki/Commitment_scheme](https://en.wikipedia.org/wiki/Commitment_scheme)
- [https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment](https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment)
diff --git a/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx b/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx
index 9308e216c..fb6b70019 100644
--- a/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx
+++ b/src/content/docs/es/technology/bridge/cross-domain-messaging.mdx
@@ -2,9 +2,9 @@
section: technology
date: Last Modified
title: "Cross-Domain Messaging"
-lang: "en"
+lang: "es"
permalink: "technology/bridge/cross-domain-messaging"
-whatsnext: { "Deposit Gateways": "/technology/bridge/deposit-gateways/" }
+whatsnext: { "Gateways de Depósito": "/es/technology/bridge/deposit-gateways/" }
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
@@ -14,15 +14,15 @@ import L1ToL2 from "../_images/L1-to-L2.png"
import L2ToL1 from "../_images/L2-to-L1.png"
import WithdrawTrie from "../_images/withdraw-trie.png"
-Scroll has an arbitrary message passing bridge that enables token transfers and allows dapps to communicate between layer 1 and layer 2. This means that dapps on layer 1 can trigger contract functions on layer 2, and vice versa. Next, we will explain how the messages are relayed between layer 1 and layer 2.
+Scroll tiene un bridge para el paso de mensajes arbitrarios que permite la transferencia de tokens y permite a las dapps comunicarse entre la capa 1 y la capa 2. Esto significa que las dapps de la capa 1 pueden activar funciones de contrato en la capa 2, y viceversa. A continuación, explicaremos cómo se transmiten los mensajes entre la capa 1 y la capa 2.
-## Sending Messages from L1 to L2
+## Envío de mensajes de L1 a L2
-There are two primary approaches to sending a message from L1 to L2: sending arbitrary messages via `L1ScrollMessenger` and sending enforced transactions via `EnforcedTxGateway`. Both approaches allow users to initiate a L2 transaction on L1 and call arbitrary contracts on L2. For arbitrary messages, the sender of the L2 transactions is the aliased `L1ScrollMessenger` address. For enforced transactions, the L2 sender is an externally-owned account (EOA). In addition, we provide several standard token gateways to make it easier for users to deposit ETH and other standard tokens including ERC-20, ERC-677, ERC-721, and ERC-1155. In essence, these gateways encode token deposits into a message and send it to their counterparts on L2 through the `L1ScrollMessenger` contract. You can find more details about the L1 token gateways in the [Deposit Gateways](/technology/bridge/deposit-gateways).
+Existen dos enfoques principales para enviar un mensaje de L1 a L2: enviar mensajes arbitrarios a través de `L1ScrollMessenger` y enviar transacciones forzadas a través de `EnforcedTxGateway`. Ambos enfoques permiten a los usuarios iniciar una transacción L2 en L1 y llamar a contratos arbitrarios en L2. En el caso de los mensajes arbitrarios, el remitente de las transacciones L2 es la dirección alias "L1ScrollMessenger". Para las transacciones forzadas, el remitente de L2 es una cuenta de titularidad externa (EOA). Además, proporcionamos varias gateways de tokens estándares para facilitar a los usuarios el depósito de ETH y otros tokens estándares, incluidos ERC-20, ERC-677, ERC-721 y ERC-1155. En esencia, estas gateways codifican los depósitos de tokens en un mensaje y lo envían a sus homólogos en L2 a través del contrato `L1ScrollMessenger`. Puede encontrar más detalles sobre las gateways de tokens de L1 en [Gateways de Depósito](/es/technology/bridge/deposit-gateways).
-As depicted in Figure 1, both arbitrary messages and enforced transactions are appended to the message queue stored in the `L1MessageQueue` contract. The `L1MessageQueue` contract provides two functions `appendCrossDomainMessage` and `appendEnforcedTransaction` for appending arbitrary messages and enforced transactions respectively.
+Como se muestra en la Figura 1, tanto los mensajes arbitrarios como las transacciones forzadas se añaden a la cola de mensajes almacenada en el contrato `L1MessageQueue`. El contrato `L1MessageQueue` proporciona dos funciones `appendCrossDomainMessage` y `appendEnforcedTransaction` para añadir mensajes arbitrarios y transacciones forzadas respectivamente.
```solidity
/// @notice Append an arbitrary L1-to-L2 message into this contract.
@@ -50,18 +50,18 @@ function appendEnforcedTransaction(
) external;
```
-Both functions construct an L1-initiated transaction with a new transaction type `L1MessageTx` introduced in the Scroll chain and compute the transaction hash (see more details in the [L1 Message Transaction](/technology/chain/transactions#l1-message-transaction)). `L1MessageQueue` then appends the transaction hash to the message queue, and emits the event `QueueTransaction(sender, target, value, queueIndex, gasLimit, calldata)`. The difference between `appendCrossDomainMessage` and `appendEnforcedTransaction` when constructing L1 message transactions is:
+Ambas funciones construyen una transacción iniciada por L1 con un nuevo tipo de transacción `L1MessageTx` introducido en la Scroll chain y calculan el hash de la transacción (ver más detalles en [Transacción de Mensajes en L1](/es/technology/chain/transactions#l1-message-transaction)). A continuación, `L1MessageQueue` añade el hash de la transacción a la cola de mensajes y emite el evento `QueueTransaction(sender, target, value, queueIndex, gasLimit, calldata)`. La diferencia entre `appendCrossDomainMessage` y `appendEnforcedTransaction` a la hora de construir transacciones de mensajes L1 es:
-- `appendCrossDomainMessage` can be only called by `L1ScrollMessenger` and it uses the [aliased address](#address-alias) of `msg.sender`, which will be the address of `L1ScrollMessenger`, as the transaction sender.
-- `appendEnforcedTransaction` can be only called by `EnforcedTxGateway` and it uses `sender` from the function parameter as the transaction sender. This allows users to enforce a withdrawal or transfer of ETH from their L2 accounts directly through the L1 bridge.
+- `appendCrossDomainMessage` sólo puede ser llamado por `L1ScrollMessenger` y utiliza la [Address Alias](#address-alias) de `msg.sender`, que será la dirección de `L1ScrollMessenger`, como remitente de la transacción.
+- La función `appendEnforcedTransaction` sólo puede ser llamada por `EnforcedTxGateway` y utiliza `sender` del parámetro de función como remitente de la transacción. Esto permite a los usuarios ejecutar una retirada o transferencia de ETH desde sus cuentas L2 directamente a través del bridge L1.
-After the transaction is successfully executed on L1, the watcher in the Scroll sequencer that monitors the `L1MessageQueue` contract collects the new `QueueTransaction` events from L1 blocks. The sequencer then constructs a new `L1MessageTx` transaction per event and appends them to its local L1 transaction queue. When constructing a new L2 block, the sequencer includes the transactions from both its L1 transaction queue and its L2 mempool. Note that the L1 message transactions must be included sequentially based on the L1 message queue order in the `L1MessageQueue` contract. `L1MessageTx` transactions always come first in the L2 blocks followed by L2 transactions. Currently, we limit the number of `L1MessageTx` transactions in a L2 block to `NumL1MessagesPerBlock` (currently set to 10).
+Después de que la transacción se ejecuta con éxito en L1, el watcher en el secuenciador Scroll que monitoriza el contrato `L1MessageQueue` recoge los nuevos eventos `QueueTransaction` de los bloques L1. El secuenciador construye entonces una nueva transacción `L1MessageTx` por evento y las añade a su cola local de transacciones L1. Cuando construye un nuevo bloque L2, el secuenciador incluye las transacciones tanto de su cola de transacciones L1 como de su mempool L2. Ten en cuenta que las transacciones de mensajes L1 deben incluirse secuencialmente basándose en el orden de la cola de mensajes L1 en el contrato `L1MessageQueue`. Las transacciones `L1MessageTx` siempre van primero en los bloques L2 seguidas de las transacciones L2. Actualmente, limitamos el número de transacciones `L1MessageTx` en un bloque L2 a `NumL1MessagesPerBlock` (fijado actualmente en 10).
-Next, we will expand more on the specific process of sending arbitrary messages via `L1ScrollMessenger` and sending enforced transactions via `EnforcedTxGateway`.
+A continuación, nos extenderemos más en el proceso específico de envío de mensajes arbitrarios a través de `L1ScrollMessenger` y el envío de transacciones forzadas a través de `EnforcedTxGateway`.
-### Sending Arbitrary Messages
+### Envío de Mensajes Arbitrarios
-The `L1ScrollMessenger` contract provides two `sendMessage` functions to send arbitrary messages. The only difference is that the second one allows users to specify a refund address other than the sender address to receive a fee refund.
+El contrato `L1ScrollMessenger` proporciona dos funciones `sendMessage` para enviar mensajes arbitrarios. La única diferencia es que la segunda permite a los usuarios especificar una dirección de reembolso distinta de la del remitente para recibir el reembolso de la comisión.
sendMessage
function signatures
@@ -93,9 +93,9 @@ function sendMessage(
-Both functions require users to provide a gas limit for the corresponding `L1MessageTx` transaction on L2 and prepay the [message relay fee](#message-relay-fee) on L1, which is calculated based on the gas limit amount. The fee is collected to a `feeVault` contract on L1. In case the transaction fails on L2 because the user did not set the correct gas limit for their message on L1, the user can replay the same message with a higher gas limit. You can find more details in the [Retrying failed messages](#retrying-failed-messages) section.
+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).
-The `sendMessage` functions encode the arguments into a cross-domain message (see the code snippet below), where the message nonce is the next queue index of the L1 message queue. The encoded data is then used as calldata in the `L1MessageTx` transaction executed on L2. Note that such cross-domain messages always call the `relayMessage` function of the `L2ScrollMessenger` contract on L2.
+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 L1. Los datos codificados se utilizan como calldata en la transacción `L1MessageTx` ejecutada en L2. Tenga en cuenta que estos mensajes entre dominios siempre llaman a la función `relayMessage` del contrato `L2ScrollMessenger` en L2.
```solidity
abi.encodeWithSignature(
@@ -108,11 +108,11 @@ abi.encodeWithSignature(
)
````
-The deposited ETH of `value` amount is locked in the `L1ScrollMessenger` contract. If the amount of ETH in the message cannot cover the message relay fee and the deposited amount, the transaction will be reverted. The `L1ScrollMessenger` contract will refund the excess amount to the designated `refundAddress` or the transaction sender otherwise. Finally, `L1ScrollMessenger` appends the cross-domain message to `L1MessageQueue` via the `appendCrossDomainMessage` method.
+La cantidad de ETH depositada de `value` se bloquea en el contrato `L1ScrollMessenger`. Si la cantidad de ETH en el mensaje no puede cubrir la Message Relay Fee y la cantidad depositada, la transacción se revertirá. El contrato `L1ScrollMessenger` reembolsará la cantidad sobrante a la `refundAddress` designada o al remitente de la transacción en caso contrario. Por último, `L1ScrollMessenger` añade el mensaje entre dominios a `L1MessageQueue` mediante el método `appendCrossDomainMessage`.
-### Sending Enforced Transactions
+### Envío de Transacciones Forzadas
-The `EnforcedTxGateway` contract provides two `sendTransaction` functions to send an enforced transaction. In the first function, the sender of the generated `L1MessageTx` transaction is the transaction sender. On the other hand, the second function uses the passed `sender` address as the sender of the `L1MessageTx` transaction. This allows a third party to send an enforced transaction on behalf of the user and pay the relay fee. Note that the second function requires providing a valid signature of the generated `L1MessageTx` transaction that matches the `sender` address. Both `sendTransaction` functions enforce the sender to be an EOA account.
+El contrato `EnforcedTxGateway` proporciona dos funciones `sendTransaction` para enviar una transacción forzada. En la primera función, el remitente de la transacción generada `L1MessageTx` es el remitente de la transacción. Por otro lado, la segunda función utiliza la dirección del `sender` como remitente de la transacción `L1MessageTx`. Esto permite a un tercero enviar una transacción forzada en nombre del usuario y pagar la comisión de retransmisión. Tenga en cuenta que la segunda función requiere proporcionar una firma válida de la transacción `L1MessageTx` generada que coincida con la dirección del `sender`. Ambas funciones `sendTransaction` exigen que el remitente sea una cuenta EOA.
sendTransaction
function signatures
@@ -149,11 +149,11 @@ function sendTransaction(
-Similar to arbitrary message relaying, `sendTransaction` deducts the message relay fee and transfers it to the L1 `feeVault` account. But a key difference is that the `value` passed to the function indicates the amount of ETH to be transferred from the sender account on L2, not on L1. Hence, the `msg.value` only needs to cover the [message relay fee](#message-relay-fee). If the amount of ETH in the message cannot cover the fee, the transaction will fail. Any excess fee is refunded to the transaction sender in the first function and to the `refundAddress` in the second function. Lastly, `EnforcedTxGateway` calls `L1MessageQueue.appendEnforcedTransaction` to append the transaction to the message queue.
+De forma similar a la retransmisión arbitraria de mensajes, `sendTransaction` deduce la comisión de retransmisión de mensajes y la transfiere a la cuenta `feeVault` de L1. Pero una diferencia clave es que el `value` que se pasa a la función indica la cantidad de ETH que debe transferirse desde la cuenta del remitente en L2, no en L1. Por lo tanto, el `msg.value` sólo necesita cubrir el [Message Relay Fee](#message-relay-fee). Si la cantidad de ETH en el mensaje no puede cubrir la comisión, la transacción fallará. Cualquier exceso de comisión se reembolsa al remitente de la transacción en la primera función y a la `refundAddress` en la segunda función. Por último, `EnforcedTxGateway` llama a `L1MessageQueue.appendEnforcedTransaction` para añadir la transacción a la cola de mensajes.
-### Retrying Failed Messages
+### Reintento de Mensajes Fallidos
-If a `L1MessageTx` transaction fails on L2 due to insufficient gas, users can replay the message with a higher gas limit. `L1ScrollMessenger` provides the method `replayMessage` that allows users to send the same information as the previous failed message with a higher gas limit. This message will become a new `L1MessageTx` transaction on L2. Note that we won't refund the gas fee for the previous failed transaction as it is already processed on L2.
+Si una transacción `L1MessageTx` falla en L2 debido a gas insuficiente, los usuarios pueden reproducir el mensaje con un límite de gas más alto. Para ello, `L1ScrollMessenger` proporciona el método `replayMessage`, que permite a los usuarios enviar la misma información que el mensaje anterior fallido con un límite de gas superior. Este mensaje se convertirá en una nueva transacción `L1MessageTx` en L2. Tenga en cuenta que no se reembolsará la tarifa de gas de la transacción fallida anterior, ya que ésta ya se ha procesado en L2.
replayMessage
function signature
@@ -179,23 +179,23 @@ function replayMessage(
-Because the `L2ScrollMessenger` contract records all L1 messages that were successfully relayed to L2, the transaction of the replayed message will be reverted on L2 if the original message succeeds.
+Dado que el contrato `L2ScrollMessenger` registra todos los mensajes de L1 que se retransmitieron con éxito a L2, la transacción del mensaje reproducido se revertirá en L2 si el mensaje original tiene éxito.
### Message Relay Fee
-The contract `L2GasPriceOracle` deployed on L1 computes the relay fee of a message given its gas limit. This contract stores the `l2BaseFee` in its storage, which is updated by a dedicated relayer run by Scroll currently. The relay fee of L1-to-L2 messages is `gasLimit * l2BaseFee`.
+El contrato `L2GasPriceOracle` desplegado en L1 calcula la comisión de retransmisión de un mensaje dado su límite de gas. Este contrato almacena el valor `l2BaseFee` en su memoria, que se actualiza mediante un relayer dedicado ejecutado actualmente por Scroll. La comisión de retransmisión de los mensajes de L1 a L2 es `gasLimit * l2BaseFee`.
### Address Alias
-Due to the behavior of the `CREATE` opcode, it is possible that someone deploys a contract at the same address on L1 and L2 but with different bytecode. To avoid malicious users taking advantage of this, the bridge applies an address alias when the message sender is a contract on L1. The aliased sender address of the L1 message transaction is `l1_contract_address + offset` where the `offset` is `0x1111000000000000000000000000000000001111`.
+Debido al comportamiento del opcode `CREATE`, es posible que alguien despliegue un contrato en la misma dirección en L1 y L2 pero con diferente bytecode. Para evitar que usuarios malintencionados se aprovechen de esto, el bridge aplica un Address Alias cuando el remitente del mensaje es un contrato en L1. La dirección del remitente alias de la transacción del mensaje L1 es `l1_dirección_del_contrato + offset` donde el `offset` es `0x11110000000000000000000000000000000000001111`.
## Sending Messages from L2 to L1
-On L2, users can send arbitrary messages through `L2ScrollMessenger` to withdraw tokens and call L1 contracts. Similar to L1, we have built several standard token gateways to make it easier to initialize token withdrawals. For more details about L2 token gateways, please refer to the [Withdraw Gateways](/technology/bridge/withdraw-gateways).
+En L2, los usuarios pueden enviar mensajes arbitrarios a través de `L2ScrollMessenger` para retirar tokens y llamar a contratos L1. Al igual que en L1, hemos creado varias gateways de tokens estándares para facilitar la inicialización de los retiros de tokens. Para más detalles sobre las gateways de tokens de L2, consulta [Gateways de Retiro](/es/technology/bridge/withdraw-gateways).
-The `L2ScrollMessenger` contract also provides a `sendMessage` function. The difference from the `L1ScrollMessenger.sendMessage` is that the `gasLimit` parameter is ignored in the function because the withdrawal execution transaction on L1 is submitted by users and the transaction fee is paid on L1 directly. Thus, the `sendMessage` function requires `msg.value` to be equal to the parameter `value`. The function encodes the arguments into a cross-domain message following the same schema as in [`L1ScrollMessenger`](#sending-arbitrary-messages).
+El contrato `L2ScrollMessenger` también proporciona una función `sendMessage`. La diferencia con respecto a `L1ScrollMessenger.sendMessage` es que el parámetro `gasLimit` se ignora en la función porque la transacción de ejecución de retiro en L1 es enviada por los usuarios y la comisión de transacción se paga en L1 directamente. Así, la función `sendMessage` requiere que `msg.value` sea igual al parámetro `value`. La función codifica los argumentos en un mensaje entre dominios siguiendo el mismo esquema que en [`L1ScrollMessenger`](#sending-arbitrary-messages).
sendMessage
function signatures
@@ -215,18 +215,18 @@ function sendMessage(
-Next, the cross-domain message hash is appended to `L2MessageQueue` by calling its `appendMessage` function. The `L2MessageQueue` contract maintains the [Withdraw Trie](#withdraw-trie), an append-only Merkle tree. Every time a new message is appended to the queue, the contract inserts it into the Withdraw Trie and updates the trie's root hash.
+A continuación, el hash de mensajes entre dominios se añade a `L2MessageQueue` llamando a su función `appendMessage`. El contrato `L2MessageQueue` mantiene el [Withdraw Trie](#withdraw-trie), un Merkle tree sólo para añadir mensajes. Cada vez que se añade un nuevo mensaje a la cola, el contrato lo inserta en el Withdraw Trie y actualiza el hash root del trie.
-After the transaction batch containing users' L2-to-L1 messages is finalized on the L1 rollup contract, users need to submit corresponding _Execute Withdrawal_ transactions to call `relayMessageWithProof` method in the `L1ScrollMessenger` contract that executes the withdrawal on L1. Thanks to the Merle proofs, the finalization of withdrawal transactions on L1 is trustless and can be submitted by user themselves or by a third party on behalf of users.
+Una vez finalizado el lote de transacciones que contiene los mensajes L2 a L1 de los usuarios en el contrato L1 rollup, los usuarios deben enviar las transacciones _Execute Withdrawal_ correspondientes para llamar al método `relayMessageWithProof` del contrato `L1ScrollMessenger` que ejecuta la retirada en L1. Gracias a las Merkle proofs, la finalización de las transacciones de retirada en L1 no genera confianza y puede ser enviada por el propio usuario o por un tercero en nombre de los usuarios.
-To make it easier to construct a withdraw MIP, Scroll maintains a service called Bridge History API. Bridge History API monitors `SentMessage` events emitted from `L2ScrollMessenger` and maintains a Withdraw Trie internally. It continuously generates Merkle proofs for every withdrawal messages. Users and third-party services can query Merkle proofs from the Bridge History API to include in the _Execute Withdrawal_ transactions.
+Para facilitar la construcción de un MIP de retiro, Scroll mantiene un servicio llamado Bridge History API. Bridge History API supervisa los eventos `SentMessage` emitidos por `L2ScrollMessenger` y mantiene internamente un Withdraw Trie. Genera continuamente Merkle proofs para cada mensaje de retirada. Los usuarios y los servicios de terceros pueden consultar las Merkle proofs desde la Bridge History API para incluirlas en las transacciones _Execute Withdrawal_.
-Note that the execute withdrawal transactions can be submitted by the users themselves or by a third-party service.
+Tenga en cuenta que las transacciones de ejecución de retirada pueden ser enviadas por los propios usuarios o por un servicio de terceros.
### Withdraw Trie
-The Withdraw Trie is a dense binary Merkle tree. The hash of a leaf node is inherited from the message hash, while the hash of a non-leaf node is the Keccak hash digest of the concatenated hashes of its two children. The depth of the Withdraw Trie grows dynamically depending on the number of messages appended to the trie.
+El Withdraw Trie es un "Merkle tree" binario denso. El hash de un leaf node se hereda del hash del mensaje, mientras que el hash de un non-leaf node es el Keccak hash digest de los hashes concatenados de sus dos descendientes. La profundidad del Withdraw Trie crece dinámicamente en función del número de mensajes añadidos al trie.
-Figure 3(a) shows an example of a complete 3-layer withdraw trie. When the number of leaves cannot saturate a complete binary tree, we pad leaf nodes with hash 0, as depicted in Figure 3(b) and 3(c). When appending a new message to a non-complete Withdraw Trie, the padding node will be then replaced by a new leaf node with the actual message hash.
+La figura 3(a) muestra un ejemplo de un withdraw trie completo de 3 capas. Cuando el número de leaves no puede saturar un tree binario completo, rellenamos los nodos de las leaf con hash 0, como se muestra en las figuras 3(b) y 3(c). Cuando se añade un nuevo mensaje a un Withdraw Trie no completo, el nodo de relleno se sustituye por un nuevo leaf node con el hash del mensaje real.
diff --git a/src/content/docs/es/technology/bridge/deposit-gateways.mdx b/src/content/docs/es/technology/bridge/deposit-gateways.mdx
index bbb4636b2..26088185c 100644
--- a/src/content/docs/es/technology/bridge/deposit-gateways.mdx
+++ b/src/content/docs/es/technology/bridge/deposit-gateways.mdx
@@ -1,38 +1,38 @@
---
section: technology
date: Last Modified
-title: "Deposit Gateways"
-lang: "en"
+title: "Gateways de Depósito"
+lang: "es"
permalink: "technology/bridge/deposit-gateways"
-whatsnext: { "Withdraw Gateways": "/technology/bridge/withdraw-gateways/" }
+whatsnext: { "Gateways de Retiro": "/es/technology/bridge/withdraw-gateways/" }
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
import DepositWorkflow from "../_images/deposit.png"
-This document describes how users and developers can utilize gateways to deposit tokens from L1 to L2. We provide several gateways for standard tokens and a gateway router on L1, listed in the table below.
+Este documento describe cómo los usuarios y desarrolladores pueden utilizar las gateways para depositar tokens de L1 a L2. Proporcionamos varias gateways para tokens estándares y un router gateway en L1, listados en la siguiente tabla.
-| Gateway Contract | Description |
+| Gateway Contract | Descripción |
| ------------------------ | ---------------------------------------------------------------- |
-| `L1GatewayRouter` | The gateway router supports the deposit of ETH and ERC20 tokens. |
-| `L1ETHGateway` | The gateway to deposit ETH. |
-| `L1StandardERC20Gateway` | The gateway for standard ERC20 token deposits. |
-| `L1CustomERC20Gateway` | The gateway for custom ERC20 token deposits. |
-| `L1WETHGateway` | The gateway for Wrapped ETH deposits. |
-| `L1ERC721Gateway` | The gateway for ERC-721 token deposits. |
-| `L1ERC1155Gateway` | The gateway for ERC-1155 token deposits. |
+| `L1GatewayRouter` | La gateway router admite el depósito de tokens ETH y ERC20. |
+| `L1ETHGateway` | La gateway para depositar ETH. |
+| `L1StandardERC20Gateway` | La gateway para depósitos de tokens ERC20 estándar. |
+| `L1CustomERC20Gateway` | La gateway para depósitos de tokens ERC20 personalizados. |
+| `L1WETHGateway` | La gateway para depósitos ETH envueltos. |
+| `L1ERC721Gateway` | La gateway para depósitos de tokens ERC-721. |
+| `L1ERC1155Gateway` | La gateway para depósitos de tokens ERC-1155. |
-## Overview
+## Vista Ampliada
-The figure depicts the deposit workflow from L1 to L2. Users call the gateways to initialize the token deposit. The deposit is then encoded into a message sent to the `L1ScrollMessenger` contract and a corresponding L1-initiated transaction is appended to the `L1MessageQueue`. To finalize the deposits on L2, the L2 sequencer collects the new L1 transaction events and includes the corresponding transactions in the L2 blocks it creates. The subsequent sections describe the details of how different tokens are deposited. You can find more details about the L1-to-L2 message relay workflow in the [Cross-Domain Messaging](/technology/bridge/cross-domain-messaging#sending-messages-from-l1-to-l2).
+La figura muestra el flujo de trabajo de depósito de L1 a L2. Los usuarios llaman a las gateways para iniciar el depósito de tokens. A continuación, el depósito se codifica en un mensaje que se envía al contrato `L1ScrollMessenger` y se añade la correspondiente transacción iniciada en L1 a la `L1MessageQueue`. Para finalizar los depósitos en L2, el secuenciador de L2 recoge los nuevos eventos de transacción de L1 e incluye las transacciones correspondientes en los bloques de L2 que crea. Las secciones siguientes describen los detalles de cómo se depositan los distintos tokens. Puede encontrar más detalles sobre el flujo de trabajo de retransmisión de mensajes de L1 a L2 en [Cross-Domain Messaging](/es/technology/bridge/cross-domain-messaging#sending-messages-from-l1-to-l2).
-## Depositing ETH
+## Depósito de ETH
-Scroll treats ETH as its native token. We pre-allocate a sufficient amount of ETH to the `L2ScrollMessenger` contract in the genesis block so that it can transfer native ETH token to L2 accounts without minting. Depositing ETH works as follows.
+Scroll utiliza ETH como su token nativo. Preasignamos una cantidad suficiente de ETH al contrato `L2ScrollMessenger` en el bloque génesis para que pueda transferir tokens ETH nativos a cuentas L2 sin necesidad de emitir. El depósito de ETH funciona de la siguiente manera.
-1. `L1GatewayRouter` provides three functions to deposit ETH from L1 to L2. The `depositETHAndCall` function can transfer ETH and execute a contract call at the same time.
+1. `L1GatewayRouter` ofrece tres funciones para depositar ETH de L1 a L2. La función `depositETHAndCall` puede transferir ETH y ejecutar una llamada de contrato al mismo tiempo.
```solidity
function depositETH(uint256 _amount, uint256 _gasLimit) external payable;
@@ -47,24 +47,24 @@ Scroll treats ETH as its native token. We pre-allocate a sufficient amount of ET
) external payable;
```
-2. All three `depositETH` functions call into `L1ETHGateway`. `L1ETHGateway` encodes the deposit into a message sent to the `L1ScrollMessenger` contract.
+2. Las tres funciones `depositETH` llaman a `L1ETHGateway`. `L1ETHGateway` codifica el depósito en un mensaje que se envía al contrato `L1ScrollMessenger`.
-3. The ETH of the deposit amount is locked in the `L1ScrollMessenger` contract. `L1ScrollMessenger` appends the message to the message queue in the `L1MessageQueue` contract.
+3. El ETH del importe del depósito se bloquea en el contrato `L1ScrollMessenger`. L1ScrollMessenger añade el mensaje a la cola de mensajes del contrato L1MessageQueue.
-4. After the deposit transaction is finalized on the L1, the sequencer will include a corresponding L2 transaction in the L2 block to finalize the deposit and transfer ETH to the recipient address on L2.
+4. Una vez finalizada la transacción de depósito en el L1, el secuenciador incluirá una transacción L2 correspondiente en el bloque L2 para finalizar el depósito y transferir ETH a la dirección del destinatario en el L2.
-5. The L2 transaction calls the `L2ScrollMessenger.relayMessage` function, which executes the relayed message.
- In the case of ETH deposit, the `relayMessage` function calls `L2ETHGateway.finalizeDepositETH` to transfer ETH to the recipient account on L2.
+5. La transacción L2 llama a la función `L2ScrollMessenger.relayMessage`, que ejecuta el mensaje retransmitido.
+ En el caso del depósito de ETH, la función `relayMessage` llama a `L2ETHGateway.finalizeDepositETH` para transferir ETH a la cuenta del destinatario en L2.
-6. If the user calls `depositETHAndCall` on L1, `finalizeDepositETH` in the `L2ETHGateway` contract will forward the additional data to the target L2 contract.
+6. Si el usuario llama a `depositETHAndCall` en L1, `finalizeDepositETH` en el contrato `L2ETHGateway` reenviará los datos adicionales al contrato L2 de destino.
-## Depositing ERC20 Tokens
+## Depósito de Tokens ERC20
-Several ERC20 gateway contracts are provided to bridge different kinds of ERC20 tokens, such as standard ERC20 tokens, custom ERC20 tokens, and Wrapped ETH token. `L1GatewayRouter` records the canonical mapping of ERC20 tokens to the corresponding ERC20 gateway on the L1. The `L1GatewayRouter` uses `StandardERC20Gateway` as the default ERC20 gateway for new ERC20 tokens unless a custom gateway is already set up.
+Se proporcionan varios contratos de gateway ERC20 para conectar diferentes tipos de tokens ERC20, como tokens ERC20 estándar, tokens ERC20 personalizados y Wrapped ETH. El `L1GatewayRouter` registra la asignación canónica de tokens ERC20 a la correspondiente gateway ERC20 en la L1. El `L1GatewayRouter` utiliza `StandardERC20Gateway` como gateway ERC20 por defecto para los nuevos tokens ERC20 a menos que ya se haya configurado una gateway personalizada.
-The deposit of ERC20 tokens works as follows.
+El depósito de tokens ERC20 funciona de la siguiente manera.
-1. To deposit ERC20 tokens from L1 to L2, users can use `L1GatewayRouter.depositERC20` and `L1GatewayRouter.depositERC20AndCall` shown below.
+1. Para depositar tokens ERC20 de L1 a L2, los usuarios pueden utilizar `L1GatewayRouter.depositERC20` y `L1GatewayRouter.depositERC20AndCall` que se muestran a continuación.
```solidity
function depositERC20(address _token, uint256 _amount, uint256 _gasLimit) external payable;
@@ -80,43 +80,43 @@ The deposit of ERC20 tokens works as follows.
) public payable;
```
-2. Based on the mapping from ERC20 tokens to gateway, the `L1GatewayRouter` calls to the corresponding gateway: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, or `L1WETHGateway`. The remaining of steps will be described separately.
+2. En función del mapping entre los tokens ERC20 y la gateway, el `L1GatewayRouter` llama a la gateway correspondiente: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, o `L1WETHGateway`. El resto de pasos se describirán por separado.
-### Standard ERC20 Tokens
+### ERC20 Tokens Estándares
-Standard ERC20 tokens are tokens that do not require any custom logic. For such tokens, their L2 ERC20 token contracts are created by `L2StandardERC20Gateway`. The remaining steps for standard ERC20 token deposit are:
+Los tokens ERC20 estándar son tokens que no requieren ninguna lógica personalizada. Para estos tokens, sus contratos de tokens L2 ERC20 se crean mediante `L2StandardERC20Gateway`. Los pasos restantes para el depósito de tokens ERC20 estándar son:
-3. The `L1StandardERC20Gateway` contract locks the ERC20 tokens by transferring them from the sender to itself.
-4. If this ERC20 token hasn't been withdrawn through `L1StandardERC20Gateway` before, `L1StandardERC20Gateway` will compute a deterministic L2 ERC20 token address and appends the token metadata (symbol, name, and decimals) to the message for the potential contract deployment on L2. If the L2 token address is already stored in the `tokenMapping`, `L1StandardERC20Gateway` will directly load the L2 token address from the mapping.
-5. `L1StandardERC20Gateway` encodes the token deposit message and calls `L1ScrollMessenger` to send the message.
-6. The corresponding L2 transaction calls the `L2ScrollMessenger.relayMessage` function to finalize the deposit on L2. In the case of standard ERC20 token deposits, the transaction then calls `L2StandardERC20Gateway.finalizeDepositERC20`.
-7. If this ERC20 token contract hasn't been deployed on L2, `L2StandardERC20Gateway` will extract the token metadata from the message and calls `ScrollStandardERC20Factory` to deploy the standard ERC20 token on L2.
-8. `L2StandardERC20Gateway` calls the mint function on the corresponding L2 ERC20 token contract.
-9. If the user calls `depositERC20AndCall` on L1, the `L2StandardERC20Gateway` will call the target L2 contract with additional data.
+3. El contrato `L1StandardERC20Gateway` bloquea los tokens ERC20 transfiriéndolos del emisor a sí mismo.
+4. Si este token ERC20 no se ha retirado antes a través de `L1StandardERC20Gateway`, `L1StandardERC20Gateway` calculará una dirección determinista de token ERC20 L2 y añadirá los metadatos del token (símbolo, nombre y decimales) al mensaje para el posible despliegue del contrato en L2. Si la dirección del token L2 ya está almacenada en el `tokenMapping`, `L1StandardERC20Gateway` cargará directamente la dirección del token L2 desde el mapeo.
+5. `L1StandardERC20Gateway` codifica el mensaje de depósito de tokens y llama a `L1ScrollMessenger` para enviar el mensaje.
+6. La transacción L2 correspondiente llama a la función `L2ScrollMessenger.relayMessage` para finalizar el depósito en L2. En el caso de depósitos de tokens ERC20 estándar, la transacción llama entonces a `L2StandardERC20Gateway.finalizeDepositERC20`.
+7. Si este contrato de token ERC20 no se ha desplegado en L2, `L2StandardERC20Gateway` extraerá los metadatos del token del mensaje y llama a `ScrollStandardERC20Factory` para desplegar el token ERC20 estándar en L2.
+8. `L2StandardERC20Gateway` llama a la función mint en el contrato de token ERC20 L2 correspondiente.
+9. Si el usuario llama a `depositERC20AndCall` en L1, `L2StandardERC20Gateway` llamará al contrato L2 de destino con datos adicionales.
-### Custom ERC20 Tokens
+### ERC20 Tokens Personalizados
-In comparison to standard ERC20 tokens, the L2 contract of custom ERC20 tokens are deployed by the token owner. The remaining steps for custom ERC20 token deposit are:
+En comparación con los tokens ERC20 estándares, el contrato L2 de los tokens ERC20 personalizados es desplegado por el propietario del token. Los pasos restantes para el depósito de tokens ERC20 personalizados son:
-3. The `L1CustomERC20Gateway` contract locks the ERC20 tokens on L1 by transferring them from the sender to itself.
-4. `L1CustomERC20Gateway` requires a L2 ERC20 token address present in the `tokenMapping`. It retrieves the corresponding ERC20 token address, encodes the token deposit message, and forwards it to `L1ScrollMessenger`.
-5. The corresponding L2 transaction calls the `L2ScrollMessenger.relayMessage` function to finalize the deposit on L2. In the case of custom ERC20 token deposits, the transaction calls `L2CustomERC20Gateway.finalizeDepositERC20`.
-6. `L2CustomERC20Gateway` calls the mint function on the corresponding L2 ERC20 token contract. It is required that the L2 ERC20 token contract grants mint permissions to the `L2CustomERC20Gateway` contract.
-7. If the user calls `depositERC20AndCall` on L1, the `L2CustomERC20Gateway` will call the target L2 contract with additional data.
+3. El contrato `L1CustomERC20Gateway` bloquea los tokens ERC20 en L1 transfiriéndolos del emisor a sí mismo.
+4. El contrato `L1CustomERC20Gateway` requiere una dirección de token ERC20 L2 presente en el `tokenMapping`. Recupera la dirección de token ERC20 correspondiente, codifica el mensaje de depósito de token y lo reenvía a `L1ScrollMessenger`.
+5. La transacción L2 correspondiente llama a la función `L2ScrollMessenger.relayMessage` para finalizar el depósito en L2. En el caso de depósitos de tokens ERC20 personalizados, la transacción llama a `L2CustomERC20Gateway.finalizeDepositERC20`.
+6. L2CustomERC20Gateway" llama a la función "mint" en el correspondiente contrato de tokens ERC20 de L2. Es necesario que el contrato de tokens L2 ERC20 conceda permisos de emisión al contrato `L2CustomERC20Gateway`.
+7. Si el usuario llama a `depositERC20AndCall` en L1, la `L2CustomERC20Gateway` llamará al contrato L2 de destino con datos adicionales.
### WETH Token
-We provide a custom gateway `L1WETHGateway` for Wrapped ETH token on L1 and record the gateway address in the `L1GatewayRouter`. The deposit of WETH token works as follows.
+Proporcionamos una gateway personalizada `L1WETHGateway` para Wrapped ETH token en L1 y registramos la dirección de la gateway en el `L1GatewayRouter`. El depósito del token WETH funciona de la siguiente manera.
-3. `L1WETHGateway` locks the WETH tokens by transferring them from the sender to itself and unwrapping the WETH token to native ETH token. The ETH token and `msg.value` (for paying the relay fee) are then sent to the `L1ScrollMessenger` contract together.
-4. `L1WETHGateway` encodes the token deposit message and forwards it to `L1ScrollMessenger`.
-5. The corresponding L2 transaction calls the `L2ScrollMessenger.relayMessage` function to finalize the deposit on L2. In the case of WETH token deposit, the transaction calls `L2WETHGateway.finalizeDepositERC20`.
-6. `L2WETHGateway` wraps the deposited ETH to L2 WETH token again and transfers it to the recipient address on L2.
-7. If the user calls `depositERC20AndCall` on L1, the `L2WETHGateway` will call the target L2 contract with additional data.
+3. `L1WETHGateway` bloquea los tokens WETH transfiriéndolos del remitente a sí mismo y desenvolviendo el token WETH a token ETH nativo. A continuación, el token ETH y `msg.value` (para pagar la comisión de retransmisión) se envían juntos al contrato `L1ScrollMessenger`.
+4. `L1WETHGateway` codifica el mensaje de depósito del token y lo reenvía a `L1ScrollMessenger`.
+5. La transacción L2 correspondiente llama a la función `L2ScrollMessenger.relayMessage` para finalizar el depósito en L2. En el caso del depósito de tokens WETH, la transacción llama a `L2WETHGateway.finalizeDepositERC20`.
+6. `L2WETHGateway` envuelve de nuevo el token ETH depositado en L2 WETH y lo transfiere a la dirección del destinatario en L2.
+7. Si el usuario llama a `depositERC20AndCall` en L1, `L2WETHGateway` llamará al contrato de destino en L2 con datos adicionales.
-## Depositing ERC-721/ERC-1155 Tokens
+## Depósito de tokens ERC-721/ERC-1155
-The deposit of ERC-721 or ERC-1155 tokens works very similar to ERC20 tokens. One can use the gateways `L1ERC721Gateway` or `L1ERC1155Gateway` to deposit ERC-721 /ERC-1155 tokens from L1.
+El depósito de tokens ERC-721 o ERC-1155 funciona de forma muy similar a los tokens ERC20. Se pueden utilizar las gateways `L1ERC721Gateway` o `L1ERC1155Gateway` para depositar tokens ERC-721 /ERC-1155 desde L1.
```solidity
function depositERC721(
@@ -148,7 +148,7 @@ function depositERC1155(
) external payable;
```
-To facilitate a large amount of ERC-721 or ERC-1155 token deposits, we also provide batch deposit functions in the `L1ERC721Gateway` and `L1ERC1155Gateway` contract via the following functions:
+Para facilitar una gran cantidad de depósitos de tokens ERC-721 o ERC-1155, también proporcionamos funciones de depósito por lotes en el contrato `L1ERC721Gateway` y `L1ERC1155Gateway` a través de las siguientes funciones:
```solidity
function batchDepositERC721(
@@ -180,4 +180,4 @@ function batchDepositERC1155(
) external payable;
```
-The L2 counterpart contracts for ERC-721 or ERC-1155 tokens are `L2ERC721Gateway` and `L2ERC1155Gateway`. These are used to finalize deposits on L2.
+Los contratos de contrapartida de L2 para los tokens ERC-721 o ERC-1155 son `L2ERC721Gateway` y `L2ERC1155Gateway`. Se utilizan para finalizar depósitos en L2.
diff --git a/src/content/docs/es/technology/bridge/withdraw-gateways.mdx b/src/content/docs/es/technology/bridge/withdraw-gateways.mdx
index f46c5d951..13f1eb71c 100644
--- a/src/content/docs/es/technology/bridge/withdraw-gateways.mdx
+++ b/src/content/docs/es/technology/bridge/withdraw-gateways.mdx
@@ -1,40 +1,40 @@
---
section: technology
date: Last Modified
-title: "Withdraw Gateways"
-lang: "en"
+title: "Gateways de Retiro"
+lang: "es"
permalink: "technology/bridge/withdraw-gateways"
-whatsnext: { "Sequencer": "/technology/sequencer/execution-node/" }
+whatsnext: { "Secuenciador": "/es/technology/sequencer/execution-node/" }
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
import WithdrawWorkflow from "../_images/withdraw.png"
-This document describes how users and developers can utilize gateways to withdraw tokens from L2 to L1. We provide several gateways for standard tokens and a gateway router on L2, listed in the table below.
+Este documento describe cómo los usuarios y desarrolladores pueden utilizar las gateways para retirar tokens de L2 a L1. Proporcionamos varias gateways para tokens estándares y un gateway router en L2, listados en la siguiente tabla.
-| Gateway Contract | Description |
+| Gateway Contract | Descripción |
| ------------------------ | ------------------------------------------------------------------- |
-| `L2GatewayRouter` | The gateway router supports the withdrawal of ETH and ERC20 tokens. |
-| `L2ETHGateway` | The gateway for ETH withdrawals. |
-| `L2StandardERC20Gateway` | The gateway for standard ERC20 token withdrawals. |
-| `L2CustomERC20Gateway` | The gateway for custom ERC20 token withdrawals. |
-| `L2WETHGateway` | The gateway for Wrapped ETH withdrawals. |
-| `L2ERC721Gateway` | The gateway for ERC-721 token withdrawals. |
-| `L2ERC1155Gateway` | The gateway for ERC-1155 token withdrawals. |
+| `L2GatewayRouter` | La gateway router admite el retiro de tokens ETH y ERC20. |
+| `L2ETHGateway` | La gateway para los retiros de ETH. |
+| `L2StandardERC20Gateway` | La gateway para los retiros de tokens ERC20 estándares. |
+| `L2CustomERC20Gateway` | La gateway para los retiros de tokens ERC20 personalizados. |
+| `L2WETHGateway` | La gateway para los retiros de Wrapped ETH. |
+| `L2ERC721Gateway` | La gateway para los retiros de tokens ERC-721. |
+| `L2ERC1155Gateway` | La gateway para los retiros de tokens ERC-1155. |
-## Overview
+## Vista General
-The figure depicts the withdrawal workflow from L2 to L1. Users call the gateways to initialize the token withdrawal. The withdrawal is encoded into a message sent to the `L2ScrollMessenger`, which is then appended to the `L2MessageQueue`. `L2MessageQueue` maintains a Withdraw Trie and updates the root every time a new message appended. The Withdraw Trie root is finalized on the L1 rollup contract along with the L2 state root. After the new Withdraw Trie root is finalized on the L1, users or third parties can then construct a valid Merkle Inclusion Proof to the Withdraw Trie root and send a _withdraw execution_ transaction to finalize the withdrawal on L1. You can find more details about the L2-to-L1 message relay workflow in the [Cross-Domain Messaging](/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1).
+La figura muestra el flujo de trabajo de retiro de L2 a L1. Los usuarios llaman a las gateways para iniciar el retiro de tokens. El retiro se codifica en un mensaje que se envía a `L2ScrollMessenger`, que luego se añade a `L2MessageQueue`. L2MessageQueue mantiene un Withdraw Trie y actualiza la "root" cada vez que se añade un nuevo mensaje. La root del Withdraw Trie se finaliza en el contrato de rollup L1 junto con la state root L2. Una vez finalizada la nueva root del Withdraw Trie en la L1, los usuarios o terceros pueden construir una Merkle Inclusion Proof válida para la root del Withdraw Trie y enviar una transacción _withdraw execution_ para finalizar el retiro en la L1. Encontrará más información sobre el flujo de trabajo de retransmisión de mensajes de L2 a L1 en [Cross-Domain Messaging] (/es/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1).
-The subsequent sections describe the details of how different tokens are withdrawn.
+Las secciones siguientes describen los detalles de cómo se retiran las diferentes tokens.
-## Withdrawing ETH
+## Retiro de ETH
-The withdrawal of ETH token works as follows.
+El retiro del token ETH funciona de la siguiente manera.
-1. `L2GatewayRouter` provides three functions to withdraw ETH from L2 to L1. `withdrawETHAndCall` function can withdraw ETH and execute a contract call at the same time.
+1. L2GatewayRouter" ofrece tres funciones para retirar ETH de L2 a L1. La función `withdrawETHAndCall` puede retirar ETH y ejecutar una llamada de contrato al mismo tiempo.
```solidity
function withdrawETH(uint256 _amount, uint256 _gasLimit) external payable;
@@ -49,16 +49,16 @@ The withdrawal of ETH token works as follows.
) external payable;
```
-2. The `withdrawETHAndCall` functions call into `L2ETHGateway`. `L2ETHGateway` encodes the withdraw message and sends it to the `L2ScrollMessenger` contract along with the withdrawn ETH.
-3. The withdrawn ETH is again locked in the `L2ScrollMessenger` contract. `L2ScrollMessenger` appends the message to the message queue in the `L2MessageQueue` contract.
-4. The withdrawal execution transaction on L1 calls the `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawal. In the case of ETH withdrawal, the `relayMessageWithProof` function calls `L1ETHGateway.finalizeWithdrawETH` to send back ETH to the recipient account on L1.
-5. If the user calls `withdrawETHAndCall` on L2, the `finalizeWithdrawETH` in the `L1ETHGateway` contract will forward the additional data to the target L1 contract.
+2. Las funciones `withdrawETHAndCall` llaman a `L2ETHGateway`. L2ETHGateway" codifica el mensaje de retirada y lo envía al contrato "L2ScrollMessenger" junto con la ETH retirada.
+3. La ETH retirada se bloquea de nuevo en el contrato "L2ScrollMessenger". L2ScrollMessenger añade el mensaje a la cola de mensajes del contrato L2MessageQueue.
+4. La transacción de ejecución de la retirada en L1 llama a la función `L1ScrollMessenger.relayMessageWithProof` para finalizar la retirada. En el caso de la retirada de ETH, la función "relayMessageWithProof" llama a "L1ETHGateway.finalizeWithdrawETH" para devolver ETH a la cuenta del destinatario en L1.
+5. Si el usuario llama a `withdrawETHAndCall` en L2, la función `finalizeWithdrawETH` del contrato `L1ETHGateway` reenviará los datos adicionales al contrato L1 de destino.
-## Withdrawing ERC20 Tokens
+## Retiro de tokens ERC20
-The withdraw of ERC20 tokens works as follows.
+El retiro de tokens ERC20 funciona de la siguiente manera.
-1. To withdraw ERC20 tokens from L1 to L2, users can use `L2GatewayRouter.withdrawERC20` and `L2GatewayRouter.withdrawERC20AndCall` showed below.
+1. Para retirar tokens ERC20 de L1 a L2, los usuarios pueden utilizar `L2GatewayRouter.withdrawERC20` y `L2GatewayRouter.withdrawERC20AndCall` como se muestra a continuación.
```solidity
function withdrawERC20(address _token, uint256 _amount, uint256 _gasLimit) external payable;
@@ -74,31 +74,31 @@ The withdraw of ERC20 tokens works as follows.
) public payable;
```
-2. Based on the mapping from ERC20 tokens to gateway, the `L2GatewayRouter` calls to the corresponding gateway, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, or `L2WETHGateway`. The remaining of steps will be described separately.
+2. En función del mapping de los tokens ERC20 a la gateway, el `L2GatewayRouter` llama a la gateway correspondiente, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, o `L2WETHGateway`. El resto de pasos se describirán por separado.
-### Standard and Custom ERC20 Tokens
+### Tokens ERC20 estándares y personalizados
-The withdrawal of standard and custom ERC20 tokens works in the same way as follows.
+El retiro de tokens ERC20 estándar y personalizados funciona de la siguiente manera.
-3. The `L2StandardERC20Gateway` or `L2CustomERC20Gateway` contract burns the withdrawn ERC20 token, encodes the withdrawal into a message, and sends it to `L2ScrollMessenger`.
-4. The L1 withdrawal execution transaction calls `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawals on L1. In the case of standard or custome ERC20 token withdrawal, the transaction calls `finalizeWithdrawERC20` function on the `L1StandardERC20Gateway` or `L1CustomERC20Gateway` contract respectively.
- - In the `L1StandardERC20Gateway` contract, if this is the first withdrawal transaction of a ERC20 token, `finalizeWithdrawERC20` function will update the mapping from L1 token address to its L2 token address in the `tokenMapping`.
-5. The L1 ERC20 token gateway releases the locked ERC20 tokens by transferring them from itself to the recipient address on L1.
-6. If the user calls `withdrawERC20AndCall` on L2, the gateways will call the target L1 contract with additional data.
+3. El contrato `L2StandardERC20Gateway` o `L2CustomERC20Gateway` quema el token ERC20 retirado, codifica la retirada en un mensaje y lo envía a `L2ScrollMessenger`.
+4. La transacción de ejecución de retiro de L1 llama a la función `L1ScrollMessenger.relayMessageWithProof` para finalizar los retiros en L1. En caso de un retiro de tokens ERC20 estándar o personalizados, la transacción llama a la función `finalizeWithdrawERC20` en el contrato `L1StandardERC20Gateway` o `L1CustomERC20Gateway` respectivamente.
+ - En el contrato `L1StandardERC20Gateway`, si se trata de la primera transacción de retirada de un token ERC20, la función `finalizeWithdrawERC20` actualizará la asignación de la dirección del token L1 a su dirección del token L2 en el `tokenMapping`.
+5. La gateway de tokens ERC20 L1 libera los tokens ERC20 bloqueados transfiriéndolos desde sí misma a la dirección del destinatario en L1.
+6. Si el usuario llama a `withdrawERC20AndCall` en L2, las gateways llamarán al contrato L1 de destino con datos adicionales.
### WETH Token
-We provide a custom gateway `L2WETHGateway` for Wrapped ETH token on L2 and record the gateway address in the `L2GatewayRouter`. The withdrawal of WETH token works as follows.
+Proporcionamos una gateway personalizada `L2WETHGateway` para Wrapped ETH token en L2 y registramos la dirección de la gateway en el `L2GatewayRouter`. El retiro del token WETH funciona de la siguiente manera.
-3. `L2WETHGateway` transfers the withdrawn WETH token to itself and unwraps WETH token to native ETH token. The ETH token is then sent back to the `L2ScrollMessenger` contract.
-4. `L2WETHGateway` encodes the token withdrawal message and forwards it to `L2ScrollMessenger`.
-5. The L1 withdrawal execution transaction calls `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawal on L1. In the case of WETH token withdrawal, the transaction calls `L1WETHGateway.finalizeWithdrawERC20` and sends the withdrawn amount in ETH to `L1WETHGateway`.
-6. `L1WETHGateway` wraps the withdrawn ETH to L1 WETH token again and transfers to the recipient address on L1.
-7. If the user calls `withdrawERC20AndCall` on L2, the `L1WETHGateway` will call the target L1 address with additional data.
+1. `L2WETHGateway` transfiere el token WETH retirado a sí mismo y "desenvuelve" el token WETH a token ETH nativo. A continuación, el token ETH se devuelve al contrato `L2ScrollMessenger`.
+2. `L2WETHGateway` codifica el mensaje de retiro del token y lo reenvía a `L2ScrollMessenger`.
+3. La transacción de ejecución del retiro en L1 llama a la función `L1ScrollMessenger.relayMessageWithProof` para finalizarlo en L1. En el caso del retiro de tokens WETH, la transacción llama a `L1WETHGateway.finalizeWithdrawERC20` y envía el importe retirado en ETH a `L1WETHGateway`.
+4. `L1WETHGateway` vuelve a convertir el ETH retirado en un token WETH L1 y lo transfiere a la dirección del destinatario en L1.
+5. Si el usuario llama a `withdrawERC20AndCall` en L2, `L1WETHGateway` llamará a la dirección L1 de destino con datos adicionales.
-## Withdrawing ERC-721/ERC-1155 Tokens
+## Retiro de tokens ERC-721/ERC-1155
-The withdrawal of ERC-721 or ERC-1155 tokens works very similar to ERC20 tokens. One can use the gateway `L2ERC721Gateway` or `L2ERC1155Gateway` to withdraw ERC-721 /ERC-1155 tokens from L2.
+El retiro de tokens ERC-721 o ERC-1155 funciona de forma muy similar a los tokens ERC20. Se puede utilizar la gateway `L2ERC721Gateway` o `L2ERC1155Gateway` para retirar tokens ERC-721 /ERC-1155 de L2.
```solidity
function withdrawERC721(
@@ -130,7 +130,7 @@ function withdrawERC1155(
) external payable;
```
-To facilitate a large amount of ERC-721 or ERC-1155 token withdrawals, we also provide batch withdraw functions in the `L2ERC721Gateway` and `L2ERC1155Gateway` contract via the following functions:
+Para facilitar el retiro de una gran cantidad de tokens ERC-721 o ERC-1155, también proporcionamos funciones de retiro por lotes en el contrato `L2ERC721Gateway` y `L2ERC1155Gateway` a través de las siguientes funciones:
```solidity
function batchWithdrawERC721(
@@ -162,4 +162,4 @@ function batchWithdrawERC1155(
) external payable;
```
-The L1 counterpart contracts for ERC-721 or ERC-1155 tokens are `L1ERC721Gateway` and `L1ERC1155Gateway` to finalize withdrawals on L1.
+Los contratos de contraparte en L1 para tokens ERC-721 o ERC-1155 son `L1ERC721Gateway` y `L1ERC1155Gateway` para finalizar los retiros en L1.
\ No newline at end of file
diff --git a/src/content/docs/es/technology/chain/accounts.mdx b/src/content/docs/es/technology/chain/accounts.mdx
index fb1d2e85c..bfa14293b 100644
--- a/src/content/docs/es/technology/chain/accounts.mdx
+++ b/src/content/docs/es/technology/chain/accounts.mdx
@@ -1,29 +1,29 @@
---
section: technology
date: Last Modified
-title: "Accounts and State"
-lang: "en"
+title: "Cuentas y Estados"
+lang: "es"
permalink: "technology/chain/accounts-and-state"
-whatsnext: { "Transactions": "/technology/chain/transactions/" }
+whatsnext: { "Transacciones": "/es/technology/chain/transactions/" }
---
-## Accounts
+## Cuentas
-Same as Ethereum, Scroll has two account types: Externally-owned account (EOA) and contract account that holds the smart contract and additional storages.
+Al igual que Ethereum, Scroll tiene dos tipos de cuenta: Cuenta de propiedad externa (EOA) y cuenta de contrato que contiene el smart contract y almacenamientos adicionales.
-Scroll stores additional information of the contract bytecode in the account to facilitate the zkEVM circuit to prove the state transition more efficiently.
+Scroll almacena información adicional en el bytecode del contrato en la cuenta para facilitar que el circuito zkEVM pruebe la transición de estado de forma más eficiente.
-The account in Scroll contains the following fields:
+La cuenta en Scroll contiene los siguientes campos:
-- `nonce`: A counter that indicates the number of transactions sent by the sender.
-- `balance`: The balance of `ETH` token in the account balance (unit in wei).
-- `storageRoot`: The root hash of the storage trie. Since Scroll uses the [zkTrie](/technology/sequencer/zktrie) for the storage trie, the `storageRoot` stores the Poseidon hash digest in a 256-bit integer.
-- `codeHash`: The Keccak hash digest of the contract bytecode.
-- `PoseidonCodeHash` (**new field**): The Poseidon hash digest of the contract bytecode in a 256-bit integer.
-- `CodeSize` (**new field**): The number of bytes in the contract bytecode.
+- `nonce`: Un contador que indica el número de transacciones enviadas por el emisor.
+- `balance`: El saldo del token `ETH` en el balance de la cuenta (unidad en wei).
+- `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.
-## State
+## Estado
-The state of a blockchain is a collection of account data. The _state trie_ encodes account data and their corresponding addresses to a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) data structure. The root of tree, or the state of the blockchain, is a cryptographic digest of all the account data contained in the tree.
+El estado de una blockchain es una colección de datos de cuentas. El _state trie_ codifica los datos de las cuentas y sus correspondientes direcciones en una estructura de datos [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree). La "root del tree", o el estado del blockchain, es un compendio criptográfico de todos los datos de cuentas contenidos en el árbol.
-Ethereum uses a data structure called [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for both the state trie and the storage trie that stores the key-value entries stored in a smart contract. In Scroll, we replace the Patricia Merkle Trie by a more zk-friendly data structure, called zkTrie, for both state trie and storage trie. In the high level, the zkTrie data structure is a sparse binary Merkle tree with the [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), a zk-friendly hash function. The [zkTrie](/technology/sequencer/zktrie) document describes more details about this data structure.
+Ethereum utiliza una estructura de datos llamada [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) tanto para el trie de estado como para el trie de almacenamiento que guarda las entradas llave-valor almacenadas en un smart contract. En Scroll, sustituimos Patricia Merkle Trie por una estructura de datos más compatible con zk, llamada zkTrie, tanto para la trie de estado como para la trie de almacenamiento. A alto nivel, la estructura de datos zkTrie es un Merkle tree binario disperso con [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), una función hash compatible con zk. El documento [zkTrie](/es/technology/sequencer/zktrie) describe más detalles sobre esta estructura de datos.
diff --git a/src/content/docs/es/technology/chain/blocks.mdx b/src/content/docs/es/technology/chain/blocks.mdx
index a7a9a5f92..e7f099e35 100644
--- a/src/content/docs/es/technology/chain/blocks.mdx
+++ b/src/content/docs/es/technology/chain/blocks.mdx
@@ -1,37 +1,37 @@
---
section: technology
date: Last Modified
-title: "Blocks"
-lang: "en"
+title: "Bloques"
+lang: "es"
permalink: "technology/chain/blocks"
-whatsnext: { "Rollup Process": "/technology/chain/rollup/" }
+whatsnext: { "Proceso del Rollup": "/es/technology/chain/rollup/" }
---
-A block is a collection of transactions and links to the previous block it extends.
+Un bloque es una recopilación de transacciones y enlaces con el bloque anterior al que amplía.
## Block Header
-The block header in Scroll mirrors the structure of Ethereum's. However, certain fields in the block header have been modified to accommodate the Layer 2 context, as detailed in the following table:
+La block header en Scroll refleja la estructura de Ethereum. Sin embargo, algunos campos de la block header se han modificado para adaptarse al contexto de la capa 2, como se detalla en la siguiente tabla:
-| Field | Description |
+| Campo | Descripción |
| ------------------- | ------------------------------------------------------------------ |
-| `parentHash` | The hash of the parent block. |
-| `uncleHash` | Always 0. |
-| `coinbase` | Pre-deployed fee vault contract address `0x5300000000000000000000000000000000000005`. |
-| `stateRoot` | The root hash of the state trie. It is the Poseidon |
-| `transactionsRoot ` | The hash of the transaction trie. |
-| `receiptsRoot ` | The hash of the transaction receipts trie. |
-| `logsBloom` | The data structure containing event logs |
-| `difficulty` | Always 0. |
-| `number` | The block number. |
-| `gasLimit` | The maximum gas allowed in the block. |
-| `gasUsed` | The gas used in the block. |
-| `timestamp` | The block time. |
-| `extraData` | Arbitrary additional data. |
-| `mixHash` | Always 0. |
-| `nonce` | Always 0. |
-| `baseFee` | Currently empty in Scroll because we haven't enabled the EIP-1559. |
+| `parentHash` | El hash del bloque padre. |
+| `uncleHash` | Siempre 0. |
+| `coinbase` | Dirección del contrato de la vault de comisiones pre-desplegada `0x5300000000000000000000000000000000000005`. |
+| `stateRoot` | El hash root del state trie. Esto es Poseidon. |
+| `transactionsRoot ` | El hash del trie de transacción. |
+| `receiptsRoot ` | El hash del trie del comprobante de la transacción. |
+| `logsBloom` | La estructura de datos que contiene los registros de eventos. |
+| `difficulty` | Siempre 0. |
+| `number` | El número del Bloque. |
+| `gasLimit` | El gas máximo permitido en el bloque. |
+| `gasUsed` | El gas utilizado en el bloque. |
+| `timestamp` | El tiempo del bloque. |
+| `extraData` | Datos arbitrarios adicionales. |
+| `mixHash` | Siempre 0. |
+| `nonce` | Siempre 0. |
+| `baseFee` | Actualmente vacío en Scroll porque no hemos activado el EIP-1559. |
-## Block Time
+## Tiempo de bloque
-Block time refers to the interval between two consecutive blocks. In Scroll, the block time is set at 3s. A reduced block time elevates the user experience and augments the Scroll chain's scalability.
+El tiempo de bloque se refiere al intervalo entre dos bloques consecutivos. En Scroll, el tiempo de bloque está fijado en 3s. Un tiempo de bloque reducido mejora la experiencia del usuario y aumenta la escalabilidad de la cadena de Scroll.
diff --git a/src/content/docs/es/technology/chain/differences.mdx b/src/content/docs/es/technology/chain/differences.mdx
index bbb6dac52..a5c69ad82 100644
--- a/src/content/docs/es/technology/chain/differences.mdx
+++ b/src/content/docs/es/technology/chain/differences.mdx
@@ -1,46 +1,46 @@
---
section: technology
date: Last Modified
-title: "EVM Differences from Ethereum"
-lang: "en"
+title: "Diferencias de EVM respecto a Ethereum"
+lang: "es"
permalink: "technology/chain/differences"
-whatsnext: { "Bridge": "/technology/bridge/cross-domain-messaging/" }
+whatsnext: { "Bridge": "/es/technology/bridge/cross-domain-messaging/" }
---
## Opcodes
-| Opcode | Scroll Behavior |
+| Opcode | Comportamiento de Scroll |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| `BLOCKHASH` | Returns `keccak(chain_id \|\| block_number)` for the last 256 blocks. |
-| `COINBASE` | Returns the fee vault address (predeployed contract `0x5300000000000000000000000000000000000005`). |
-| `DIFFICULTY` / `PREVRANDAO` | Always return 0. |
-| `BASEFEE` | Disabled because currently we disabled EIP-1559. If the opcode is encountered, the transaction will be reverted. |
-| `SELFDESTRUCT` | Disabled. If the opcode is encountered, the transaction will be reverted. |
+| `BLOCKHASH` | Devuelve `keccak(chain_id \|\| block_number)` para los últimos 256 bloques. |
+| `COINBASE` | Devuelve la dirección de la vault de comisiones (contrato predesplegado `0x53000000000000000000000000000000000000000005`). |
+| `DIFFICULTY` / `PREVRANDAO` | Devuelve siempre 0. |
+| `BASEFEE` | Desactivado porque actualmente desactivamos el EIP-1559. Si el opcode es detectado, la transacción será revertida. |
+| `SELFDESTRUCT` | Desactivado. Si el opcode es detectado, la transacción será revertida. |
-## Precompiled Contracts
+## Contratos Precompilados
-| Address | Name | Scroll behavior |
+| Dirección | Nombre | Comportamiento de Scroll |
| ------- | ------------ | ----------------------------------------------------------------------------------------------- |
-| `0x02` | `SHA2-256` | Currently not supported. |
-| `0x03` | `RIPEMD-160` | Currently not supported. |
-| `0x05` | `modexp` | Restrict the input values `B, E, M` to unsigned integers less than $2^{256}$. |
-| `0x08` | `ecPairing` | The inputs are still multiple of 6 32-byte values, but limit the number of tuples to at most 4. |
-| `0x09` | `blake2f` | Currently not supported. |
+| `0x02` | `SHA2-256` | Actualmente no soportado. |
+| `0x03` | `RIPEMD-160` | Actualmente no soportado. |
+| `0x05` | `modexp` | Restringe los valores de entrada `B, E, M` a enteros sin signo menores que $2^{256}$. |
+| `0x08` | `ecPairing` | Las entradas siguen siendo múltiplos de 6 valores de 32 bytes, pero limitan el número de tuplas a un máximo de 4. |
+| `0x09` | `blake2f` | Actualmente no soportado. |
-The remaining precompiled contracts have the same behavior as Ethereum. However, their maximum usage within a block is constrained by a limit tied to the zkEVM circuit capacity.
+El resto de contratos precompilados tienen el mismo comportamiento que Ethereum. Sin embargo, su uso máximo dentro de un bloque está restringido por un límite ligado a la capacidad del circuito zkEVM.
## EIPs
-Our sequencer was developed based on the London fork initially. We disabled some EIPs in the London fork and introduced a few EIPs from the Shanghai fork to improve the compatibility.
+Nuestro secuenciador se desarrolló basándose inicialmente en la London fork. Deshabilitamos algunos EIPs en la London fork e introdujimos algunos EIPs de la Shanghai fork para mejorar la compatibilidad.
-Disabled EIPs until the London fork:
+EIPs deshabilitados hasta la London fork:
-- [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Fee market change and EIP-1559 transaction type
-- [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930): Optional access lists
-- [EIP-3198](https://eips.ethereum.org/EIPS/eip-3198): `BASEFEE` opcode
+- [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Cambio en el "market fee" y tipo de transacción EIP-1559
+- [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930): Listas de acceso opcionales
+- [EIP-3198](https://eips.ethereum.org/EIPS/eip-3198): opcode `BASEFEE`
-EIPs imported from the Shanghai fork:
+EIP importados de la Shanghai fork:
- [EIP-3651](https://eips.ethereum.org/EIPS/eip-3651): Warm `COINBASE`
-- [EIP-3855](https://eips.ethereum.org/EIPS/eip-3855): `PUSH0` instruction
-- [EIP-3860](https://eips.ethereum.org/EIPS/eip-3860): Limit and meter initcode
+- [EIP-3855](https://eips.ethereum.org/EIPS/eip-3855): instrucción `PUSH0`
+- [EIP-3860](https://eips.ethereum.org/EIPS/eip-3860): Límite y medidor initcode
diff --git a/src/content/docs/es/technology/chain/rollup.mdx b/src/content/docs/es/technology/chain/rollup.mdx
index 3c1b4efbc..d934156a3 100644
--- a/src/content/docs/es/technology/chain/rollup.mdx
+++ b/src/content/docs/es/technology/chain/rollup.mdx
@@ -1,57 +1,57 @@
---
section: technology
date: Last Modified
-title: "Rollup Process"
-lang: "en"
+title: "Proceso del Rollup"
+lang: "es"
permalink: "technology/chain/rollup"
-whatsnext: { "EVM Differences from Ethereum": "/technology/chain/differences/" }
+whatsnext: { "Diferencias de EVM respecto a Ethereum": "/es/technology/chain/differences/" }
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
import RollupProcess from "../_images/rollup.png"
-This document describes the rollup process in Scroll.
+Este documneto describe el proceso del Rollup en Scroll
-## Workflow
+## Flujo de Trabajo
-The figure illustrates the rollup workflow. The L2 sequencer contains three modules:
+La figura ilustra el flujo de trabajo del rollup. El secuenciador L2 contiene tres módulos:
-- **Sync service** subscribes to the event issued from the L1 bridge contract. Once it detects any newly appended messages to the L1 inbox, the Sync Service will generate a new `L1MessageTx` transaction accordingly and add it to the local L1 transaction queue.
-- **Mempool** collects the transactions that are directly submitted to the L2 sequencer.
-- **Executor** pulls the transactions from both the L1 transaction queue and L2 mempool, executes them to construct a new L2 block.
+- **Sync Service** se suscribe al evento emitido desde el contrato bridge L1. Una vez que detecta cualquier mensaje recién añadido a la inbox de L1, el Sync Service generará una nueva transacción `L1MessageTx` en consecuencia y la añadirá a la cola local de transacciones L1.
+- **Mempool** recoge las transacciones que se envían directamente al secuenciador L2.
+- El **Executor** extrae las transacciones tanto de la cola de transacciones L1 como de la mempool L2 y las ejecuta para construir un nuevo bloque L2.
-The rollup node contains three modules:
+El nodo rollup contiene tres módulos:
-- **Relayer** submits the commit transactions and finalize transactions to the rollup contract for data availability and finality.
-- **Chunk Proposer** and **Batch Proposer** proposes new chunks and new batches following the constraints described in the [Transaction Batching](/technology/chain/transactions#transaction-batching).
+- **Relayer** envía las transacciones de confirmación y las transacciones de finalización al contrato de rollup para la disponibilidad y la finalidad de los datos.
+- Los módulos **Chunk Proposer** y **Batch Proposer** proponen nuevos chunks y nuevos lotes siguiendo las restricciones descritas en [Lotes de Transacciones](/es/technology/chain/transactions#lotes-de-transacciones).
-The rollup process can be broken down into three phases: transaction execution, batching and data commitment, and proof generation and finalization.
+El proceso de rollup puede dividirse en tres fases: ejecución de transacciones, procesamiento por lotes y compromiso de datos, y generación y finalización de pruebas.
-### Phase 1. Transaction Execution
+### Fase 1. Ejecución de Transacciones
-1. Users submit transactions to L1 bridge contract or L2 sequencers.
-2. The Sync Service in the L2 sequencer fetches the latest appended L1 transactions from the bridge contract.
-3. The L2 sequencer processes the transactions from both the L1 message queue and the L2 mempool to construct L2 blocks.
+1. Los usuarios envían transacciones al contrato bridge L1 o a los secuenciadores L2.
+2. El Sync Service del secuenciador L2 obtiene las últimas transacciones L1 adjuntas del contrato bridge.
+3. El secuenciador L2 procesa las transacciones tanto de la cola de mensajes L1 como del mempool L2 para construir bloques L2.
-### Phase 2. Batching and Data Commitment
+### Fase 2. Procesamiento por Lotes y Compromiso de Datos
-4. The rollup node monitors the latest L2 blocks and fetches the transaction data.
-5. If the criterion (described in the [Transaction Batching](/technology/chain/transactions#transaction-batching)) are met, the rollup node proposes a new chunk or a batch and writes it to the database. Otherwise, the rollup node keeps waiting for more blocks or chunks.
-6. Once a new batch is created, the rollup relayer collects the transaction data in this batch and submits a Commit Transaction to the rollup contract for data availability.
+4. El nodo de rollup monitoriza los últimos bloques L2 y obtiene los datos de la transacción.
+5. Si se cumplen los criterios (descritos en [Lotes de Transacciones](/es/technology/chain/transactions#transaction-batching)), el nodo rollup propone un nuevo chunk o lote y lo escribe en la base de datos. En caso contrario, el nodo rollup seguirá esperando más bloques o chunks.
+6. Una vez creado un nuevo lote, el rollup relayer recopila los datos de la transacción en este lote y envía una Commit Transaction al contrato rollup para la disponibilidad de los datos.
-### Phase 3. Proof Generation and Finalization
+### Fase 3. Generación y Finalización de Pruebas.
-7. Once the coordinator polls a new chunk or batch fromm the database:
- - Upon a new chunk, the coordinator will query the execution traces of all blocks in this chunk from the L2 sequencer and then send a chunk proving task to a randomly selected zkEVM prover.
- - Upon a new batch, the coordinator will collect the chunk proofs of all chunks in this batch from the database and dispatch a batch proving task to a randomly selected aggregator prover.
-8. Upon the coordinator receives a chunk or batch proofs from a prover, it will write the proof to the database.
-9. Once the rollup relayer polls a new batch proof from the database, it will submit a Finalize Transaction to the rollup contract to verify the proof.
+7. Una vez que el coordinador sondea un nuevo chunk o lote de la base de datos:
+ - Ante un nuevo chunk, el coordinador consultará las trazas de ejecución de todos los bloques de este chunk al secuenciador L2 y enviará una proving task de chunk a un prover zkEVM seleccionado al azar.
+ - Ante un nuevo lote, el coordinador recopilará todas las pruebas de todos de los chunks de este lote y enviará una proving task de lote a un prover agregador seleccionado aleatoriamente.
+8. Cuando el coordinador reciba una prueba de chunk o lote de un prover, escribirá la prueba en la base de datos.
+9. Una vez que el rollup relayer obtenga una nueva prueba de lote de la base de datos, enviará una transacción de finalización al contrato de rollup para verificar la prueba.
## Commit Transaction
-The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 message. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise the transaction will be reverted. See the `commitBatch` function signature below.
+La Commit Transaction envía la información del bloque y los datos de la transacción a L1 para la disponibilidad de los datos. La transacción incluye el batch header padre, los datos del chunk y un mapa de bits del mensaje L1 omitido. El batch header padre designa el lote anterior al que se vincula este lote. El lote padre debe confirmarse antes; de lo contrario, la transacción se revertirá. Véase la firma de la función `commitBatch` más abajo.
```solidity
function commitBatch(
@@ -62,19 +62,19 @@ function commitBatch(
) external override OnlySequencer
```
-After the `commitBatch` function verifies the parent batch is committed before, it constructs the batch header of the batch and stores the hash of the batch header in the `ScrollChain` contract.
+Después de que la función `commitBatch` verifique que el lote padre se ha consignado antes, construye el batch header y almacena el hash del mismo en el contrato `ScrollChain`.
```solidity
mapping(uint256 => bytes32) public committedBatches;
```
-The encoding of batch header and chunk data are described in the [Codec](#codec) section. Most fields in the batch header are straight-forward to derive from the chunk data. One important field to note is `dataHash` that will become part of the public input to verify the validity proof. Assuming that a batch contains `n` chunks, its `dataHash` is computed as follows
+La codificación del batch header y de los datos de los chunks se describen en la sección [Codec](#codec). La mayoría de los campos de la batch header son fáciles de derivar de los datos de los chunks. Un campo importante a tener en cuenta es `dataHash` que formará parte de la entrada pública para verificar la prueba de validez. Suponiendo que un lote contiene `n` chunks, su `dataHash` se calcula de la siguiente manera
```
batch.dataHash := keccak(chunk[0].dataHash || ... || chunk[n-1].dataHash)
```
-Assuming that a chunk contains `k` blocks, its `dataHash` is computed as follows
+Suponiendo que un chunk contenga `k` bloques, su `dataHash` se calcula del siguiente modo
```
chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] ||
@@ -82,13 +82,13 @@ chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] ||
block[k-1].l1TxHashes || block[k-1].l2TxHashes)
```
-, where `block.l1TxHashes` are the concatenated transaction hashes of the L1 transactions in this block and `block.l2TxHashes` are the concatenated transaction hashes of the L2 transactions in this block. Note that the transaction hashes of L1 transactions are not uploaded by the rollup node, but instead directly loaded from the `L1MessageQueue` contract given the index range of included L1 messages in this block. The L2 transaction hashes are calculated from the RLP-encoded bytes in the `l2Transactions` field in the [`Chunk`](#Chunk-Codec).
+donde `block.l1TxHashes` son los hashes de transacción concatenados de las transacciones L1 en este bloque y `block.l2TxHashes` son los hashes de transacción concatenados de las transacciones L2 en este bloque. Nótese que los hashes de transacción de las transacciones L1 no son cargados por el nodo rollup, sino que se cargan directamente desde el contrato `L1MessageQueue` dado el rango de índices de los mensajes L1 incluidos en este bloque. Los hashes de transacciones L2 se calculan a partir de los bytes codificados en RLP en el campo `l2Transactions` del [`Chunk`](#Chunk-Codec).
-In addition, the `commitBatch` function contains a bitmap of skipped L1 messages. Unfortunately, this is due to the problem of proof overflow. If the L1 transaction corresponding to a L1 message exceeds the circuit capacity limit, we won't be able to generate a valid proof for this transaction and thus cannot finalize it on L1. Scroll is working actively to eliminate the proof overflow problem through upgrades to our proving system.
+Además, la función `commitBatch` contiene un mapa de bits de los mensajes L1 omitidos. Lamentablemente, esto se debe al problema del sobreflujo de pruebas. Si la transacción L1 correspondiente a un mensaje L1 supera el límite de capacidad del circuito, no podremos generar una prueba válida para esta transacción y, por tanto, no podremos finalizarla en L1. Scroll está trabajando activamente para eliminar el problema del sobreflujo de pruebas mediante actualizaciones de nuestro sistema de pruebas.
-## Finalize Transaction
+## Finalización de la Transacción
-The Finalize Transaction finalizes the previously-committed batch with a validity proof. The transaction also submits the state root and the withdraw root after the batch. Here is the function signature of `finalizeBatchWithProof`:
+La Transacción finaliza con el lote previamente comprometido y su prueba de validez. La transacción también presenta la "state root" y la "withdraw root" después del lote. Esta es la firma de la función `finalizeBatchWithProof`:
```solidity
function finalizeBatchWithProof(
@@ -100,56 +100,56 @@ function finalizeBatchWithProof(
) external override OnlyProver
```
-The `finalizeBatchWithProof` function first verifies if the batch has been committed in the contract. It then calculates the public input hash as follows
+La función `finalizeBatchWithProof` primero verifica si el lote ha sido comprometido en el contrato. A continuación, calcula el hash de entrada público de la siguiente manera
```
publicInputHash := keccak(chainId || prevStateRoot || postStateRoot || withdrawRoot || batch.dataHash)
```
-The public input hash and the validity proof are sent to the plonk solidity verifier. Once the verification passes, the new state root and withdraw root are stored in the `ScrollChain` contract.
+El hash de entrada público y la prueba de validez se envían al verificador de plonk solidity. Una vez superada la verificación, la nueva "state root" y la "withdraw root" se almacenan en el contrato `ScrollChain`.
```solidity
mapping(uint256 => bytes32) public override finalizedStateRoots;
mapping(uint256 => bytes32) public override withdrawRoots;
```
-At this stage, the state root of the latest finalized batch can be used trustlessly and the withdrawal transactions in that batch can be executed on L1 using the Merkle proof to the withdraw root.
+En esta fase, la "state root" del último lote finalizado puede utilizarse de forma trustless y las transacciones de retirada de ese lote pueden ejecutarse en L1 utilizando la prueba de Merkle para la "withdraw root".
## Codec
-This section describes the codec of three data structures in the Rollup contract: `BatchHeader`, `Chunk`, and `BlockContext`.
+Esta sección describe el codec de tres estructuras de datos del contrato Rollup: `BatchHeader`, `Chunk` y `BlockContext`.
-### `BatchHeader` Codec
+### Codec `BatchHeader`
-| Field | Bytes | Type | Offset | Description |
+| Campo | Bytes | Tipo | Offset | Descripción |
| ------------------------ | ------- | ----------- | ------ | --------------------------------------------------------------- |
-| `version` | 1 | `uint8` | 0 | The batch header version |
-| `batchIndex` | 8 | `uint64` | 1 | The index of the batch |
-| `l1MessagePopped` | 8 | `uint64` | 9 | The number of L1 messages poped in the batch |
-| `totalL1MessagePopped` | 8 | `uint64` | 17 | The number of total L1 messages popped after the batch |
-| `dataHash` | 32 | `bytes32` | 25 | The data hash of the batch |
-| `parentBatchHash` | 32 | `bytes32` | 57 | The parent batch hash |
-| `skippedL1MessageBitmap` | dynamic | `uint256[]` | 89 | A bitmap to indicate which L1 messages are skipped in the batch |
+| `version` | 1 | `uint8` | 0 | La versión del batch header. |
+| `batchIndex` | 8 | `uint64` | 1 | El index del lote. |
+| `l1MessagePopped` | 8 | `uint64` | 9 | El número de mensajes L1 emitidos en el lote. |
+| `totalL1MessagePopped` | 8 | `uint64` | 17 | El número total de mensajes L1 emitidos tras el lote. |
+| `dataHash` | 32 | `bytes32` | 25 | El hash de datos del lote. |
+| `parentBatchHash` | 32 | `bytes32` | 57 | El hash del lote padre. |
+| `skippedL1MessageBitmap` | dynamic | `uint256[]` | 89 | Un mapa de bits para indicar qué mensajes L1 se omiten en el lote. |
-### `Chunk` Codec
+### Codec `Chunk`
-| Field | Bytes | Type | Offset | Description |
+| Campo | Bytes | Tipo | Offset | Descripción |
| ---------------- | ------- | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `numBlocks` | 1 | `uint8` | 0 | The number of blocks in the chunk |
-| `block[0]` | 60 | `BlockContext` | 1 | The block information of the 1st block |
+| `numBlocks` | 1 | `uint8` | 0 | El número de bloques del chunk. |
+| `block[0]` | 60 | `BlockContext` | 1 | La información del bloque 1. |
| ... | ... | ... | ... | ... |
-| `block[i]` | 60 | `BlockContext` | `60*i+1` | The block information of `i+1`-th block |
+| `block[i]` | 60 | `BlockContext` | `60*i+1` | La información del bloque `i+1`-ésimo. |
| ... | ... | ... | ... | ... |
-| `block[n-1]` | 60 | `BlockContext` | `60*n-59` | The block information of the last block |
-| `l2Transactions` | dynamic | `bytes` | `60*n+1` | The concatenated RLP encoding of L2 transactions with signatures. The byte length (`uint32`) of RLP encoding is inserted before each transaction. |
+| `block[n-1]` | 60 | `BlockContext` | `60*n-59` | La información del último bloque. |
+| `l2Transactions` | dynamic | `bytes` | `60*n+1` | La codificación RLP concatenada de transacciones L2 con firmas. La longitud en bytes (`uint32`) de la codificación RLP se inserta antes de cada transacción. |
-### `BlockContext` Codec
+### Codec `BlockContext`
-| Field | Bytes | Type | Offset | Description |
+| Campo | Bytes | Tipo | Offset | Descripción |
| ----------------- | ----- | --------- | ------ | ----------------------------------------------------------------------------------- |
-| `blockNumber` | 8 | `uint64` | 0 | The block number |
-| `timestamp` | 8 | `uint64` | 8 | The block time |
-| `baseFee` | 32 | `uint256` | 16 | The base fee of this block. Currently, it is always 0, because we disable EIP-1559. |
-| `gasLimit` | 8 | `uint64` | 48 | The gas limit of this block |
-| `numTransactions` | 2 | `uint16` | 56 | The number of transactions in this block, including both L1 & L2 txs |
-| `numL1Messages` | 2 | `uint16` | 58 | The number of L1 messages in this block |
+| `blockNumber` | 8 | `uint64` | 0 | El número del bloque. |
+| `timestamp` | 8 | `uint64` | 8 | El tiempo del bloque. |
+| `baseFee` | 32 | `uint256` | 16 | La comisión base de este bloque. Actualmente, siempre es 0, porque desactivamos el EIP-1559. |
+| `gasLimit` | 8 | `uint64` | 48 | El límite de gas de este bloque. |
+| `numTransactions` | 2 | `uint16` | 56 | El número de transacciones en este bloque, incluyendo L1 & L2 txs |
+| `numL1Messages` | 2 | `uint16` | 58 | El número de mensajes L1 en este bloque |
diff --git a/src/content/docs/es/technology/chain/transactions.mdx b/src/content/docs/es/technology/chain/transactions.mdx
index 90ac2bfd1..8f4ead38a 100644
--- a/src/content/docs/es/technology/chain/transactions.mdx
+++ b/src/content/docs/es/technology/chain/transactions.mdx
@@ -1,32 +1,32 @@
---
section: technology
date: Last Modified
-title: "Transactions"
-lang: "en"
+title: "Transacciones"
+lang: "es"
permalink: "technology/chain/transactions"
-whatsnext: { "Blocks": "/technology/chain/blocks/" }
+whatsnext: { "Bloques": "/es/technology/chain/blocks/" }
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
import TransactionBatching from "../_images/batching.png"
-A transaction is a cryptographically signed message that initiates a state transition to the chain state. It can be a simple balance transfer or invoking a smart contract, which in turn executes a program to alter the state.
+Una transacción es un mensaje firmado criptográficamente que inicia una transición de estado al estado de la cadena. Puede ser una simple transferencia de saldo o la llamada a un smart contract, que a su vez ejecuta un programa para alterar el estado.
-## Transaction Type
+## Tipo de Transacción
-Currently, Scroll supports three types of transactions.
+Actualmente, Scroll admite tres tipos de transacciones.
-- Pre-EIP-155 Transaction: This is to support the [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) contract.
-- Legacy Transaction (refer to [EIP-155](https://eips.ethereum.org/EIPS/eip-155))
-- `L1MessageTx` Typed Transaction (Type: `0x7E`): This is a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction introduced in Scroll as described below. This transaction type is for transactions initiated on L1.
+- Transacción Pre-EIP-155: Soporta el contrato [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470).
+- Transacción Legacy (consulte [EIP-155](https://eips.ethereum.org/EIPS/eip-155))
+- Transacción tipo `L1MessageTx` (Tipo: `0x7E`): Se trata de una nueva transacción [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) introducida en Scroll como se describe a continuación. Este tipo de transacción es para transacciones iniciadas en L1.
-Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) transaction type are not supported in Scroll currently. Scroll will bring back these two transaction types in the future.
+Tenga en cuenta que los tipos de transacción [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) y [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) no están soportados actualmente en Scroll. Scroll incorporará estos dos tipos de transacción en el futuro.
-### L1 Message Transaction
+### Transacción de Mensajes en L1
-We introduce a new type of transactions `L1MessageTx` for L1 initiated transactions. This type of transaction is initiated on the L1 bridge contract. Every time a new message is appended to the `L1MessageQueue` contract on L1, the L2 sequeuncer will create a corresponding `L1MessageTx` transaction to be included in the L2 blocks. Because the signature was already implicitly verified when users submitted the transaction on L1, `L1MessageTx` transactions don't have signature.
+Introducimos un nuevo tipo de transacciones `L1MessageTx` para transacciones iniciadas por L1. Este tipo de transacción se inicia en el contrato bridge de L1. Cada vez que se añade un nuevo mensaje al contrato `L1MessageQueue` en L1, el secuenciador L2 creará una transacción `L1MessageTx` correspondiente que se incluirá en los bloques L2. Dado que la firma ya se verificó implícitamente cuando los usuarios enviaron la transacción en L1, las transacciones `L1MessageTx` no tienen firma.
-The `L1MessageTx` transaction type is `0x7E` and its payload is defined as follows.
+El tipo de transacción `L1MessageTx` es `0x7E` y su payload se define como se muestra a continuación.
```go
type L1MessageTx struct {
@@ -39,53 +39,53 @@ type L1MessageTx struct {
}
```
-The RLP encoding of `L1MessageTx` transactions follows the [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) rule `TransactionType || TransactionPayload`, where `TransactionType` is `0x7E` and `TransactionPayload = RLP(L1MessageTx)`.
+La codificación RLP de las transacciones `L1MessageTx` sigue la regla [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) `TransactionType || TransactionPayload`, donde `TransactionType` es `0x7E` y `TransactionPayload = RLP(L1MessageTx)`.
-Two noticeable behaviors of the `L1MessageTx` transactions:
+Dos comportamientos notables de las transacciones `L1MessageTx`:
-- The `QueueIndex` in the transaction is the queue index in the L1 message queue, different from the `Nonce` of the `Sender` account. But the sender's `Nonce` will still increases by 1 after the transaction.
-- This type of transactions doesn't pay [L2 fee](/developers/transaction-fees-on-scroll#l2-fee) or [L1 fee](/developers/transaction-fees-on-scroll#l1-fee). The L2 fee is already paid when users submit transactions on L1. The L1 Fee isn't charged because the data of `L1MessageTx` transactions is already available in the L1 bridge contract.
+- El `QueueIndex` de la transacción es el índice de la cola de mensajes en L1, distinto del `Nonce` de la cuenta `Sender`. Pero el `Nonce` del remitente seguirá aumentando en 1 después de la transacción.
+- Este tipo de transacciones no paga [Comisión en L2](/es/developers/transaction-fees-on-scroll#l2-fee) o [Comisión en L1](/es/developers/transaction-fees-on-scroll#l1-fee). La comisión L2 ya se paga cuando los usuarios envían transacciones en L1. La comisión L1 no se cobra porque los datos de las transacciones `L1MessageTx` ya están disponibles en el contrato bridge de L1.
-## Transaction Life Cycle
+## Ciclo de Vida de las Transacciones
-The transaction life cycle in the Scroll contains the following three phases:
+El ciclo de vida de la transacción en Scroll contiene las tres fases:
-1. **Confirmed**: Users submits a transaction to either the L1 bridge contract or L2 sequencer. The transaction becomes `Confirmed` after it gets executed and included in a L2 block.
-2. **Committed**: The transactions are included in a batch and a _commit transaction_ that contains the data of this batch is submitted to L1. After the commit transaction is finalized in the L1 blocks, the transactions in this batch becomes `Committed`.
-3. **Finalized**: The validity proof of this batch is generated and verified on the L1. After the _finalize transaction_ is finalized on L1, the status of the transaction is `Finalized` and becomes a canonical part of the Scroll L2 chain.
+1. **Confirmed**: El usuario envía una transacción al contrato bridge en L1 o al secuenciador en L2. La transacción se convierte en `Confirmed` después de ser ejecutada e incluida en un bloque en L2.
+2. **Committed**: Las transacciones se incluyen en un lote y se envía a L1 una _commit transaction_ que contiene los datos de este lote. Después de que la commit transaction se finaliza en los bloques L1, las transacciones de este lote se convierten en `Committed`.
+3. **Finalized**: La prueba de validez de este lote se genera y verifica en el L1. Después de que la _finalize transaction_ se termina en el L1, el estado de la transacción es `Finalized` y se convierte en una parte canónica de la Scroll L2 chain.
-### Submit Transactions
+### Envío de transacciones
-There are two entry points where users can submit transactions to Scroll.
+Hay dos puntos de entrada en los que los usuarios pueden enviar transacciones a Scroll.
-First, users can directly submit transactions to L2 sequencers. To do so, users just need to configure their wallets and connect to the Scroll RPC endpoint. The sequencer validates the transaction and stores it in its local transaction pool.
+En primer lugar, los usuarios pueden enviar transacciones directamente al secuenciador en L2. Para ello, los usuarios sólo tienen que configurar sus wallets y conectarse al endpoint RPC de Scroll. El secuenciador valida la transacción y la almacena en su fondo de transacciones local.
-Second, deposit and enforced transactions are originated on L1. Scroll L1 bridge contract provides three entry points for users and smart contracts to send transactions from the L1. All messages sent through these three entry points will be appended to the `L1MessageQueue` contract.
+En segundo lugar, las transacciones de depósito y ejecución originadas en L1. El contrato bridge de Scroll L1 proporciona tres puntos de entrada para que los usuarios y los smart contracts envíen transacciones desde el L1. Todos los mensajes enviados a través de estos tres puntos de entrada se añadirán al contrato `L1MessageQueue`.
-- The `ScrollGatewayRouter` contract and several standard token gateways allow users and contracts to deposit standard tokens to L2. See more details in the [Deposit Token Gateways](/-oscADc8SoKAOxjtpcEqKg).
-- The `L1ScrollMessenger` contract allows users and contracts to send arbitrary messages to L2. See more details in the [Sending Arbitrary Messages](/UPyw7afFQE6q-9CIdIRBag#Sending-Arbitrary-Messages).
-- The `EnforcedTxGateway` contract allows EOAs to initiate an enforced transaction from the same address to withdraw tokens or call other contracts on L2. See more details in the [Sending Enforced Transaction](/UPyw7afFQE6q-9CIdIRBag#Sending-Enforced-Transactions).
+- El contrato `ScrollGatewayRouter` y varias gateways de tokens estándares permiten a los usuarios y contratos depositar tokens estándares en la L2. Ver más detalles en [Gateways de Depósito](/es/technology/bridge/deposit-gateways).
+- El contrato `L1ScrollMessenger` permite a los usuarios y contratos enviar mensajes arbitrarios a L2. Ver más detalles en [Envío de Mensajes Arbitrarios](/es/technology/bridge/cross-domain-messaging#envío-de-mensajes-arbitrarios).
+- El contrato `EnforcedTxGateway` permite a los EOA iniciar una transacción forzada desde la misma dirección para retirar tokens o llamar a otros contratos en L2. Ver más detalles en [Envío de Transacciones Forzadas](/es/technology/bridge/cross-domain-messaging#envío-de-transacciones-forzadas).
-The Scroll sequencer periodically starts a new mining job. It pulls the L1 messages from the `L1MessageQueue` contract and transactions in the L2 mempool and seals a block. Once a transaction is included in a L2 block, its status becomes `Confirmed`.
+El secuenciador de Scroll inicia periódicamente un nuevo trabajo de minería. Extrae los mensajes L1 del contrato `L1MessageQueue` y las transacciones en el mempool de L2 y sella un bloque. Una vez que una transacción se incluye en un bloque L2, su estado pasa a ser `Confirmed`.
-### Commit Transaction Data
+### Compilación de datos de transacciones
-The rollup node collects new L2 blocks and packs them into chunks and batches (see more details in [Transaction Batching](/RxRWLFtiQ7W_wbc0jMnQNA)). Periodically it sends a _Commit Transaction_ that posts the data of a batch of transactions to the L1 `ScrollChain` contract. After the Commit Transaction is finalized in a L1 block, the status of the transactions in this batch becomes `Committed`. At this time, users can reconstruct L2 state themselves completely based on the committed data from the L1 contract.
+El nodo de rollup recopila nuevos bloques L2 y los empaqueta en trozos y lotes (ver más detalles en [Lotes de Transacciones](/es/technology/chain/transactions#lotes-de-transacciones)). Periódicamente envía una _Commit Transaction_ que publica los datos de un lote de transacciones en el contrato L1 `ScrollChain`. Una vez finalizada la commit transaction en un bloque L1, el estado de las transacciones de este lote pasa a ser `Committed`. En este momento, los usuarios pueden reconstruir por sí mismos el estado L2 completamente basándose en los datos consignados del contrato L1.
-### Finalize Transactions
+### Finalizar transacciones
-After the validity proof is generated, the rollup node sends a _Finalize Transaction_ including the validity proof and the new state root after this batch for onchain verification. Once the Finalize Transaction succeeds and confirmed in a L1 block, the status of the L2 transactions in this batch becomes `Finalized`. The new state root can be used by third parties trustlessly.
+Una vez generada la prueba de validez, el rollup node envía una _Finalize Transaction_ que incluye la prueba de validez y el nuevo state root después de este lote para su verificación onchain. Una vez que la transacción finalizada se confirma en un bloque de L1, el estado de las transacciones L2 de este lote pasa a ser `Finalized`. La nueva state root puede ser utilizada por terceros con total confianza.
-## Transaction Batching
+## Lotes de Transacciones
-In Scroll, the transactions are batched in multiple tiers.
+En Scroll, las transacciones se agrupan en varios niveles.
-1. A group of ordered transactions are packed into a block.
-2. A series of contiguous blocks are grouped into a chunk. The chunk is the base unit for proof generation of the zkEVM circuit.
-3. A series of contiguous chunks are grouped into a batch. The batch is the base unit for data commitment and proof verification on the L1. The proof for a batch, or a _batch proof_, is an aggregated proof of the chunk proofs in this batch.
+1. Un grupo de transacciones ordenadas se empaquetan en un bloque.
+2. Una serie de bloques contiguos se agrupan en un chunk. El chunk es la unidad base para la generación de pruebas del circuito zkEVM.
+3. Una serie de bloques contiguos se agrupan en un lote. El lote es la unidad base para el compromiso de datos y la verificación de pruebas en la L1. La prueba de un lote, o _batch proof_, es una prueba agregada de las pruebas de los chunks de este lote.
-The goal for this multi-layer batching schema is to reduce the gas cost of onchain data commitment and proof verification. This approach increases the granularity of the rollup units on L1 while takes the fixed circuit capacity into consideration. As a result, batching reduces the data to be stored in the contract and amortizes the proof verification cost to more L2 transactions.
+El objetivo de este esquema de lotes multi-layer es reducir el coste de gas del compromiso de datos onchain y la verificación de pruebas. Este enfoque aumenta la granularidad de las unidades de rollup en L1 al tiempo que tiene en cuenta la capacidad del circuito fijo. Como resultado, la división en lotes reduce los datos que deben almacenarse en el contrato y amortiza el coste de verificación de la prueba a más transacciones L2.
-Once a chunk is created, a corresponding chunk proving task will be generated and sent to a zkEVM prover. Upon the creation of a new batch, two subsequent actions occur: (a) the rollup node commits the transaction data and block information from this batch to the L1 contract, and (b) a batch proving task to aggregate chunk proofs is dispatched to an aggregator prover. The standards for proposing a chunk and a batch are detailed in the [Rollup Node](/technology/sequencer/rollup-node).
+Una vez creado un chunk, se generará una tarea de comprobación de chunk correspondiente y se enviará a un prover de zkEVM. Tras la creación de un nuevo lote, se producen dos acciones posteriores: (a) el nodo de rollup consigna los datos de transacción y la información de bloque de este lote al contrato L1, y (b) se envía una proving task para agregar pruebas de los chunks a un prover agregador. Las normas para proponer un chunk y un batch se detallan en [Rollup Node](/es/technology/sequencer/rollup-node).
diff --git a/src/content/docs/es/technology/index.mdx b/src/content/docs/es/technology/index.mdx
index 927303aa8..8999ead69 100644
--- a/src/content/docs/es/technology/index.mdx
+++ b/src/content/docs/es/technology/index.mdx
@@ -1,11 +1,11 @@
---
section: technology
date: Last Modified
-title: "Scroll Architecture"
-lang: "en"
+title: "Arquitectura de Scroll"
+lang: "es"
permalink: "technology"
whatsnext:
- { "Scroll Chain": "/technology/chain/accounts", "Bridge": "/technology/bridge/cross-domain-messaging", "Sequencer": "/technology/sequencer/execution-node", "zkEVM": "/technology/zkevm/zkevm-overview" }
+ { "Scroll Chain": "/es/technology/chain/accounts", "Bridge": "/es/technology/bridge/cross-domain-messaging", "Secuenciador": "/es/technology/sequencer/execution-node", "zkEVM": "/es/technology/zkevm/zkevm-overview" }
---
import ClickToZoom from "../../../../components/ClickToZoom.astro"
@@ -13,12 +13,12 @@ import Architecture from "./_images/arch.png"
-As illustrated in the figure above, Scroll chain consists of three layers:
+Como se ilustra en la figura anterior, la Scroll chain consta de tres capas:
-- **Settlement Layer**: provides data availability and ordering for the canonical Scroll chain, verifies validity proofs, and allows users and dapps to send messages and assets between Ethereum and Scroll. We use Ethereum as the Settlement Layer and deploy the bridge and rollup contract onto the Ethereum.
-- **Sequencing Layer**: contains a *Execution Node* that executes the transactions submitted to the Scroll sequencer and the transactions submitted to the L1 bridge contract and produces L2 blocks, and a *Rollup Node* that batches transactions, posts transaction data and block information to Ethereum for data availability, and submits validity proofs to Ethereum for finality.
-- **Proving Layer**: consists of a pool of provers that are responsible for generating the zkEVM validity proofs that verify the correctness of L2 transactions, and a coordinator that dispatches the proving tasks to provers and relays the proofs to the Rollup Node to finalize on the Ethereum.
+- **Settlement Layer**: proporciona disponibilidad de datos y ordenación para la Scroll chain canónica, verifica las pruebas de validez, y permite a los usuarios y dapps enviar mensajes y activos entre Ethereum y Scroll. Utilizamos Ethereum como Settlement Layer y desplegamos el bridge y el rollup contract en Ethereum.
+- **Sequencing Layer**: contiene un *Execution Node* que ejecuta las transacciones enviadas al secuenciador de Scroll y las transacciones enviadas al bridge contract en L1 y produce bloques L2, y un *Rollup Node* que agrupa transacciones, publica datos de transacciones e información de bloques en Ethereum para la disponibilidad de datos, y envía pruebas de validez a Ethereum para la finalización.
+- **Proving Layer**: consiste en un grupo de probadores que son responsables de generar las pruebas de validez zkEVM que verifican la corrección de las transacciones L2, y un coordinador que envía las tareas de prueba a los probadores y retransmite las pruebas al Rollup Node para finalizarlas en Ethereum.
-This section of the documentation provides comprehensive information on the Scroll protocol specification, bridging protocol, sequencer, and zkEVM circuit.
+Esta sección de la documentación proporciona información exhaustiva sobre la especificación del protocolo Scroll, el protocolo bridging, el secuenciador y el circuito zkEVM.
-*In the remainder of this section, L1 will refer to Ethereum, while L2 will refer to Scroll.*
+*En el resto de esta sección, L1 se referirá a Ethereum, mientras que L2 se referirá a Scroll.*
diff --git a/src/content/docs/es/technology/sequencer/execution-node.mdx b/src/content/docs/es/technology/sequencer/execution-node.mdx
index b51fd0476..ea9ab4e59 100644
--- a/src/content/docs/es/technology/sequencer/execution-node.mdx
+++ b/src/content/docs/es/technology/sequencer/execution-node.mdx
@@ -1,83 +1,83 @@
---
section: technology
date: Last Modified
-title: "Execution Node"
-lang: "en"
+title: "Nodo de Ejecución"
+lang: "es"
permalink: "technology/sequencer/execution-node"
-whatsnext: { "Rollup Node": "/technology/sequencer/rollup-node/" }
+whatsnext: { "Nodo Rollup": "/es/technology/sequencer/rollup-node/" }
---
import Aside from "../../../../../components/Aside.astro"
-The execution node is one of the core components in the Scroll protocol: it is responsible for maintaining the L2 blockchain. The execution node also ensures that the user and developer experience on Scroll closely resemble those on Ethereum. It achieves this by maintaining EVM and RPC behaviour that is directly inherited from Ethereum, with very few modifications.
+El nodo de ejecución es uno de los componentes centrales del protocolo Scroll: se encarga de mantener la blockchain L2. El nodo de ejecución también garantiza que la experiencia del usuario y del desarrollador en Scroll se parezca mucho a la de Ethereum. Para ello, mantiene el comportamiento EVM y RPC heredado directamente de Ethereum, con muy pocas modificaciones.
-The primary functions of Scroll's execution node are:
-- Collect transactions from L2 and L1.
-- Validate transactions and pack them into L2 blocks.
-- Execute blocks and maintain the L2 blockchain state.
+Las funciones principales del nodo de ejecución de Scroll son:
+- Recoger transacciones de L2 y L1.
+- Validar transacciones y agruparlas en bloques L2.
+- Ejecutar bloques y mantener el estado del blockchain L2.
-It is worth highlighting that bridging messages and tokens from L1 to L2 (deposits) is also the execution node's responsibility. Messages from L2 to L1 (withdraws), on the other hand, can be executed by any user on L1.
+Cabe destacar que la transmisión de mensajes y tokens de L1 a L2 (depósitos) también es responsabilidad del nodo de ejecución. Los mensajes de L2 a L1 (retiros), por otro lado, pueden ser ejecutados por cualquier usuario en L1.
-The secondary functions of Scroll's execution node are:
-- Offer standard Ethereum RPC APIs and some Scroll extension APIs.
-- Allow peers (follower nodes) to sync the blockchain using Ethereum's peer-to-peer protocol.
+Las funciones secundarias del nodo de ejecución de Scroll son:
+- Ofrecer APIs RPC estándar de Ethereum y algunas APIs de extensión de Scroll.
+- Permitir a los peers (nodos seguidores) sincronizar la blockchain utilizando el protocolo peer-to-peer de Ethereum.
-The execution node, being a fork of [go-ethereum](https://github.com/ethereum/go-ethereum), inherits most of its functionality from Ethereum. This includes transaction and block data structures, EVM execution, RPC and p2p protocols. As these were not reimplemented but were directly inherited from `go-ethereum`, we can have a very high certainty of Scroll's compatibility with Ethereum.
+El nodo de ejecución, al ser un fork de [go-ethereum](https://github.com/ethereum/go-ethereum), hereda la mayor parte de su funcionalidad de Ethereum. Esto incluye estructuras de datos de transacciones y bloques, ejecución EVM, RPC y protocolos p2p. Como estos no fueron reimplementados sino que fueron heredados directamente de `go-ethereum`, podemos tener una certeza muy alta de la compatibilidad de Scroll con Ethereum.
-The following sections will introduce the main components of the execution node, the additional validation rules, and summary of modification details.
+Las siguientes secciones presentarán los principales componentes del nodo de ejecución, las reglas de validación adicionales y un resumen de los detalles de la modificación.
-## `l2geth` Components
+## Componentes de `l2geth`
-[`l2geth`](https://github.com/scroll-tech/go-ethereum) is Scroll's fork of [go-ethereum](https://github.com/ethereum/go-ethereum). It is responsible for building and executing blocks and maintaining the blockchain state. `l2geth` inherits most of its functionality from Ethereum, with some notable differences listed below. `l2geth` has the following submodules (not exhaustive list):
-- **Storage**: Ledger and state storage implemented using LevelDB.
-- **EVM**: The state transition rules of Ethereum.
-- **Worker:** Responsible for creating new L2 blocks.
-- **L1 SyncService**: Sync and store L1 messages in `l2geth` local database.
-- **API layer**: Standard Ethereum RPC and p2p interfaces.
-- **Transaction pool**: Mempool for L2 transactions.
-- **Circuit capacity checker**: checks if a transaction or a block exceeds the circuit capacity limit.
+[`l2geth`](https://github.com/scroll-tech/go-ethereum) es un fork de Scroll de [go-ethereum](https://github.com/ethereum/go-ethereum). Es responsable de construir y ejecutar bloques y de mantener el estado de la cadena de bloques. `l2geth` hereda la mayor parte de su funcionalidad de Ethereum, con algunas diferencias notables que se enumeran a continuación. `l2geth` tiene los siguientes submódulos (lista no exhaustiva):
+- **Storage**: Ledger y almacenamiento de estado implementado usando LevelDB.
+- **EVM**: Las reglas de transición de estado de Ethereum.
+- **Worker:** Responsable de la creación de nuevos bloques L2.
+- **L1 SyncService**: Sincroniza y almacena mensajes L1 en la base de datos local `l2geth`.
+- **API Layer**: Interfaces estándar RPC y p2p de Ethereum.
+- **Transaction pool**: Mempool para transacciones L2.
+- **Circuit capacity checker**: comprueba si una transacción o un bloque excede el límite de capacidad del circuito.
-### Circuit Capacity Checker
+### Comprobador de capacidad del circuito
-With Scroll's current zkEVM circuits, it is possible to construct transactions and blocks that cannot be proven because they do not fit into the zkEVM circuit. We call this *proof overflow*. To avoid this, we implemented a *circuit capacity checker* module as part of l2geth. The circuit capacity checker is used both during block creation and block validation.
+Con los circuitos zkEVM actuales de Scroll, es posible construir transacciones y bloques que no se pueden probar porque no caben en el circuito zkEVM. A esto lo llamamos *proof overflow*. Para evitarlo, implementamos un módulo *circuit capacity checker* como parte de l2geth. El comprobador de capacidad del circuito se utiliza tanto durante la creación como durante la validación de bloques.
-During block creation, if the next transaction would lead to proof overflow, then we seal the block and leave the transaction for the next block. If a single transaction leads to proof overflow, l2geth discards it. We call this mechanism *skipping*.
+Durante la creación del bloque, si la siguiente transacción podría provocar una proof overflow, sellamos el bloque y dejamos la transacción para el siguiente bloque. Si una transacción conduce a una proof overflow, l2geth la descarta. A este mecanismo lo denominamos *skipping*.
-Skipping L2 transactions means simply discarding them. In this case, the user needs to submit another transaction with the same nonce that does not lead to proof overflow in order to proceed.
+Omitir transacciones L2 significa simplemente descartarlas. En este caso, el usuario debe enviar otra transacción con el mismo nonce que no provoque una proof overflow para poder continuar.
-Skipping L1 messages is a more explicit process. Both the `ScrollChain` contract on L1 and the zkEVM verifies that each L1 transaction in `L1MessageQueue` was either included and executed, or skipped. While the batch encoding does not contain L1 transactions, it does include a *skip bitmap* that indicates to `ScrollChain` which L1 messages were skipped. If an L1 deposit message is skipped, the user can get their tokens refunded on L1.
+Omitir mensajes L1 es un proceso más explícito. Tanto el contrato `ScrollChain` en L1 como el zkEVM verifican que cada transacción L1 en `L1MessageQueue` se incluyó y ejecutó, o se omitió. Aunque la codificación por lotes no contiene transacciones L1, sí incluye un *skip bitmap* que indica a `ScrollChain` qué mensajes L1 se han omitido. Si se omite un mensaje de depósito L1, el usuario puede obtener la devolución de sus tokens en L1.
-
+
{" "}
- Proof overflow and thus skipping suggests malicious activity; for normal deposit transactions, this will never happen.
+ Una Proof overflow y la omisión sugiere actividad maliciosa; para las transacciones de depósito normales, esto nunca ocurrirá.
{" "}
-As the unit of zkEVM proving is the chunk, proof overflow must be avoided for chunks as well.
-This is achieved by incorporating the circuit capacity checker into the rollup-relayer to make sure that it never proposes unprovable chunks.
+Como la unidad de prueba de zkEVM es el chunk, el proof overflow debe evitarse también para los chunks.
+Esto se consigue incorporando el verificador de la capacidad del circuito en el rollup-relayer para asegurarse de que nunca propone chunks no comprobables.
-## Validation Rules
+## Reglas de Validación
-Scroll adds a few validation rules in addition to Ethereum's block validation rules. These new rules constrain the L2 behavior of L1 message inclusion and zkEVM circuit capacity limit.
-- The [circuit capacity checker](#circuit-capacity-checker) module outlined above
- verifies the block can fit into the circuit space capacity of the zkEVM circuit.
-- Rules related to L1 messages:
- - L1 messages in a block must be contiguous and at the front of the block.
- - L1 messages in a block must be included following their order in `L1MessageQueue`, i.e., they must be included with increasing `QueueIndex`.
- - L1 messages in a block must match those in the `L1MessageQueue` contract.
-- Most of these rules are considered both during block creation and block validation. As a result, if the block proposer node violates any of these rules, follower nodes will reject its blocks.
+Scroll añade algunas reglas de validación además de las reglas de validación de bloques de Ethereum. Estas nuevas reglas restringen el comportamiento L2 de la inclusión de mensajes L1 y el límite de capacidad del circuito zkEVM.
+- El módulo [Comprobador de capacidad del circuito](/es/technology/sequencer/execution-node/#comprobador-de-capacidad-del-circuito) descrito anteriormente
+verifica que el bloque puede encajar en la capacidad del espacio del circuito zkEVM.
+- Reglas relacionadas con los mensajes L1:
+ - Los mensajes L1 de un bloque deben ser contiguos y estar al principio del bloque.
+ - Los mensajes L1 de un bloque deben incluirse siguiendo su orden en `L1MessageQueue`, es decir, deben incluirse con `QueueIndex` creciente.
+ - Los mensajes L1 de un bloque deben coincidir con los del contrato `L1MessageQueue`.
+- La mayoría de estas reglas se tienen en cuenta tanto durante la creación del bloque como durante su validación. Como resultado, si el nodo proponente del bloque viola alguna de estas reglas, los nodos seguidores rechazarán sus bloques.
-## Summary of Modifications
+## Resumen de las Modificaciones
-The Scroll execution node inherits most of Ethereum's behaviours. However, we needed to make some breaking changes to `l2geth` to enable more efficient proving. This section provides a non-exhaustive list of the modifications, along with their rationale.
+El nodo de ejecución Scroll hereda la mayoría de los comportamientos de Ethereum. Sin embargo, hemos tenido que realizar algunos cambios de última hora en `l2geth` para permitir una prueba más eficiente. Esta sección proporciona una lista no exhaustiva de las modificaciones, junto con su justificación.
-- **State and storage tree**: Ethereum uses the MPT (Merkle-Partricia Trie) as its state and contract storage data structure. This trie's structure and the fact that it uses Keccak hash would make it prohibitively expensive for ZK circuits. `l2geth` instead uses [zkTrie](/technology/sequencer/zktrie): a binary Merkle trie with Poseidon hash for its state and contract storage.
-- **StateAccount**: The modification of state account is described in the [Accounts and State](/technology/chain/accounts).
-- **EVM**: The modifications are described in the [EVM Differences from Ethereum](/technology/chain/differences)
-- **Transaction fees**
- - All fees collected on L2 are sent to a Scroll-maintained L2 fee vault contract.
- - L1 fee: In addition to the L2 gas fee that covers L2 block space and execution costs, we also collect an L1 fee that covers the costs of committing the transaction to L1. This fee is proportional to the size of the RLP-encoded transaction. The actual cost depends on the current settings stored in the `L1GasOracle` contract on L2. This fee is deducted from the sender balance directly (and not from the gas allowance).
-- **L1MessageTx**: We introduced a new transaction type `L1MessageTx`. We also added DB interfaces for storing such transactions and related metadata.
-- **SyncService**: monitors finalized blocks on L1 and collects L1 messages from these.
-- **New API**: The `l2geth` offers a trace API `scroll_traceBlockByNumberOrHash` for provers to query the trace information to generate proofs.
+- **State and storage tree**: Ethereum utiliza el MPT (Merkle-Partricia Trie) como estructura de datos de almacenamiento de estados y contratos. La estructura de este trie y el hecho de que utilice hash Keccak lo harían prohibitivamente caro para los circuitos ZK. En su lugar, `l2geth` utiliza [zkTrie](/es/technology/sequencer/zktrie): un trie Merkle binario con Poseidon hash para su almacenamiento de estados y contratos.
+- **StateAccount**: La modificación de la cuenta de estado se describe en [Cuentas y Estado](/technology/chain/accounts).
+- **EVM**: Las modificaciones se describen en las [Diferencias de EVM respecto a Ethereum](/es/technology/chain/differences).
+- **Comisiones de transacción**
+ - Todas las comisiones recaudadas en L2 se envían a un contrato vault de comisiones en L2 mantenido por Scroll.
+ - Comisión L1: Además de la tasa de gas L2 que cubre el espacio de bloque L2 y los costes de ejecución, también cobramos una tasa L1 que cubre los costes de comprometer la transacción en L1. Esta tasa es proporcional al tamaño de la transacción codificada en RLP. El coste real depende de la configuración actual almacenada en el contrato `L1GasOracle` en L2. Esta tarifa se deduce directamente del saldo del remitente (y no de la asignación de gas).
+- **L1MessageTx**: Hemos introducido un nuevo tipo de transacción `L1MessageTx`. También hemos añadido interfaces de base de datos para almacenar dichas transacciones y los metadatos relacionados.
+- **SyncService**: supervisa los bloques finalizados en L1 y recoge los mensajes L1 de los mismos.
+- **Nueva API**: El `l2geth` ofrece una API de rastreo `scroll_traceBlockByNumberOrHash` para que los provers puedan consultar la información de rastreo para generar pruebas.
diff --git a/src/content/docs/es/technology/sequencer/rollup-node.mdx b/src/content/docs/es/technology/sequencer/rollup-node.mdx
index 69cb065b6..7f967e8c4 100644
--- a/src/content/docs/es/technology/sequencer/rollup-node.mdx
+++ b/src/content/docs/es/technology/sequencer/rollup-node.mdx
@@ -1,33 +1,33 @@
---
section: technology
date: Last Modified
-title: "Rollup Node"
-lang: "en"
+title: "Nodo Rollup"
+lang: "es"
permalink: "technology/sequencer/rollup-node"
-whatsnext: { "zkTrie": "/technology/sequencer/zktrie/" }
+whatsnext: { "zkTrie": "/es/technology/sequencer/zktrie/" }
---
-The rollup node is responsible for splitting up the Scroll blockchain into sections that are suitable for proving and commitment on L1. The two main units of this are *chunks* and *batches*.
-* A chunk is simply a contiguous section of the L2 ledger, it is a collection of L2 blocks, and chunks are the unit of zkEVM proving.
-* A batch, on the other hand, is a collection of chunks that are submitted to L1, along with an aggregate proof.
+El nodo de rollup es responsable de dividir el blockchain de Scroll en secciones que sean adecuadas para el proving y commitment en L1. Las dos unidades principales son los *chunks* y los *batches*.
+* Un chunk es simplemente una sección contigua del ledger L2, es una colección de bloques L2, y los chunks son la unidad de prueba de zkEVM.
+* Por otro lado, un batch (o lote) es una colección de chunks que se envían a L1, junto con una prueba agregada.
-The rollup node has the following submodules:
-- Chunk Proposer: collects L2 blocks and proposes chunks while enforcing certain limits (see below).
-- Batch Proposer: collect chunks and propose batches while enforcing certain limits (see below).
-- Relayer: submits batch data and batch proofs to L1.
+El nodo rollup tiene los siguientes submódulos:
+- Chunk Proposer: recopila bloques L2 y propone chunks aplicando ciertos límites (véase más adelante).
+- Batch Proposer: recopila bloques y propone lotes aplicando ciertos límites (véase más adelante).
+- Relayer: envía datos de lotes y pruebas de lotes a L1.
-## Chunk and batch constraints
+## Restricciones de chunks y batches
-Compared to the execution node, the rollup node is a much more straightforward and simple component.
-It collects L2 blocks, creates chunks and batches, and submits these to L1.
-In this section we outline the main limits that the rollup node must enforce during chunk and batch creation.
+Comparado con el nodo de ejecución, el nodo de rollup es un componente mucho más directo y sencillo.
+Recoge bloques L2, crea chunks, batches y los envía a L1.
+En esta sección se describen los principales límites que debe cumplir el nodo de rollup durante la creación de "chunks" y "batches".
-Constraints on chunks:
-- **No proof overflow:** Using the circuit capacity checker, we make sure to include as many blocks in a chunk that it would still not lead to proof overflow.
-- **L1 payload**: Inherited constraints from batch proposer, transaction payload cannot exceed 128KB.
+Restricciones sobre los chunks:
+- **No proof overflow:** Utilizando el comprobador de capacidad de circuitos, nos aseguramos de incluir tantos bloques en un chunk como sea posible para que no se produzca un proof overflow.
+- **L1 payload:** Restricciones heredadas del batch proposer, el payload de la transacción no puede exceder los 128KB.
-Constraints on batches:
-- **L1 payload:** Ethereum has a hardcoded 128KB limit on transaction payload size.
-- **L1 commit gas:** The gas cost of committing a batch is proportional to the number of blocks and transactions in it. We must make sure that this cost does not exceed the L1 block gas limit.
-- **Number of chunks:** A batch includes a number of chunks that is optimal for the aggregation prover.
+Restricciones en los lotes:
+- **L1 payload:** Ethereum tiene un límite de 128 KB en el tamaño del payload de la transacción.
+- **L1 commit gas:** El coste de gas de confirmar un lote es proporcional al número de bloques y transacciones que contiene. Debemos asegurarnos de que este coste no excede el límite de gas de bloque L1.
+- **Número de chunks:** Un lote incluye un número de chunks que es óptimo para el prover de agregación.
diff --git a/src/content/docs/es/technology/sequencer/zktrie.mdx b/src/content/docs/es/technology/sequencer/zktrie.mdx
index b9d592b6a..0e80bb05c 100644
--- a/src/content/docs/es/technology/sequencer/zktrie.mdx
+++ b/src/content/docs/es/technology/sequencer/zktrie.mdx
@@ -2,10 +2,10 @@
section: technology
date: Last Modified
title: "zkTrie"
-lang: "en"
+lang: "es"
permalink: "technology/sequencer/zktrie"
-whatsnext: { "zkEVM": "/technology/zkevm/intro-to-zkevm/" }
-excerpt: "zkTrie is a sparse binary Merkle Patricia Trie built using Poseidon hash."
+whatsnext: { "zkEVM": "/es/technology/zkevm/intro-to-zkevm/" }
+excerpt: "zkTrie es un Merkle Patricia Trie binario disperso construido usando Poseidon hash."
---
import Aside from "../../../../../components/Aside.astro"
@@ -14,73 +14,73 @@ import zktrie1 from "../_images/zktrie-arch.png"
import zktrie2 from "../_images/zktrie-insertion.png"
import zktrie3 from "../_images/zktrie-deletion.png"
-This document describes zkTrie, a sparse binary Merkle Patricia Trie used to store key-value pairs efficiently. It explains the tree structure, construction, node hashing, and tree operations, including insertion and deletion.
+Este documento describe zkTrie, un Merkle Patricia Trie binario disperso utilizado para almacenar pares key-value de forma eficiente. Se explica la estructura del tree, la construcción, el hash de nodos y las operaciones del tree, incluyendo la inserción y la eliminación.
-You can also explore our [zktrie repo](https://github.com/scroll-tech/zktrie).
+También puedes explorar nuestro [zktrie repo](https://github.com/scroll-tech/zktrie).
-## Tree Structure
+## Estructura del Tree
-zkTrie is a sparse binary Merkle Patricia Trie, depicted in the above figure.
-Before diving into the Sparse Binary Merkle Patricia Trie, let's briefly touch on Merkle Trees and Patricia Tries.
-* **Merkle Tree**: A Merkle Tree is a tree where each leaf node represents a hash of a data block, and each non-leaf node represents the hash of its child nodes.
-* **Patricia Trie**: A Patricia Trie is a type of radix tree or compressed trie used to store key-value pairs efficiently. It encodes the nodes with same prefix of the key to share the common path, where the path is determined by the value of the node key.
+zkTrie es un Merkle Patricia Trie binario disperso, representado en la figura anterior.
+Antes de sumergirnos en el Merkle Patricia Trie binario disperso, hablemos brevemente de los Merkle Trees y los Patricia Tries.
+* **Merkle Tree**: Un Merkle Tree es un árbol donde cada nodo hoja representa un hash de un bloque de datos, y cada nodo no hoja representa el hash de sus nodos hijos.
+* **Patricia Trie**: Un Patricia Trie es un tipo de árbol radix o trie comprimido utilizado para almacenar pares key-value de forma eficiente. Codifica los nodos con el mismo prefijo de la key para compartir el camino común, donde el camino está determinado por el valor de la key del nodo.
-As illustrated in the Figure 1, there are three types of nodes in the zkTrie.
-- Branch Node: Given the zkTrie is a binary tree, a branch node has two children.
-- Leaf Node: A leaf node holds the data of a key-value pair.
-- Empty Node: An empty node is a special type of node, indicating the sub-trie that shares the same prefix is empty.
+Como se ilustra en la Figura 1, existen tres tipos de nodos en el zkTrie.
+- Branch Node: Dado que zkTrie es un sistema binario, un branch node dos hijos.
+- Leaf Node: Un leaf node contiene los datos de un par key-value.
+- Empty Node: Un empty node es un tipo especial de nodo, que indica que la sub-trie que comparte el mismo prefijo está vacía.
-In zkTrie, we use Poseidon hash to compute the node hash because it's more friendly and efficient to prove it in the zk circuit.
+En zkTrie, usamos Poseidon hash para calcular el hash de nodo porque es más amigable y eficiente probarlo en el circuito zk.
-## Tree Construction
+## Construcción del Tree
-Given a key-value pair, we first compute a *secure key* for the corresponding leaf node by hashing the original key (i.e., account address and storage key) using the Poseidon hash function. This can make the key uniformly distributed over the key space. The node key hashing method is described in the [Node Hashing](#node-hashing) section below.
+Dado un par key-value, primero calculamos una *key segura* para el "leaf node" correspondiente haciendo un hash de la key original (es decir, la dirección de la cuenta y la key de almacenamiento) usando la función hash Poseidon. Esto puede hacer que la key se distribuya uniformemente sobre el key space. El método hash de la key del nodo se describe en la sección [Node Hashing](#node-hashing) más abajo.
-We encode the path of a new leaf node by traversing the secure key from Least Significant Bit (LSB) to the Most Significant Bit (MSB). At each step, if the bit is 0, we will traverse to the left child; otherwise, traverse to the right child.
+Codificamos la ruta de un nuevo leaf node recorriendo la key segura desde el Least Significant Bit (LSB) hasta el Most Significant Bit (MSB). En cada paso, si el bit es 0, pasaremos al hijo izquierdo; en caso contrario, pasaremos al hijo derecho.
-We limit the maximum depth of zkTrie to 248, meaning that the tree will only traverse the lower 248 bits of the key. Because the secure key space is a finite field used by Poseidon hash that doesn't occupy the full range of $2^{256}$. the bit representation of the key can be ambiguous in the finite field and thus results in a soundness issue in the zk circuit. After we truncate the key to lower 248 bits, the key space can fully occupy the range of $2^{248}$ and won't have the ambiguity in the bit representation.
+Limitamos la profundidad máxima de zkTrie a 248, lo que significa que el tree sólo recorrerá los 248 bits inferiores de la key. Debido a que el espacio de key segura es un campo finito utilizado por Poseidon hash que no ocupa todo el rango de $2^{256}$. la representación de bits de la key puede ser ambigua en el campo finito y por lo tanto resulta en un problema de solidez en el circuito zk. Después de truncar la key a 248 bits inferiores, el espacio de la key puede ocupar completamente el rango de $2^{248}$ y no tendrá la ambigüedad en la representación de bits.
-We apply an optimization to reduce the tree depth by contracting a subtree that has only one leaf node to a single leaf node. For example, in the Figure 1, the tree has three nodes in total, with keys `0100`, `0010`, and `1010`. Because there is only one node that has key with suffix `00`, the leaf node for key `0100` only traverses the suffix `00` and doesn't fully expand its key which would have resulted in depth of 4.
+Aplicamos una optimización para reducir la profundidad del tree contrayendo un subtree que sólo tiene un leaf node para un single leaf node. Por ejemplo, en la Figura 1, el tree tiene tres nodos en total, con las claves `0100`, `0010` y `1010`. Como sólo hay un nodo que tenga la key con sufijo `00`, el leaf node de la key `0100` sólo atraviesa el sufijo `00` y no expande completamente su key, lo que hubiera resultado en una profundidad de 4.
-## Tree Operations
+## Operaciones del Tree
-### Insertion
+### Inserción
-When we insert a new leaf node to a zkTrie, there are two cases illustrated in the Figure 2.
+Cuando insertamos un nuevo leaf node en una zkTrie, se dan dos casos ilustrados en la Figura 2.
-1. When traversing the path of the node key, it reaches an empty node (Figure 2a). In this case, we just need to replace this empty node by this leaf node and backtrace the path to update the merkle hash of branch nodes till the root.
-2. When traversing the path of the node key, it reaches another leaf node `b` (Figure 2b). In this case, we need to push down the existing leaf node `b` until the next bit in the node keys of two leaf nodes differs. At each push-down step, we need to insert an empty sibling node to the branch node. When we reach the level where the bits differ, we then place two leaf nodes `b` and `d` as the left child and the right child depending on their bits. At last, we backtrace the path and update the Merkle hash of all branch nodes.
+1. Al recorrer la ruta del key node, se llega a un empty node (Figura 2a). En este caso, sólo tenemos que sustituir este empty node por este leaf node y retroceder en el camino para actualizar el merkle hash de los branch nodes hasta la root.
+2. Cuando se recorre el camino del key node, se llega a otro leaf node `b` (Figura 2b). En este caso, tenemos que empujar hacia abajo el leaf node existente `b` hasta que el siguiente bit en las keys de los nodos de dos leaf nodes difiera. En cada paso de empuje hacia abajo, tenemos que insertar un empty node hermano en el branch node. Cuando llegamos al nivel en el que los bits difieren, colocamos dos leaf nodes `b` y `d` como hijo izquierdo e hijo derecho en función de sus bits. Por último, volvemos a trazar el camino y actualizamos el hash Merkle de todos los branch nodes.
-### Deletion
+### Eliminación
-The deletion of a leaf node is similar to the insertion. There are two cases illustrated in the Figure 3.
+La eliminación de un leaf node es similar a la inserción. En la Figura 3 se ilustran dos casos.
-1. The sibling node of to-be-deleted leaf node is a
-branch node (Figure 3a). In this case, we can simply replace the node `a` by an empty node and update the node hash of its ancestors till the root node.
-2. The node of to-be-deleted leaf node is a leaf node (Figure 3b). Similarly to case 1, we first replace the leaf node by an empty node and start to contract its sibling node upwards until its sibling node is not an empty node. For example, in Figure 3b, we replace the leaf node `b` by an empty node. Because the sibling of node `c` now becomes an empty node, we need to move node `c` one level upward and replace its parent. The new sibling of node `c`, node `e`, is still an empty node. So again we move node `c` upward. Now that the sibling of node `c` is node `a`, a leaf node, the deletion process is finished.
+1. El nodo hermano del leaf node que se va a eliminar es un branch node (Figura 3a).
+En este caso, podemos simplemente reemplazar el nodo `a` por un empty node y actualizar el hash de sus ancestros hasta el root node.
+2. El leaf node a eliminar es un leaf node (Figura 3b). De forma similar al caso 1, primero sustituimos el leaf node por un empty node y empezamos a contraer su nodo hermano hacia arriba hasta que su nodo hermano no sea un empty node. Por ejemplo, en la figura 3b, sustituimos el leaf node `b` por un empty node. Como el hermano del nodo `c` se convierte ahora en un empty node, 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 empty node. Así que de nuevo movemos el nodo `c` hacia arriba. Ahora que el hermano del nodo `c` es el nodo `a`, un leaf node, el proceso de borrado ha terminado.
-Note that the sibling of a leaf node in a valid zkTrie cannot be an empty node. Otherwise, we should always prune the subtree and move the leaf node upwards.
+Ten en cuenta que el hermano de un leaf node en una zkTrie válida no puede ser un empty node. De lo contrario, siempre debemos purgar el subtree y mover el leaf node hacia arriba.
-## Node Hashing
+## Hash de Nodos
-In this section, we will describe how leaf secure key and node Merkle hash are computed. We use Poseidon hash with arity 2 for both hashing computation. In Scroll, the Poseidon hash function is configured to take two field element inputs each time and a `domain_value` as the initial context for domain separation, denoted as follows.
+En esta sección, describiremos cómo se calculan la key segura de hoja y el hash Merkle de nodo. Usamos Poseidon hash con arity 2 para ambos cálculos hash. En Scroll, la función hash Poseidon está configurada para tomar dos entradas de elementos de campo cada vez y un `domain_value` como contexto inicial para la separación de dominios, denotado como sigue.
```
h{domain_value}(input1, input2)
```
### Empty Node
-The node hash of an empty node is 0.
+El hash de un empty node es 0.
### Branch Node
-The branch node hash is computed as follows
+El hash del nodo de la rama se calcula del siguiente modo
```go
branchNodeHash = h{BranchNodeType}(leftChildHash, rightChildHash)
@@ -88,20 +88,20 @@ branchNodeHash = h{BranchNodeType}(leftChildHash, rightChildHash)
### Leaf Node
-The node hash of a leaf node is computed as follows.
+El hash de un leaf node se calcula de la siguiente manera.
```go
leafNodeHash = h{LeafNodeType}(nodeKey, valueHash)
```
-The computation involves two fields `nodeKey` and `valueHash`.
-- `nodeKey` is hashed from the original key. The domain value used in the Poseidon hash is 256.
-- `valueHash` is calculated by hashing the leaf node value. The domain value used in the Poseidon hash is `256 * n`, where `n` is the number of elements in the leaf node value.
+El cálculo implica dos campos `nodeKey` y `valueHash`.
+- El `nodeKey` es un hash de la key original. El valor del dominio usado en el hash de Poseidon es 256.
+- El `valueHash` se calcula a partir del hash del valor del leaf node. El valor de dominio usado en el hash de Poseidon es `256 * n`, donde `n` es el número de elementos en el valor del leaf node.
-There are two types of leaf nodes: Ethereum accounts and storage key-value pairs. Next, we will describe the calculation method of the node key and value hash for each leaf node type respectively.
+Hay dos tipos de leaf nodes: Cuentas Ethereum y pares key-value de almacenamiento. A continuación, vamos a describir el método de cálculo de la node key y el valor hash para cada tipo de leaf node, respectivamente.
-#### Ethereum Account Leaf Node
-For an Ethereum Account Leaf Node, it consists of an Ethereum address and a state account data structure. The secure key is derived from the Ethereum address.
+#### Cuenta Ethereum Leaf Node
+Para una Cuenta Ethereum Leaf Node, consiste en una dirección de Ethereum y una estructura de datos de cuenta de estado. La key segura se deriva de la dirección de Ethereum.
```go
var address byte[20] // 20 bytes in big-endian
valHi := address[0:16]
@@ -109,7 +109,7 @@ valLo := address[16:20] * 2^96 // padding 12 bytes of 0 at the end
nodeKey := h{256}(valHi, valLo)
```
-A state account struct in the Scroll consists of the following fields (`Fr` indicates the finite field and is a 254-bit value)
+Una estructura de cuenta de estado en el Scroll consta de los siguientes campos (`Fr` indica el campo finito y es un valor de 254 bits)
- `Nonce`: u64
- `Balance`: u256, but treated as Fr
@@ -118,7 +118,7 @@ A state account struct in the Scroll consists of the following fields (`Fr` indi
- `PoseidonCodeHash`: Fr
- `CodeSize`: u64
-Before computing the value hash, the state account is first marshaled into a list of `u256` values. The marshaling scheme is
+Antes de calcular el value hash, la cuenta de estado se transforma en una lista de valores `u256`. El esquema es el siguiente
```text
(The following scheme assumes the big-endian encoding)
@@ -133,7 +133,7 @@ Before computing the value hash, the state account is first marshaled into a lis
(total 160 bytes)
```
-The marshal function also returns a `flag` value along with a vector of `u256` values. The `flag` is a bitmap that indicates whether a `u256` value cannot be treated as a field element (Fr). The `flag` value for state account is 8, shown below.
+La función marshal también devuelve un valor `flag` junto con un vector de valores `u256`. El `flag` es un mapa de bits que indica si un valor `u256` no puede ser tratado como un elemento de campo (Fr). El valor `flag` para la cuenta de estado es 8, como se muestra a continuación.
```
+--------------------+---------+------+----------+----------+
@@ -146,18 +146,18 @@ flag bit | 0 | 0 | 0 | 1 | 0 |
(LSB) (MSB)
```
-The value hash is computed in two steps:
-1. Convert the value that cannot be represented as a field element of the Poseidon hash to the field element.
-2. Combine field elements in a binary tree structure till the tree root is treated as the value hash.
+El value hash se calcula en dos pasos:
+1. Convertir el valor que no puede ser representado como un elemento de campo del Poseidon hash al elemento de campo.
+2. Combinar elementos de campo en una estructura de tree binario hasta que la root del tree sea tratada como el value hash.
-In the first step, when the bit in the `flag` is 1 indicating the `u256` value that cannot be treated as a field element, we split the value into a high-128bit value and a low-128bit value, and then pass them to a Poseidon hash to derive a field element value, `h(valueHi, valueLo)`.
+En el primer paso, cuando el bit en el `flag` es 1 indicando el valor `u256` que no puede ser tratado como un elemento de campo, dividimos el valor en un valor alto-128bit y un valor bajo-128bit, y luego los pasamos a un Poseidon hash para derivar un valor de elemento de campo, `h(valueHi, valueLo)`.
```go
// convert Keccak codehash to a field element
compressedKeccakCodeHash := h{512}(keccakCodeHash[0:16], keccakCodeHash[16:32])
```
-Second, the value hash is computed as follows.
+En segundo lugar, el value hash se calcula del siguiente modo.
```go
domain := 256 * 5 // 5 elements to compute the valueHash
@@ -174,9 +174,9 @@ valueHash :=
)
```
-#### Storage Leaf Node
+#### Almacenamiento de Leaf Node
-A Storage Leaf Node encodes a key-value pair, which both key and value are `u256` values. The secure key of this leaf node is derived from the storage key.
+Un leaf node de almacenamiento codifica un par key-value, en el que tanto la key como el value son valores `u256`. La key segura de este leaf node se deriva de la key de almacenamiento.
```go
var storageKey byte[32] // 32 bytes in big-endian
@@ -185,7 +185,7 @@ valLo := storageKey[16:32]
nodeKey := h{256}(valHi, valLo)
```
-The storage value is a `u256` value. The `flag` for the storage value is 1, showed below.
+El value de almacenamiento es un valor `u256`. El `flag` para el value or de almacenamiento es 1, como se muestra a continuación.
```
+--------------+
@@ -197,7 +197,7 @@ flag bit | 1 |
+--------------+
```
-The value hash is computed as follows
+El value hash se calcula del siguiente modo
```go
valueHash = h{512}(storageValue[0:16], storageValue[16:32])
diff --git a/src/content/docs/es/technology/zkevm/intro-to-zkevm.md b/src/content/docs/es/technology/zkevm/intro-to-zkevm.md
index 1c4bc4772..04f07ec62 100644
--- a/src/content/docs/es/technology/zkevm/intro-to-zkevm.md
+++ b/src/content/docs/es/technology/zkevm/intro-to-zkevm.md
@@ -1,30 +1,30 @@
---
section: technology
date: Last Modified
-title: "Intro to zkEVM"
-lang: "en"
+title: "Introducción a la zkEVM"
+lang: "es"
permalink: "technology/intro-to-zkevm"
excerpt: "ZK rollups are widely recognized as the ideal scaling solution for Ethereum."
-whatsnext: { "zkEVM Overview": "/technology/zkevm/zkevm-overview" }
+whatsnext: { "Vista General de la zkEVM ": "/es/technology/zkevm/zkevm-overview" }
---
-## Introduction and motivation
+## Introducción y Motivación
-ZK rollups are widely recognized as the ideal scaling solution for Ethereum. They inherit the strong security of Ethereum Layer 1 and offer the fastest transaction finality compared to other Layer 2 solutions.
+Los rollups ZK son ampliamente reconocidos como la solución de escalado ideal para Ethereum. Heredan la fuerte seguridad de la capa 1 de Ethereum y ofrecen la finalidad de transacción más rápida en comparación con otras soluciones de capa 2.
-The basic idea of a ZK rollup is to execute transactions off-chain and to generate succinct proofs of the execution’s validity. These succinct proof can then be posted and verified on Ethereum Layer 1. ZK rollups improve scalability since verifying the proof for a batch of transactions is much cheaper than re-executing the batch of transactions.
+La idea básica de un ZK rollup es ejecutar transacciones fuera de la cadena y generar pruebas de validez sucintas de ejecución. Estas pruebas sucintas pueden publicarse y verificarse en la capa 1 de Ethereum. Los ZK rollups mejoran la escalabilidad, ya que verifican la prueba de un lote de transacciones es mucho más barato que volver a ejecutar el lote de transacciones.
-ZK rollups can be categorized into application-specific and general-purpose rollups, based on the types of transactions they support. Application-specific ZK rollups are designed for particular transaction sets, such as payments and swaps, or a player’s action set for an on-chain game. In these cases, rollups only need to generate proofs attesting to the correctness of the supported primitives, such as valid state transitions for game players.
+Los rollups ZK pueden clasificarse en rollups de aplicación específica y rollups de uso general, en función de los tipos de transacciones que admiten. Los rollups ZK para aplicaciones específicas están diseñados para conjuntos de transacciones particulares, como pagos y swaps, o por ejemplo, el conjunto de acciones de un jugador para un juego online. En estos casos, los rollups sólo necesitan generar pruebas que demuestren la veracidad de las primitivas soportadas, como las transiciones de estado válidas para los jugadores de un juego.
-On the other hand, general-purpose ZK rollups support a wider range of transactions and computations. These rollups use a virtual machine (VM) to execute assembly code, and then generate a proof to show that the execution was done correctly according to the VM's specifications. The particular VM that a ZK rollup uses for its computation differs across the many ZK rollup projects. Some projects elect to build their own VM, optimized for fast proof generation. Other projects elect to use the EVM, for optimal compatibility with the Ethereum ecosystem.
+Por otro lado, los ZK rollups de propósito general admiten una gama más amplia de transacciones y cálculos. Estos rollups utilizan una máquina virtual (VM) para ejecutar código assembly y, a continuación, generan una prueba para demostrar que la ejecución se ha realizado correctamente de acuerdo con las especificaciones de la VM. La máquina virtual concreta que utiliza un ZK rollup para sus cálculos varía en función de los proyectos de ZK rollup que existen. Algunos proyectos optan por construir su propia máquina virtual, optimizada para la generación rápida de pruebas. Otros proyectos optan por utilizar la EVM, para una compatibilidad óptima con el ecosistema Ethereum.
-Scroll is a general-purpose ZK rollup that uses the EVM for off-chain computations. Scroll’s execution layer functions similarly to Ethereum’s - transactions are batched into blocks, and then the blocks are executed according to the [EVM](https://ethereum.org/en/developers/docs/evm/) specs (we actually use a slightly [modified version](https://github.com/scroll-tech/go-ethereum) of [Geth](https://geth.ethereum.org/)). This means that users can interact with Scroll in the same way that they would interact with Ethereum. It also means that developers can develop on top of Scroll just as they would develop on top of Ethereum.
+Scroll es un ZK rollup de propósito general que utiliza la EVM para cálculos fuera de la cadena. La capa de ejecución de Scroll funciona de forma similar a la de Ethereum: las transacciones se agrupan en bloques y, a continuación, los bloques se ejecutan de acuerdo con las especificaciones [EVM](https://ethereum.org/en/developers/docs/evm/) (en realidad utilizamos una versión ligeramente [modificada](https://github.com/scroll-tech/go-ethereum) de [Geth](https://geth.ethereum.org/)). Esto significa que los usuarios pueden interactuar con Scroll del mismo modo que lo harían con Ethereum. También significa que los desarrolladores pueden trabajar con Scroll del mismo modo que lo harían con Ethereum.
-However, achieving Ethereum compatibility with a ZK rollup poses a large challenge - the rollup must be able to generate a proof proving that an off-chain EVM computation was executed correctly. This is essentially what a “zkEVM” is: **a zkEVM is a system that proves the correct execution of the EVM**.
+Sin embargo, lograr la compatibilidad de Ethereum con un ZK rollup plantea un gran reto: el rollup debe ser capaz de generar una prueba que demuestre que un cálculo EVM fuera de la cadena se ha ejecutado correctamente. Esto es esencialmente lo que es un "zkEVM": **una zkEVM es un sistema que comprueba la correcta ejecución de la EVM**.
-The EVM was originally designed without ZK rollups in mind, and it turns out that it is quite challenging build a zkEVM. However, we at Scroll are undeterred by the challenge, and have been working hard in collaboration with the [Ethereum Privacy and Scaling Explorations](https://appliedzkp.org/) team to make the zkEVM a reality.
+La EVM se diseñó originalmente sin tener en cuenta los ZK rollups, y resulta que es todo un reto construir una zkEVM. Sin embargo, en Scroll no nos dejamos intimidar por el reto y hemos estado trabajando duro en colaboración con el equipo [Ethereum Privacy and Scaling Explorations](https://appliedzkp.org/) para hacer realidad la zkEVM.
-## Learn more
+## Aprende Más
-- [Blog post](https://scroll.io/blog/zkEVM) introducing zkEVM
-- [zkEVM overview](https://youtu.be/NHwd-gJ8xg4) - Haichen Shen
+- [Blog post](https://scroll.io/blog/zkEVM) de la presentación de la zkEVM
+- [Visión general de la zkEVM](https://youtu.be/NHwd-gJ8xg4) - Haichen Shen
diff --git a/src/content/docs/es/technology/zkevm/zkevm-overview.mdx b/src/content/docs/es/technology/zkevm/zkevm-overview.mdx
index 19a1b6326..30eaeff77 100644
--- a/src/content/docs/es/technology/zkevm/zkevm-overview.mdx
+++ b/src/content/docs/es/technology/zkevm/zkevm-overview.mdx
@@ -1,11 +1,10 @@
---
section: technology
date: Last Modified
-title: "zkEVM Overview"
-lang: "en"
+title: "Vista General de la zkEVM"
+lang: "es"
permalink: "technology/zkevm-overview"
-excerpt: "In order to understand how to build a zkEVM, which proves the execution of the EVM, we need to first look at the EVM itself."
-whatsnext: { "Bridge Overview": "/technology/bridge/bridge-overview" }
+excerpt: "Para entender cómo se construye una zkEVM, que prueba la ejecución del EVM, primero tenemos que ver la propia EVM."
---
import ClickToZoom from "../../../../../components/ClickToZoom.astro"
@@ -13,45 +12,45 @@ import zkevm1 from "../_images/zkevm1.png"
import zkevm2 from "../_images/zkevm2.png"
import zkevm3 from "../_images/zkevm3.png"
-## The EVM
+## La EVM
-In order to understand how to build a zkEVM, which proves the execution of the EVM, we need to first look at the EVM itself.
+Para entender cómo construir una zkEVM, que demuestre la ejecución del EVM, primero tenemos que ver la propia EVM.
-The EVM can be modeled as a state transition function. It specifies a transition function `f` that, given an initial world state `S` and a transaction `T`, outputs a new world state `S’`: `f(S,T) = S'`.
+La EVM puede modelarse como una función de transición de estados. Esta especifica una función de transición `f` que, dado un estado inicial del sistema `S` y una transacción `T`, produce un nuevo estado del sistema `S'`: `f(S,T) = S'`.
-The “world state” is modeled as a [modified Merkle-Patricia Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) (MPT). This trie contains all of the network’s persistent data. This includes the information of all externally-owned accounts (EOAs) and smart contract accounts. Smart contract accounts have sub-tries that hold the smart contract’s bytecode and persistent storage.
+El "estado del sistema" se modela como un [Merkle-Patricia Trie modificado](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) (MPT). Este trie contiene todos los datos permanentes de la red. Esto incluye la información de todas las cuentas de propiedad externa (EOAs) y las cuentas de los smart contracts. Las cuentas de smart contracts tienen sub-tries que contienen el bytecode del smart contract y el almacenamiento permanente.
-The EVM processes a new transaction by executing its resulting computations, and making changes to the world state accordingly. EVM computation works over transient data stores (stack and memory) as well as persistent data stores (contract bytecode and storage).
+La EVM procesa una nueva transacción ejecutando los cálculos resultantes y realizando los cambios correspondientes en el estado del sistema. Los cálculos de la EVM funcionan sobre almacenes de datos transitorios (pila y memoria), así como sobre almacenes de datos persistentes (bytecode y almacenamiento del contrato).
-The computation triggered by an individual transaction is broken down into small machine instructions called “opcodes,” which the EVM can directly understand and execute. The behavior of each opcode is specified in the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). The execution of a transaction can therefore be summarized by an “execution trace,” which is simply an ordered list of opcode executions. Ethereum execution clients, such as [Geth](https://geth.ethereum.org/), can explicitly output a step-by-step execution trace for the computation it has performed.
+El cálculo activado por una transacción individual se descompone en pequeñas instrucciones de máquina denominadas "opcodes", que la EVM puede comprender y ejecutar directamente. El comportamiento de cada opcode se especifica en el [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). Por lo tanto, la ejecución de una transacción puede resumirse en una "traza de ejecución", que no es más que una lista ordenada de ejecuciones de opcodes. Los clientes de ejecución de Ethereum, como [Geth](https://geth.ethereum.org/), pueden mostrar explícitamente una traza de ejecución paso a paso del cálculo que han realizado.
-As the opcodes are executed, the state trie is altered. This results in a new state trie, with a new state root.
+A medida que se ejecutan los opcodes, se altera el trie de estado. El resultado es un nuevo trie de estado, con una nueva raíz de estado.
-## Proving an EVM execution
+## Prueba de la ejecución de una EVM
-The goal of a zkEVM is to generate a proof attesting to the validity of a transaction’s execution. In other words, given an initial world state `S`, a transaction `T`, and a resulting world state `S'`, the zkEVM must generate a proof that `f(S,T) = S'`, where `f` is the state transition function specified in the Ethereum Yellow Paper.
+El objetivo de una zkEVM es generar una prueba que certifique la validez de la ejecución de una transacción. En otras palabras, dado un estado inicial del sistema `S`, una transacción `T`, y un estado resultante del sistema `S'`, la zkEVM debe generar una prueba de que `f(S,T) = S'`, donde `f` es la función de transición de estado especificada en el Ethereum Yellow Paper.
-In order to prove the validity of the transition function execution, we break down the execution into its step-by-step execution trace. The execution of `f(S,T)` is expanded into a list of its sequential opcode executions. The execution trace serves as a “witness” attesting to the correctness of the state transition `f(S,T) = S'` - the trace in a sense a step-by-step explanation of how the state transitions from `S` to `S'`.
+Para demostrar la validez de la ejecución de la función de transición, descomponemos la ejecución en su traza de ejecución paso a paso. La ejecución de `f(S,T)` se expande en una lista de sus ejecuciones secuenciales de opcodes. La traza de ejecución sirve como "testigo (o "witness")" de la corrección de la transición de estado `f(S,T) = S'` - la traza es en cierto sentido una explicación paso a paso de cómo el estado pasa de `S` a `S'`.
-The problem is then reduced to proving the following:
+El problema se reduce entonces a demostrar lo siguiente:
-- The execution trace is _correct_.
- - Each individual opcode is correctly executed according to the Ethereum Yellow Paper spec.
- - For example, the `ADD` opcode must result in popping two values off the stack, and pushing their sum to the stack.
- - A proof must show that each opcode was executed with the proper behavior, including any alterations to transient data stores (stack and memory) or persistent data stores (contract bytecode and storage).
- - The ordered list of opcodes being executed is in fact the correct list of opcodes triggered by the transaction.
- - This includes correctly loading the initial transaction calldata, and the bytecode for any invoked contracts.
-- The execution trace starts with initial state `S` and results in state `S'`.
+- La traza de ejecución es _correcta_.
+ - Cada opcode individual se ejecuta correctamente según la especificación del Ethereum Yellow Paper.
+- Por ejemplo, el opcode `ADD` debe resultar en sacar dos valores de la pila, y colocar su suma en la pila.
+- Una prueba debe mostrar que cada opcode fue ejecutado con el comportamiento adecuado, incluyendo cualquier alteración a los almacenes de datos transitorios (pila y memoria) o almacenes de datos permanentes (bytecode del contrato y almacenamiento).
+ - La lista ordenada de opcodes que se ejecutan es de hecho la lista correcta de opcodes activados por la transacción.
+ - Esto incluye cargar correctamente el calldata inicial de la transacción, y el bytecode de cualquier contrato invocado.
+- La traza de ejecución comienza con el estado inicial `S` y termina en el estado `S'`.
-In subsequent sections, we will dive into the details of how the correctness of EVM execution traces can be proved.
+En secciones posteriores, nos adentraremos en los detalles de cómo puede demostrarse la corrección de las trazas de ejecución de la EVM.
-## Learn more
+## Aprende Más
-- Cypherpunks [GitBook chapter](https://cypherpunks-core.github.io/ethereumbook/13evm.html) on the EVM
-- [zkEVM overview](https://youtu.be/NHwd-gJ8xg4) - Haichen Shen
+- "Cypherpunks" [capítulo de GitBook](https://cypherpunks-core.github.io/ethereumbook/13evm.html) sobre la EVM
+- [Visión general de zkEVM](https://youtu.be/NHwd-gJ8xg4) - Haichen Shen
diff --git a/src/content/docs/es/user-guide/bridge.mdx b/src/content/docs/es/user-guide/bridge.mdx
index 08c806a1c..9f9485e9b 100644
--- a/src/content/docs/es/user-guide/bridge.mdx
+++ b/src/content/docs/es/user-guide/bridge.mdx
@@ -2,9 +2,9 @@
section: gettingStarted
date: Last Modified
title: "Bridge"
-lang: "en"
+lang: "es"
permalink: "user-guide/bridge/"
-excerpt: "To start bridging assets from Sepolia, navigate to the portal bridge app."
+excerpt: "Para empezar a transferir activos desde Sepolia, navegue hasta el portal del bridge."
---
{/* // import ClickToZoom from "../../../../components/ClickToZoom.astro" */}
@@ -19,32 +19,32 @@ excerpt: "To start bridging assets from Sepolia, navigate to the portal bridge a
{/* TODO: Update all instructions after being able to walk through the whole flow. */}
-Visit our [Bridge](https://scroll.io/bridge) app to get started![^thanks-hop] The Bridge supports both **Deposit** and **Withdraw** operations, allowing users to trustlessly move assets from Sepolia Testnet to Scroll Sepolia Testnet.
-[^thanks-hop]: Forked from [Hop Exchange]('https://hop.exchange/')'s UI 🙌
+Visite nuestra [Bridge](https://scroll.io/bridge) para empezar. [^thanks-hop] El Bridge admite operaciones de **depósito** y **retirada**, lo que permite a los usuarios mover activos de Sepolia Testnet a Scroll Sepolia Testnet con total confianza.
+[^gracias-hop]: Un fork de la IU de [Hop Exchange]('https://hop.exchange/') 🙌.
-Deposits can take up to 15 minutes to be available on Scroll.
+Los depósitos pueden tardar hasta 15 minutos en estar disponibles en Scroll.
-Withdrawals, which require a second interaction on Sepolia after the withdrawal is finalized, can take much longer.
+Los retiros, que requieren una segunda interacción en Sepolia una vez finalizada la retirada, pueden tardar mucho más.
-:::caution[Waiting a long time for a bridge transaction?]
-The time estimates above are typical for normal network behavior and activity levels. Because we only process so many queued L1 transactions per an L2 block, bridged messages may take longer to be included on Scroll in times of exceptional network usage.
+:::caution[¿Esperando mucho tiempo para una transacción del bridge?]
+Las estimaciones de tiempo anteriores son típicas para el comportamiento normal de la red y los niveles de actividad. Dado que sólo procesamos un número determinado de transacciones de L1 en cola por bloque L2, los mensajes en el bridge pueden tardar más en incluirse en Scroll en momentos de uso excesivo de la red.
:::
-## Deposit from Sepolia to Scroll Sepolia
+## Depósito de Sepolia a Scroll Sepolia
-### Instructions
+### Instrucciones
-1. First, navigate to the [Scroll Bridge](https://scroll.io/bridge) and press the "Connect Wallet."
-1. In the app, ensure that **Ethereum Sepolia** is on top and **Scroll Sepolia** is on the bottom. You can click the "**↓**" button to switch their positions.
-1. Select the token you want to transfer from Sepolia to Scroll Sepolia. If it's you're first time bridging, try "ETH."
-1. If this is your first time transferring a specific ERC20 token, you must **Approve** the Sepolia Bridge contract to access your ERC20 token.
-1. Next, click the **Send to Scroll Sepolia** button to make the deposit. Your wallet will ask to confirm the transfer transaction.
-1. Once the transfer transaction is sent and confirmed, the token will be deducted from your Sepolia wallet.
-1. You can always check the status of a transaction by pressing the "History" icon next to your wallet address in the top-right corner.
+1. En primer lugar, navegue hasta el [Scroll Bridge](https://scroll.io/bridge) y pulse el botón "Connect Wallet".
+1. En la app, asegúrate de que **Ethereum Sepolia** está arriba y **Scroll Sepolia** abajo. Puedes pulsar el botón "**↓**" para cambiar sus posiciones.
+1. Selecciona el token que quieres transferir de Sepolia a Scroll Sepolia. Si es la primera vez que usas el bridge, prueba con "ETH".
+1. Si es la primera vez que transfiere un token ERC20 específico, debe **Aprobar** el contrato Sepolia Bridge para acceder a su token ERC20.
+1. A continuación, haga clic en el botón **Enviar a Scroll Sepolia** para realizar el ingreso. Tu wallet te pedirá que confirmes la transacción de transferencia.
+1. Una vez enviada y confirmada la operación de transferencia, el token se deducirá de tu wallet de Sepolia.
+1. Siempre puede comprobar el estado de una transacción pulsando el icono "Historial" situado junto a la dirección de su wallet en la esquina superior derecha.
-### When will the token arrive in your Scroll Sepolia wallet?
+### ¿Cuándo llegará la token a su wallet de Scroll Sepolia?
-It could take between **8 to 14 minutes** (awaiting block to become [_Safe_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels) on Sepolia) before the token shows up in your Scroll Sepolia wallet.
+Puede tardar entre **8 y 14 minutos** (esperando a que el bloque se vuelva [_Seguro_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels) en Sepolia) antes de que el token aparezca en tu wallet de Scroll Sepolia.
{/* You can check the progress of deposit transactions as follows: */}
@@ -70,37 +70,37 @@ It could take between **8 to 14 minutes** (awaiting block to become [_Safe_](htt
{/* */}
-## Withdraw from Scroll Sepolia to Sepolia
+## Retiro de Scroll Sepolia a Sepolia
-### Instructions
+### Instrucciones
-#### Submitting your Initial Withdrawal Transaction
+#### Envío de la primera transacción de retiro de fondos
-1. First, switch to the **Scroll Sepolia** network in your wallet.
-1. In the app, ensure that **Scroll Sepolia** is on top and **Ethereum Sepolia** is on the bottom. You can click the "**↓**" button to switch the positions.
-1. Select the token you want to transfer from **Scroll Sepolia** to **Sepolia**. If it's you're first time bridging, try "ETH."
-1. If this is your first time transferring a specific ERC20 token, you must **Approve** the Scroll Sepolia Bridge contract to access your ERC20 token.
-1. Next, click the **Send to Ethereum Sepolia** button to make the withdrawal. Your wallet will ask to confirm the transfer transaction.
-1. Once the transfer transaction is sent and confirmed, the token will be deducted from your Scroll Sepolia wallet.
+1. Primero, cambia a la red **Scroll Sepolia** en tu wallet.
+1. En la app, asegúrate de que **Scroll Sepolia** está arriba y **Ethereum Sepolia** abajo. Puedes pulsar el botón "**↓**" para cambiar las posiciones.
+1. Selecciona el token que quieres transferir de **Scroll Sepolia** a **Sepolia**. Si es la primera vez que usas el bridge, prueba con "ETH".
+1. Si es la primera vez que transfiere un token ERC20 específico, debe **Aprobar** el contrato Scroll Sepolia Bridge para acceder a su token ERC20.
+1. A continuación, haga clic en el botón **Enviar a Ethereum Sepolia** para realizar la retirada. Tu wallet te pedirá que confirmes la transacción de transferencia.
+1. Una vez enviada y confirmada la operación de transferencia, el token se deducirá de tu wallet de Scroll Sepolia.
-#### Submitting an Execute Withdrawal Transaction
+#### Envío de una transacción de retiro de fondos
{/* TODO: finish the additional instructions, better estimate "wait time" */}
-_The remaining steps happen on Scroll Sepolia, but you first must wait for your transaction to be fully proven ("finalized") on Ethereum Sepolia. This process can take up to four hours._
+_Los pasos restantes tienen lugar en Scroll Sepolia, pero primero debe esperar a que su transacción esté completamente probada ("finalizada") en Ethereum Sepolia. Este proceso puede durar hasta cuatro horas._
-1. When your withdrawal transaction is completed finalizing on Ethereum Sepolia, you will see the "Claim" button in the Recent Transactions area become solid.
-1. Click the "Claim" button to submit the Execute Withdrawal transaction.
-1. Once submitted, your withdrawn funds should appear immediately in your Sepolia wallet.
+1. Cuando su transacción de retirada haya finalizado en Ethereum Sepolia, verá que el botón "Claim" en el área de Transacciones Recientes se vuelve sólido.
+1. Haga clic en el botón "Claim" para enviar la ejecución de la transacción de retiro de fondos.
+1. Una vez enviado, los fondos retirados deberían aparecer inmediatamente en su wallet de Sepolia.
-### When will the token arrive in your Sepolia wallet?
+### ¿Cuándo llegará el token a su wallet Sepolia?
-The transferred token will arrive in your Sepolia wallet immediately after the block containing your Execute Withdrawal transaction is confirmed on Sepolia.
+El token transferido llegará a tu wallet de Sepolia inmediatamente después de que el bloque que contiene la ejecución de la transacción de retirada se confirme en Sepolia.
{/* TODO: check architecture link is live */}
-:::tip[Rollup Status]
-The rollup status `Finalized` indicates that the correct execution of transactions in this block has been proven by verifying a validity proof on-chain on Sepolia. For more information about rollup status, see [Scroll's Architecture Overview](/technology).
+:::tip[Estatus del Rollup]
+El estado de rollup `Finalizado` indica que se ha comprobado la correcta ejecución de las transacciones de este bloque mediante la verificación de una prueba de validez on-chain en Sepolia. Para más información sobre el estado de rollup, véase [Visión general de la arquitectura de Scroll](/es/technology).
:::
{/* You can check the progress of withdrawal transactions as follows: */}
diff --git a/src/content/docs/es/user-guide/common-errors.mdx b/src/content/docs/es/user-guide/common-errors.mdx
index f1f1b52b8..d7afc4668 100644
--- a/src/content/docs/es/user-guide/common-errors.mdx
+++ b/src/content/docs/es/user-guide/common-errors.mdx
@@ -1,41 +1,41 @@
---
section: gettingStarted
date: Last Modified
-title: "Common Errors"
-lang: "en"
+title: "Errores Comunes"
+lang: "es"
permalink: "user-guide/common-errors/"
-excerpt: "Seeing an error when trying to interact with Scroll Sepolia Testnet? Here are some common configuration errors and how to quickly fix them."
+excerpt: "¿Ve un error cuando intenta interactuar con Scroll Sepolia Testnet? Aquí hay algunos errores comunes de configuración y cómo solucionarlos rápidamente."
---
-## Incorrect nonce error when sending a transaction in MetaMask
+## Error de nonce incorrecto al enviar una transacción en MetaMask
-You will encounter this error when the local nonce stored in your MetaMask wallet is different from the nonce in the Scroll testnet node. It could be because there is a recent pending transaction.
+Encontrará este error cuando el nonce local almacenado en su wallet MetaMask sea diferente del nonce en el nodo Scroll testnet. Podría deberse a que hay una transacción pendiente reciente.
-To fix this issue, you need to reset your account in MetaMask for the Scroll Sepolia Testnet. The steps to reset the account are:
+Para solucionar este problema, es necesario restablecer su cuenta en MetaMask para el Scroll Sepolia Testnet. Los pasos para restablecer la cuenta son:
-1. Open the **MetaMask** extension in the browser
-2. Select **Scroll Sepolia Testnet** in the top area
-3. Click the round **account icon** in the top-right corner
-4. Select **Settings**
-5. Go to **Advanced**
-6. Click **Reset account**
+1. Abra la extensión **MetaMask** en el navegador
+2. Seleccione **Scroll Sepolia Testnet** en el área superior
+3. Haz clic en el **icono de la cuenta** redondo en la esquina superior derecha
+4. Seleccione **Configuración**
+5. Vaya a **Avanzado**.
+6. Haga clic en **Borrar datos de la pestaña de actividad**.
-You will not lose any assets during the MetaMask account reset.
+No perderás ningún activo durante el reinicio de la cuenta MetaMask.
-:::caution[Caution]
-Removing and re-adding a network is NOT enough to fix this - you must reset your account.
+:::caution[Precaución]
+Eliminar y volver a añadir una red NO es suficiente para solucionarlo, debes restablecer tu cuenta.
:::
-## Nothing happens when confirming a bridging/swapping transaction
+## No ocurre nada al confirmar una transacción bridging/swapping
-If no error or console logs appear, this is likely due to a nonce issue, please reset your MetaMask account as outlined above at [#incorrect-nonce-error-when-sending-a-transaction-in-metamask](#incorrect-nonce-error-when-sending-a-transaction-in-metamask).
+Si no aparece ningún error o registro de consola, es probable que se deba a un problema de nonce, por favor, reinicie su cuenta MetaMask como se indica más [arriba](/es/user-guide/common-errors#error-de-nonce-incorrecto-al-enviar-una-transacción-en-metamask).
-## Block Explorer shows "Internal server error"
+## Block Explorer muestra "Internal server error".
-Use an incognito window, or open your browser developer console and remove the `_explorer_key` cookie (or all cookies). [See this guide for how to remove cookies.](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/).
+Utiliza una ventana de incógnito o abre la "Developer Console" de tu navegador y elimina la cookie `_explorer_key` (o todas las cookies). [Consulta esta guía para saber cómo eliminar las cookies](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/).
-## Sending max amount of Ether in MetaMask results in a "Failed" error
+## Al enviar la cantidad máxima de ETH en MetaMask se produce un error "Failed".
-When sending Ether using MetaMask, if you try sending the "Max" amount, it's going to result in a "Failed" error. This is because MetaMask doesn't account for the additional "L1 Fee" that rollups have on top of regular gas fees and falls short for a small amount needed to pay for the gas of the transaction.
+Cuando envías ETH usando MetaMask, si intentas enviar la cantidad "Max", y resulta en un error "Failed". Esto se debe a que MetaMask no tiene en cuenta la "Comisión L1" adicional que tienen los rollups además de la comisión normal por el gas, por ello, se queda corto en una pequeña cantidad necesaria para pagar el gas de la transacción.
-To solve this, manually lower the amount of ether to be a little smaller than suggested and the transaction will go through.
+Para solucionar esto, baje manualmente la cantidad de ETH para que sea un poco menor que la sugerida y la transacción se realizará.
diff --git a/src/content/docs/es/user-guide/faucet.mdx b/src/content/docs/es/user-guide/faucet.mdx
index f9408df26..c94dcbe4b 100644
--- a/src/content/docs/es/user-guide/faucet.mdx
+++ b/src/content/docs/es/user-guide/faucet.mdx
@@ -2,34 +2,34 @@
section: gettingStarted
date: Last Modified
title: "Faucet"
-lang: "en"
+lang: "es"
permalink: "user-guide/faucet/"
-whatsnext: { "Bridge your ETH to Scroll Sepolia": "/user-guide/bridge" }
-excerpt: "To interact with our testnet, you first need to acquire Sepolia ETH. There are a few Sepolia faucet apps to get you started."
+whatsnext: { "Pasa tu ETH a Scroll Sepolia": "/es/user-guide/bridge" }
+excerpt: "Para interactuar con nuestra testnet, primero necesitas adquirir Sepolia ETH. Hay algunas aplicaciones de faucets de Sepolia para empezar."
---
-To interact with our testnet, you first need to receive testnet ETH on _Sepolia Testnet_. Then you may bridge from _Sepolia Testnet_ to _Scroll Sepolia Testnet_.
+Para interactuar con nuestra testnet, primero necesitas recibir ETH de la _Sepolia Testnet_. Luego puedes usar un bridge de _Sepolia Testnet_ a _Scroll Sepolia Testnet_.
-## Sepolia Faucets
+## Faucets de Sepolia
-Each faucet has its own rules and requirements, so you may need to try a few before you find one that works for you.
+Cada faucet tiene sus propias reglas y requisitos, por lo que es posible que tengas que probar unos cuantos antes de encontrar uno que funcione para ti.
-Here are a few Sepolia faucet apps:
+Aquí tienes algunos faucets de Sepolia:
- [https://sepoliafaucet.com](https://sepoliafaucet.com//)
- [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de/)
- [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip)
- [https://faucet.chainstack.com](https://faucet.chainstack.com)
-Once you receive ETH on Sepolia, you should see it in your wallet on the _Sepolia Network_. It may take a few seconds for them to appear, but you can check the status by looking for a transaction to your address on a [Sepolia Block Explorer](https://sepolia.etherscan.io/).
+Una vez que recibas ETH en Sepolia, deberías verlos en tu wallet en la _Red Sepolia_. Pueden tardar unos segundos en aparecer, pero puedes comprobar el estado buscando una transacción a tu dirección en un [Explorador de bloques de Sepolia](https://sepolia.etherscan.io/).
-:::note[Pace Yourself!]
-Most faucets only allow requests for test tokens once every 24 hours.
+:::note[A tu ritmo!]
+La mayoría de los faucets sólo permiten solicitar tokens de prueba una vez cada 24 horas.
:::
-## Scroll Sepolia Faucets
+## Faucets de Scroll Sepolia
-If you don't want to interact with the bridge, some faucets directly distribute Scroll Sepolia ETH. -->
+Si no quieres interactuar con el bridge, algunos faucets distribuyen ETH directamente a Scroll Sepolia . -->
- [https://scroll.l2scan.co/faucet](https://scroll.l2scan.co/faucet)
- [https://www.covalenthq.com/faucet/](https://www.covalenthq.com/faucet/)
diff --git a/src/content/docs/es/user-guide/index.md b/src/content/docs/es/user-guide/index.md
index 1b845d330..264af3aca 100644
--- a/src/content/docs/es/user-guide/index.md
+++ b/src/content/docs/es/user-guide/index.md
@@ -1,36 +1,36 @@
---
section: gettingStarted
date: Last Modified
-title: "Scroll Sepolia User Guide"
-lang: "en"
+title: "Guía de Usuario de Scroll Sepolia"
+lang: "es"
permalink: "user-guide/"
-excerpt: "Thank you for testing out our Sepolia Testnet. The Sepolia Testnet consists of Ethereum's Sepolia Testnet and the Scroll Sepolia test network."
-whatsnext: { "Set Up Your Wallet": "/user-guide/setup" }
+excerpt: "Gracias por probar nuestra Scroll Sepolia Testnet. La Sepolia Testnet está formada por la Sepolia Testnet de Ethereum y la red de pruebas Scroll Sepolia."
+whatsnext: { "Configuración de Wallet": "/es/user-guide/setup" }
---
-Thank you for testing the Scroll Sepolia Testnet. If you have questions or want to give feedback, join our [Discord](https://discord.gg/scroll)!
+Gracias por probar la Scroll Sepolia Testnet. Si tienes preguntas o quieres darnos tu opinión, ¡únete a nuestro [Discord](https://discord.gg/scroll)!
-The Sepolia Testnet consists of _Ethereum's Sepolia Testnet_ and the _Scroll Sepolia_ test network. Sepolia is an Ethereum test network, while Scroll Sepolia is a zero-knowledge rollup testnet deployed on top of the former. There are some pre-deployed demo applications: a [bridge](https://scroll.io/bridge) between _Sepolia_ and _Scroll Sepolia_,[^1] a [block explorer](https://sepolia-blockscout.scroll.io/) for _Scroll Sepolia_,[^2] and a [rollup explorer](https://scroll.io/rollupscan).
+Sepolia Testnet está formada por _Ethereum's Sepolia Testnet_ y la red de pruebas _Scroll Sepolia_. Sepolia es una red de pruebas de Ethereum, mientras que Scroll Sepolia es una zero-knowledge rollup testnet desplegada sobre la primera. Existen algunas aplicaciones demo predesplegadas: un [bridge](https://scroll.io/bridge) entre _Sepolia_ y _Scroll Sepolia_,[^1] un [block explorer](https://sepolia-blockscout.scroll.io/) para _Scroll Sepolia_,[^2] y un [rollup explorer](https://scroll.io/rollupscan).
-To view L1 transactions, check out Etherscan's [Sepolia explorer](https://sepolia.etherscan.io/).
-To view L2 transactions, you can use Scroll's block explorer, but you may also want to try out the additional functionality provided by [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) or [L2Scan](https://scroll.l2scan.co/).
+Para ver transacciones L1, echa un vistazo al [Sepolia explorer] de Etherscan(https://sepolia.etherscan.io/).
+Para ver las transacciones L2, puedes usar el explorador de bloques de Scroll, pero también puedes probar la funcionalidad adicional proporcionada por [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) o [L2Scan](https://scroll.l2scan.co/).
-Here is the suggested workflow to explore the Testnet:
+Este es el flujo de trabajo sugerido para explorar la Testnet:
-1. Add the [Sepolia Testnet](https://scroll.io/portal) configurations to your wallet.
-2. Request test tokens in the _Sepolia_ network from any Ethereum Faucet app. (see [Faucet](/user-guide/faucet) article)
-3. Transfer test tokens from _Sepolia_ to _Scroll Sepolia_ through the [Bridge](https://scroll.io/bridge) app.
-4. Transfer tokens to other wallets on _Scroll Sepolia_ using your wallet.
-5. Explore our ecosystem, interacting with contracts like [Uniswap](http://uniswap-showcase.sepolia.scroll.xyz/).
-6. Withdraw tokens from _Scroll Sepolia_ to _Sepolia_ through the [Bridge](https://scroll.io/bridge) app.
+1. Añade las configuraciones de [Sepolia Testnet](https://scroll.io/portal) a tu wallet.
+2. Solicita tokens de prueba en la red _Sepolia_ desde cualquier aplicación de Ethereum Faucet. (véase el artículo [Faucet](/es/user-guide/faucet)).
+3. Transfiere tokens de prueba de _Sepolia_ a _Scroll Sepolia_ a través del [Bridge](https://scroll.io/bridge).
+4. Transfiere tokens a otras wallets en _Scroll Sepolia_ utilizando tu wallet.
+5. Explora nuestro ecosistema, interactuando con contratos como [Uniswap](http://uniswap-showcase.sepolia.scroll.xyz/).
+6. Retira tokens de _Scroll Sepolia_ a _Sepolia_ a través del [Bridge](https://scroll.io/bridge).
-You can find the instructions for each app in the rest of this user guide.
+Encontrarás las instrucciones de cada aplicación en el resto de esta guía del usuario.
-## Questions & Feedback
+## Preguntas y Feedback
-If you encounter any issues, join our [Discord](https://discord.gg/scroll) and talk to us in the `#general-support` channel. We would love to hear your thoughts or feedback on how we can improve your experience, too.
+Si tienes algún problema, únete a nuestro [Discord](https://discord.gg/scroll) y habla con nosotros en el canal `#general-support`. También nos encantaría conocer tus opiniones o comentarios sobre cómo podemos mejorar tu experiencia.
-[^1]: Forked from the [Hop Exchange](https://hop.exchange/) UI 🐇🙌
-[^2]: Using [Blockscout](https://blockscout.com/)'s great open source block explorer
+[^1]: Un fork de la IU de [Hop Exchange](https://hop.exchange/) 🐇🙌.
+[^2]: Usando el gran explorador de bloques de código abierto de [Blockscout](https://blockscout.com/)
diff --git a/src/content/docs/es/user-guide/setup.mdx b/src/content/docs/es/user-guide/setup.mdx
index 3f90fe4ce..9f352d6d4 100644
--- a/src/content/docs/es/user-guide/setup.mdx
+++ b/src/content/docs/es/user-guide/setup.mdx
@@ -1,42 +1,41 @@
---
section: gettingStarted
date: Last Modified
-title: "Setup"
-lang: "en"
+title: "Configuración"
+lang: "es"
permalink: "user-guide/setup/"
-whatsnext: { "Grab Sepolia ETH from a Faucet": "/user-guide/faucet" }
-excerpt: "You need to have a wallet to interact with the Scroll Testnet. You can find some example wallets and configuration tips here."
+whatsnext: { "Obten ETH de Sepolia ETH desde un Faucet": "/es/user-guide/faucet" }
+excerpt: "Necesitas tener un wallet para interactuar con la Scroll Testnet. Puedes encontrar algunas wallets de ejemplo y consejos de configuración aquí."
---
import Aside from "../../../../components/Aside.astro"
## Wallet
-You need to have a wallet to interact with dApps on the Scroll Sepolia testnet. You can find some example wallets and configuration tips below. Our Bridge app supports MetaMask, Coinbase Wallet, or any wallet with WalletConnect support.
+Necesitas tener una wallet para interactuar con las dApps en la Scroll Sepolia testnet. Puedes encontrar algunos ejemplos de wallets y consejos de configuración más abajo. Nuestra aplicación Bridge es compatible con MetaMask, Coinbase Wallet o cualquier otra wallet compatible con WalletConnect.
### MetaMask
-You can install MetaMask from their [official website](https://metamask.io/download/).
+Puedes instalar MetaMask desde su [sitio web oficial](https://metamask.io/download/).
-You can import the Scroll Sepolia testnet configurations to your MetaMask wallet. To do this, visit the [Scroll Sepolia portal](https://scroll.io/portal), then click the "Connect Wallet" button and select MetaMask. Next, click the "Add to MetaMask" buttons for Sepolia Testnet and Scroll Sepolia Testnet. This will import the chain ID and RPC URLs for the Scroll Sepolia Testnet. The Sepolia Testnet is also configured on MetaMask by default. To show it, click "Show/hide test networks" in the MetaMask network selection dropdown menu.
+Puedes importar las configuraciones de la Scroll Sepolia testnet a tu wallet de MetaMask. Para ello, visita el [portal de Scroll Sepolia](https://scroll.io/portal), luego haz clic en el botón "Connect Wallet" y selecciona MetaMask. A continuación, haga clic en los botones "Add to MetaMask" para Sepolia Testnet y Scroll Sepolia Testnet. Esto importará el ID de cadena y las URL RPC para el Scroll Sepolia Testnet. La Sepolia Testnet también está configurada por defecto en MetaMask. Para mostrarla, haz clic en "Mostrar/ocultar redes de prueba" en el menú desplegable de selección de redes de MetaMask.
-### Manual network configuration (for other wallets)
+### Configuración manual de la red (para otras wallets)
-The **Add to wallet** links may not be compatible with every wallet. If you are having issues using them, you may need to manually add the _Sepolia Testnet_ and _Scroll Sepolia_ network by inserting the configuration details from the table below:
+Los links **Add to wallet** pueden no ser compatibles con todos las wallets. Si tiene problemas para utilizarlos, puede que necesite añadir manualmente la red _Sepolia Testnet_ y _Scroll Sepolia_ introduciendo los detalles de configuración de la tabla siguiente:
-| Network Name | Scroll Sepolia Testnet | Sepolia Testnet |
+| Nombre de la Red | Scroll Sepolia Testnet | Sepolia Testnet |
| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) |
| Chain ID | 534351 | 11155111 |
| Currency Symbol | ETH | ETH |
| Block Explorer URL | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) |
-
- For looking into activity on Layer 1, use Etherscan's [Sepolia Testnet Explorer](https://sepolia.etherscan.io).
+
+ Para ver la actividad en la Capa 1, utiliza [Sepolia Testnet Explorer](https://sepolia.etherscan.io) de Etherscan.
-For an alternative block explorer experience, Unifra has built [L2Scan](https://scroll.l2scan.co/), which lets users
-explore additional aspects of the Scroll Sepolia Testnet.
-[Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) also supports Scroll Sepolia and provides a
-multi-chain view of blockchain activity.
+Para una experiencia de exploración de bloques alternativa, Unifra ha construido [L2Scan](https://scroll.l2scan.co/), que permite a los usuarios
+explorar otros aspectos del Scroll Sepolia Testnet.
+[Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) también es compatible con Scroll Sepolia y ofrece una visión multi-chain de la actividad de la blockchain.
diff --git a/src/content/docs/es/user-guide/transfer-tokens.md b/src/content/docs/es/user-guide/transfer-tokens.md
index ae62be9f4..6df1fd1c1 100644
--- a/src/content/docs/es/user-guide/transfer-tokens.md
+++ b/src/content/docs/es/user-guide/transfer-tokens.md
@@ -1,18 +1,18 @@
---
section: gettingStarted
date: Last Modified
-title: "Transfer Tokens"
-lang: "en"
+title: "Transferencia de Tokens"
+lang: "es"
permalink: "user-guide/transfer-tokens/"
-excerpt: "You can use your wallet as usual to transfer tokens within the Scroll Sepolia Testnet."
+excerpt: "Puede utilizar su wallet como de costumbre para transferir tokens dentro de la Scroll Sepolia Testnet."
---
-You can use your wallet's normal function for transferring tokens within the Scroll Sepolia Testnet -- no additional configurations are needed.
+Puede utilizar la funcionalidad normal de su wallet para transferir tokens dentro de la Testnet de Scroll Sepolia -- no es necesaria ninguna configuración adicional.
-## Sending a token in MetaMask
+## Envío de un token en MetaMask
-1. Open your wallet and switch to **Scroll Sepolia Testnet**.
-2. Click the **Send** button in the middle and type the address you want to transfer to in the text box.
-3. Select the token in the **Asset** box and type the amount of token that you want to transfer.
-4. Click the **Next** button and then click the **Confirm** button to send out the transaction.
-5. After sending, you can find the transaction in the **Activity** tab in your wallet.
+1. Abra su wallet y cambie a **Scroll Sepolia Testnet**.
+2. Haga clic en el botón **Enviar** del centro y escriba la dirección a la que desea transferir en el cuadro de texto.
+3. Selecciona el token en la casilla **Activo** y escribe la cantidad de token que quieres transferir.
+4. Pulsa el botón **Siguiente** y después pulsa el botón **Confirmar** para enviar la transacción.
+5. Después del envío, puede encontrar la transacción en la pestaña **Actividad** de su wallet.