L2 en EspañolIntroducción a la Data Availability
📌IntroducciónUno de los conceptos que más se repiten en la industria cripto es “trustless”, lo cual significa en esencia que no debes confiar en nadie sin validarlo primero. Es por esto que las blockchains poseen nodos completos, los cuales descargan y ejecutan la data que proporcionan los “bloques” (blocks en inglés) y se aseguran que los cálculos propuestos por el block producer coinciden precisamente con los cálculos hechos por el validador. De esta manera, los nodos verifican que esta nu...
L2 en EspañolIntroducción al Optimistic Rollup de Arbitrum
🔵IntroducciónEl Optimistic Rollup de Arbitrum es una solución de capa 2 diseñada para abordar los desafíos de escalabilidad de la red Ethereum. Arbitrum ofrece una forma más rápida y económica de realizar transacciones en Ethereum al aprovechar la técnica de los Optimistic Rollups. En este sistema, la mayoría de las operaciones se realizan fuera de la cadena principal (es decir fuera de mainnet ó off-chain), lo que permite aumentar la eficiencia y reducir los costos. En este artículo, explic...
L2 en EspañolArbitrum Nitro: Guía para correr un full node
IntroducciónLos Rollups, al igual que cualquier blockchain, operan en función de un nodo completo. En una blockchain de capa 1, el nodo completo representa la unidad fundamental que impulsa la seguridad y descentralización de la red. Para el usuario individual, proporciona accesibilidad, soberanía y privacidad al interactuar con la red. En un Optimistic Rollup completamente funcional, la noción de un "nodo completo" no ofrece el mismo nivel de beneficios desde la perspectiva de la red, debido...
Comunidad dedicada al estudio de soluciones de escalabilidad en Ethereum. Impulsado y administrado por DeFi para Principiantes y SEED Latam.
En el ecosistema Web3, la función de un bridge (aka puente) puede parecer sencilla a primera vista: facilitar la transferencia de tokens de una cadena a otra. Sin embargo, la realidad es mucho más intrigante y compleja. En su esencia, los bridges son el medio en el que se transmiten mensajes, como por ejemplo, un mensaje que implica la congelación del activo que deseas transferir a una blockchain y, como resultado, emiten tokens equivalentes en la cadena de destino. Estos tokens equivalentes, a menudo denominados "envueltos" o "wrapped," representan la criptomoneda o el token original, pero cuentan con la versatilidad de circular y utilizarse en diferentes blockchains. Por ejemplo, cuando deseas transferir Ethereum a la blockchain de Scroll, el bridge se encarga de inmovilizar el Ethereum original y, a cambio, emite tokens equivalentes en blockchain de Scroll.
En este artículo, nos sumergiremos en la forma en que Scroll aprovecha el poder de su bridge para facilitar la transferencia de activos entre L1 y L2 (capas 1 y 2) y viceversa. Además, exploraremos las implicaciones y las características únicas que distinguen a Scroll en este aspecto.
Mensajes entre Dominios L1 y L2.
Envío de mensajes de L1 a L2.
Proceso de Envío de Mensajes y Transacciones.
Envío de Mensajes Arbitrarios.
Envío de Transacciones Forzadas.
Reintento de Mensajes Fallidos.
Tarifa de Retransmisión de Mensajes.
Alias de Dirección.
Envío de mensajes de L2 a L1.
Withdraw Trie.
Gateways de tokens.
Gateways de depósito
Caso 1: Deposito de ETH.
Caso 2: Depositos de tokens ERC-20 Stardard / Custom ERC-20 / WETH.
Caso 3: Deposito de tokens ERC-721/ERC-1155.
Gateways de Retiro.
Caso 1: Retiro de ETH.
Caso 2: Retiro de tokens ERC-20/Custom tokens/WETH.
Caso 3: Deposito de tokens ERC-721/ERC-1155.
Conclusión.
Glosario.
En Scroll los usuarios tienen la posibilidad de usar un puente para mensajes arbitrarios que permite la transferencia de tokens y a su vez deja a las que dapps puedan comunicarse entre L1 y L2. Por consecuencia, esto significa que una Dapps en L1 puede activar funciones de un contrato en L2 y viceversa.
Tal como se observa en la figura, existen dos enfoques principales a la hora de interactuar desde L1 a L2: el envío de mensajes arbitrarios a través de Scroll Messenger de L1 (o L1ScrollMessenger) y el envío de transacciones forzadas mediante la Gateway para transacciones forzadas (o EnforcedTxGateway). Ambos métodos permiten a los usuarios iniciar una transacción desde L1 a L2 o interactuar con contratos desplegados en L2 desde L1.
Para los mensajes arbitrarios, el sender en L2 es la dirección del Scroll Messenger de L1 con alias. Por otro lado, para las transacciones forzadas, el sender (o remitente en español) en L2 es una cuenta de propiedad externa (EOA). Además, se proporcionan varias Gateways para facilitar el depósito de ETH y conocidos estándares de tokens, tales como ERC-20, ERC-677, ERC-721 y ERC-1155.
En la Figura 1, tanto los mensajes arbitrarios como las transacciones forzadas se agregan a la cola de mensajes en el contrato Message Queue de L1 (o L1MessageQueue). Este contrato ofrece dos funciones clave: appendCrossDomainMessage y appendEnforcedTransaction para agregar mensajes arbitrarios y transacciones forzadas, respectivamente.
appendCrossDomainMessage: permite agregar mensajes iniciados por L1, utilizando la dirección de alias de Scroll Messenger de L1 como sender.
appendEnforcedTransaction solo puede ser llamada por EnforcedTxGateway y utiliza el sender especificado en el parámetro de función como remitente de la transacción. Esto permite a los usuarios ejecutar un retiro o transferencia de ETH desde sus cuentas L2 directamente a través del bridge L1.
Después de que una transacción se ejecute con éxito en L1, el watcher en el secuenciador de Scroll monitorea el contrato Message Queue de L1 y recopila nuevos eventos llamados QueueTransaction. Estos eventos son utilizados por el secuenciador para construir una nueva transacción L1MessageTx, que luego se agrega a su cola de transacciones L1 local.
Las transacciones L1MessageTx siempre aparecen primero en los bloques L2, seguidas de las transacciones L2.
La dirección del contrato Scroll Messenger de L1 proporciona dos funciones sendMessage para enviar mensajes arbitrarios. La diferencia principal entre ellas es que la segunda permite a los usuarios especificar una dirección de reembolso para recibir el exceso de gas.
A nivel de código las 2 funciones se ven de la siguiente manera:
Ambas funciones requieren que los usuarios proporcionen un límite de gas y paguen el fee de retransmisión por adelantado en L1. Los detalles se codifican en un mensaje entre dominios, y luego se utilizan como datos de llamada en la transacción L1MessageTx en L2.
El contrato EnforcedTxGateway ofrece dos funciones sendTransaction para enviar transacciones forzadas. La diferencia clave radica en quién es el remitente de la transacción en L2: el remitente de la transacción o la dirección especificada. Esto permite a un tercero enviar una transacción forzada en nombre del usuario y pagar la tasa 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 remitente.
Ambas funciones exigen que el remitente sea una cuenta EOA y la tarifa de retransmisión se deduzca de la cuenta L1. El valor pasado a la función indica la cantidad de ETH que se transferirá desde la cuenta del remitente en L2, no en L1.
Si una transacción L1MessageTx falla en L2 debido a la falta de gas, los usuarios pueden reintentar con un límite de gas más alto utilizando la función replayMessage del contrato Scroll Messenger de L1. Este mensaje se convertirá en un nuevo L1MessageTx en L2. Tenga en cuenta que no se reembolsará la tarifa del gas por la transacción fallida anterior, por que ya está procesada en L2.
La tarifa de retransmisión de mensajes L1 a L2 se calcula en función del límite de gas y se almacena en la dirección del contrato L2GasPriceOracle (o Oráculo de gas en L2) Esta tarifa se deduce de la cuenta L1 y es igual a gasLimit * l2BaseFee.
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 alias de dirección cuando el emisor del mensaje es un contrato en L1. La dirección del remitente alias de la transacción del mensaje en L1 es l1_contract_address + offset, donde el offset es 0x1111000000000000000000000000000000001111.
En la Capa 2 (L2), los usuarios tienen la capacidad de enviar mensajes arbitrarios utilizando el Scroll Messenger de L2 (o L2ScrollMessenger) para facilitar la retirada de tokens e interactuar con los contratos desplegados en la Capa 1 (L1). Al igual que en L1, Scroll ha desarrollado diversas Gateways de Tokens estándar para simplificar el proceso de inicio de retiros.
Adicionalmente, el contratoScroll Messenger de L2 incluye una función denominada sendMessage. Es importante destacar que esta función difiere de L1ScrollMessenger.sendMessage, ya que no toma en cuenta el parámetro gasLimit. Esto se debe a que, al iniciarse la transacción de ejecución para el retiro en L1, las comisiones de transacción se pagan directamente en L1.
Como resultado, la función sendMessage requiere que la función msg.value coincida con el value especificado en el parámetro. La función codifica los argumentos en un mensaje entre dominios siguiendo el mismo esquema que utiliza Scroll Messenger de L1.
A nivel de código, se veria de la siguiente manera:
Luego, se agrega el hash del mensaje entre dominios a Message Queue de L2 (o L2MessageQueue), usando la función appendMessage. El contrato Message Queue de L2 se encarga del Withdraw Trie, que es un Merkle tree diseñado para almacenar los mensajes nuevos del Message Queue de L2. Cada vez que un nuevo mensaje es agregado a la cola, el contrato lo inserta dentro del withdraw trie y actualiza la root hash del trie.
Luego de que un lote de transacciones que contienen mensajes de L2 a L1 es finalizado en el contrato rollup L1, usuarios deben enviar las transacciones de ejecución de retiro para poder llamar a la función relayMessageWithProof en el contrato Scroll Messenger de L1 para poder ejecutar el retiro en L1. Gracias a las Pruebas Merkle, la finalización de las transacciones de reto es confiable y puede ser presentada por los propios usuarios o por un tercero en nombre de ellos.
Para simplificar el proceso de crear un “MIP” de Retiro (Prueba de Inclusión de Merkle) para Scroll, se tiene un servicio llamado Bridge History API. Esta API monitorea los eventos SentMessage generados por Scroll Messenger de L2 y mantiene un Trie de Retiros interno. Genera activamente pruebas de Merkle para todos los mensajes de retiro, asegurando una experiencia sin problemas para los usuarios y los servicios de terceros. Esto significa que cualquier persona, ya sea un usuario o un servicio de terceros, puede solicitar fácilmente pruebas de Merkle del Bridge History API para incluirlas en sus transacciones de Ejecución de Retiro.
Es importante destacar que estas transacciones de Ejecución de Retiro pueden ser iniciadas tanto por los propios usuarios como por servicios de terceros, lo que proporciona flexibilidad en la forma en que se procesan los retiros.
El Withdraw Trie es un árbol de Merkle binario compacto. En esta estructura, el hash de cada nodo hoja se deriva directamente del hash del mensaje, mientras que el hash de un nodo no hoja se calcula utilizando el resumen de hash de Keccak de los hashes concatenados de sus dos nodos hijos. La profundidad del Withdraw Trie se expande de manera dinámica según la cantidad de mensajes agregados al trie.
Por ejemplo la figura 6 muestra un ejemplo de un Trie de Retiros completo de 3 capas.
Sin embargo, existen casos en donde la cantidad de hojas no llena un árbol binario completo, por ellos se utilizan hashes de valor 0 para rellenar los nodos hoja, como se muestra a continuación:
Luego, cuando llega un nuevo mensaje, este se agrega a un Trie de Retiros incompleto reemplazando el hash de valor 0 por el nuevo hash para el nodo hoja.
De esa forma el arbol va creciendo y agregando nuevos hashes ceros que seran reemplazados por los hashes de las solicitudes de retiro que vayan realizandose en la chain.
Cuando un activo, ya sea, un token, un NFT o simplemente ETH, es depositado o retirado en Scroll, debe pasar por una serie de pasos previos para garantizar una correcta ejecución en Scroll.
Para manejar esto, se crearon una serie de “Gateways”, las cuales son utilizadas para cada tipo de activo que busque transferir entre las cadenas de Scroll y Ethereum. Para cada tipo de activo, existe una gateway especifica, por lo que se necesita guiar a estos activos por la gateway adecuada, este trabajo es responsabilidad del Gateway Router el cual revisa y selecciona el mapeo correspondiente para cada activo que se deposita o retira de Scroll.
Tal como se puede apreciar en la figura 9, a la hora de depositar fondos en Scroll, el usuario necesita enviar la solicitud de deposito al Gateway Router de L1(o L1GatewayRouter), el cual seleccionará la gateway adecuada dependiendo el tipo de activo a depositar. Es importante descatar que para los token de tipo ERC-721 o ERC-1155 no es necesario realizar una llamada al router, ya que Scroll ha configurado gateways especiales para este tipo de activos no fungibles.
Luego de seleccionar la gateway adecuada, esta crea un mensaje codificado que recibe el Scroll Messenger de L1, este mensaje es agregado a una fila de mensajes (Message Queue de L1) que son almacenados para ser escogidos por el secuenciador para ser agregados a la chain de Scroll.
El proceso es bastante simple, sin embargo, dependiendo del tipo de activo que se vaya a depositar pueden existir algunas diferencias.
Para Scroll, ETH es la moneda nativa para pagar las comisiones de la chain, por ello
existe una gran cantidad de ETH en el contrato del Scroll Messenger de L2 para que los usuarios puedan depositar en L1 y retirar en L2 sin la necesidad de emitir nuevos tokens.
El proceso es simple:
Primero se llama al contrato Gateway Router de L1.
Luego se selecciona la Gateway de ETH de L1 y se codifica el mensaje.
El contrato Scroll Messenger de L1 recibe este mensaje codificado y lo agrega al contrato de Message Queue de L1.
Despues que la transacción finalize en L1, el secuenciador incluira una transacción en un bloque en L2.
Esta transacción en L2 llamara a la función L2ScrollMessenger.relayMessage que a su vez llama a L2ETHGateway.finalizeDepositETH del contrato de la Gateway L2 de ETH(o L2ETHGateway) y de esa forma, finaliza el depósito en L2.
Antes de avanzar es importante mencionar que al igual que para el deposito de ETH, lo primero que se debe hacer es llamar al contrato Gateway Router de L1, luego base al mapping se seleccionara la Gateway correspondiente dependiendo si es un token ERC20, WETH o un Custom token. Esto es igual para estos 3 tipos de tokens.
Para los tokens ERC-20 Standard:
La Gateway L1 de ERC20 Standard(o L1StandardERC20Gateway) bloquea los tokens ERC-20 en L1 que seran depositados.
Si es la primera vez que el token ERC-20 se deposita, la Gateway L1 de ERC20 Standard computa una dirección para L2 y agrega toda la metadata del token (nombre, simbolo y decimales) en un mensaje para la “posible” creación de un nuevo contracto en L2.
En caso de que el token ERC-20 que se deposita ya tenga creada un dirección de contrato en L2 almacenada en tokenMapping, la Gateway L1 de ERC20 Standard directamente tomará esta dirección de contrato para emitir nuevos tokens en L2.
Luego de esto la Gateway L1 de ERC20 Standard crea el mensaje codificado y lo envia al Scroll Messenger de L1. Este a su vez lo incluye al contrato de Message Queue de L1.
Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2. Esta transaccíon llama a la función L2ScrollMessenger.relayMessage que a su vez llama a
Para custom ERC-20 tokens:
La Gateway L1 de Custom ERC20 tokens(o L1CustomERC20Gateway) bloquea los tokens en L1 que seran depositados.
La Gateway L1 de Custom ERC20 tokens requiere una dirección de token ERC20 L2 presente en tokenMapping. Esta función recupera la dirección de token ERC20 correspondiente, codifica el mensaje de depósito de token y lo reenvía a Scroll Messenger de L1. Este a su vez lo incluye al contrato de Message Queue de L1.
Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2
Esta transacción llama a L2ScrollMessenger.relayMessage que a su vez llama a L2CustomERC20Gateway.finalizeDepositERC20 de la Gateway L2 de Custom ERC20 tokens(o L2CustomERC20Gateway) para finalizar el depósito.
Es importante destacar que la Gateway L2 de Custom ERC20 tokens llamara a la función mint del contrato del custom token en L2, por lo que este último debera concederle permisos para emitir tokens al contrato de la Gateway L2 de Custom ERC20 tokens.
Para WETH:
La Gateway L1 de WETH(o L1WETHGateway) bloquea los tokens en L1 que seran depositados transfiriendo del remitente a sí mismo y “desenvolviendo el WETH”, es decir convertiendo el token de WETH a ETH nativo.
Luego, este token ETH nativo y msg.value se envian juntos al mediante un mensaje codificado que se le envia a Scroll Messenger de L1. Este último, lo incluye al contrato de Message Queue de L1.
Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2
La transacción L2 correspondiente llama a la función L2ScrollMessenger.relayMessage que a su vez llama a L2WETHGateway.finalizeDepositERC20 de la Gateway L2 de WETH(o L2WETHGateway) para finalizar el depósito.
Una vez realizado esto la Gateway L2 de WETH vuelve a “envolver” de nuevo el token
El depósito de este tipo de tokens funciona de manera similar a los tokens de tipo ERC-20, sin embargo, tal y como se muestra en la figura 9, los usuarios pueden acceder a las Gateways L1 de ERC-721/ERC-1155 directamente sin la necesidad de depender de la Gateway Router de L1.
Con el objetivo de facilitar el deposito de tokens ERC-721 o ERC-1155, la Gateway L1 de ERC721 y la Gateway L1 de ERC1155 tienen implementadas una función que permite depositar por lotes (o batches) varios tokens al mismo tiempo.
Para la finalización del depósito se utilizan la Gateway L2 de ERC721 y la Gateway L2 de ERC1155, con los mismo comandos como en el caso de un ERC-20.
La figura 10 muestra el flujo de trabajo desde L2 a L1 en donde los usuarios pueden llamar a las diferentes Gateways disponibles para iniciar el retiro de fondos. El retiro de fondo se codifica en un mensaje que recibe el Scroll Messenger de L2(o y que luego es agregado al Message Queue de L2. Este último componente mantiene una Withdraw Trie root que es actualizado cada vez que un nuevo mensaje es incluido.
La Withdraw Trie root final, junto con la state root del estado L2, se confirma en el contrato de rollup de L1. Una vez que la nueva Withdraw Trie root se finaliza en L1, los usuarios o terceros pueden generar una Prueba de Inclusión Merkle válida para la Withdraw Trie root y ejecutar una transacción de retiro en L1.
Al igual que para los depósitos, el proceso para los retiros puede variar dependiendo del tipo de activo que se vaya a retirar.
Se llama a la Gateway Router de L2, luego se secciona la Gateway adecuada (en este caso la Gateway L2 de ETH).
La Gateway L2 de ETH crea el mensaje codificado y lo envia al Scroll Messenger de L2, el cual bloquea el ETH a retirar en su contrato. Luego, este último agrega un mensaje al Message Queue de L2.
La ejecución de la transaccion de retiro en L1 llama a la función L1ScrollMessenger.relayMessageWithProof para finalizar el retiro. En el caso de retiro de ETH la función relayMessageWithProof llama a la función L1ETHGateway.finalizeWithdrawETH y envia el ETH a la dirección del destinatario en L1.
Para este caso lo primero que se hace es llamar al contrato de la Gateway Router de L2 el cual llamará a la Gateway correspondiente.
Para ERC-20 Standard y Custom ERC-20tokens:
La Gateway Router de L2 llama a la Gateway correspondiente segun activo (sea ERC20 Standard o Custom ERC20)
Los contratos de las Gateways L2 de ERC20 Standard o Custom ERC20 queman, según el activo, la cantidad de token ERC20 a retirar y al mismo tiempo generan un mensaje codificado, el cual es enviado al Scroll Messenger de L2.
La ejecución del retiro en L1 llama a la función L1ScrollMessenger.relayMessageWithProof para finalizar el retiro en L1. En el caso de un token ERC20 Standard o Custom, la transacción llama a la función finalizeWithdrawERC20 de Gateway L1 de ERC20 Standard o L1CustomERC20Gateway respectivamente.
En el contrato de Gateway L1 de ERC20 Standard, si se trata de la primera transacción de retirada de un token ERC20, la función finalizeWithdrawERC20 actualizará la mapping de la dirección del token L1 a su dirección del token L2 en el tokenMapping.
Finalmente, la Gateway L1 de ERC20 Standard
Para WETH:
La Gateway Router de L2 llama a la Gateway L2 de WETH.
Luego, la Gateway L2 de WETH se transfiere los WETH asi mismo y los “desenvuelve” convirtiendolos en ETH nativo que son transferidos al Scroll messenger de L2 junto con un mensaje codificado.
La ejecución del retiro en L1 llama a la función L1ScrollMessenger.relayMessageWithProof para finalizar el retiro en L1. Para el caso de WETH, la transacción llama a L1WETHGateway.finalizeWithdrawERC20 y envia este monto en ETH a la Gateway L1 de WETH.
Finalmente, la Gateway L1 de WETH vuelve a convertir los ETH a WETH y los envia a dirección del destinatario en L1.
El retiro de este tipo de tokens funciona de manera similar a los tokens de tipo ERC-20, sin embargo, tal y como se muestra en la figura 10, los usuarios pueden acceder a las Gateways L1 de ERC-721/ERC-1155 directamente sin la necesidad de depender de la Gateway Router de L2.
Al igual que en el caso de los depositos, la Gateway L2 de ERC721 y la Gateway L2 de ERC1155 tienen implementadas una función que permite depositar por lotes (o batches) varios tokens al mismo tiempo.
Para la finalización del depósito se utilizan la Gateway L1 de ERC721 y la Gateway L1 de ERC1155, con los mismos comandos como en el caso de un ERC-20.
La arquitectura del puente de Scroll brinda la capacidad de transferir activos entre las capas L1 y L2. A través de mensajes entre dominio, Scroll facilita la comunicación entre L1 y L2 para las Dapps, lo que simplifica la interacción entre contratos y la transferencia de tokens.
Los procesos de envío de mensajes y transacciones, tanto de L1 a L2 como de L2 a L1, implican una serie de contratos y pasos, que incluyen la codificación de mensajes, la gestión de gateways de tokens y la ejecución de transacciones.
Lo notable del puente de Scroll es su versatilidad, ya que no se limita a un solo tipo de token. Puede manejar diversos tipos de activos, como ETH, tokens ERC-20 Standard, Custom tokens y tokens ERC-721/ERC-1155. Cada uno de estos activos tiene su propio flujo de trabajo y procesos de depósito/retiro, que incluye la selección de gateways adecuadas, así como también un mecanismo para forzar transacciones en caso de que el secuenciador falle o actúe maliciosamente.
Indudablemente, Scroll ha desarrollado una sólida y altamente adaptable arquitectura de puente que permite a los usuarios transferir activos de manera eficiente entre diferentes capas de la cadena. Esta arquitectura aporta flexibilidad y facilidad de uso, aspectos esenciales en el creciente ecosistema Web3. La tecnología de Scroll desempeña un papel crucial en la facilitación de la interoperabilidad en este entorno y se posiciona como una valiosa solución para la comunidad blockchain.
Bridge (Puente): Un sistema que permite la transferencia de activos entre dos blockchains o cadenas de bloques.
Web3: Un término que se refiere a la tercera generación de la web, que se centra en la descentralización y la interoperabilidad de las aplicaciones y activos en línea.
Tokens: Representaciones digitales de activos o valores, como criptomonedas.
Mensaje (Message): Una comunicación digital que se envía de un lugar a otro, en este contexto, un mensaje puede ser una solicitud para transferir activos.
Blockchain: Cadena de bloques, una tecnología de registro distribuido utilizada para almacenar transacciones de forma segura y transparente.
Envueltos (Wrapped): Tokens que representan otro activo y pueden circular en diferentes blockchains.
L1 y L2 (Capas 1 y 2): Capas de una solución de escalabilidad en la cadena de bloques, donde L1 se refiere a la cadena principal y L2 a una capa secundaria.
Sender (Remitente): La entidad que inicia una transacción o mensaje.
Gateways (Pasarelas): Plataformas o contratos inteligentes que facilitan el depósito o retiro de activos entre diferentes blockchains.
Fee (Tarifa): El costo asociado con una transacción en una cadena de bloques.
Alias de Dirección: Una dirección alternativa utilizada para mejorar la seguridad y evitar abusos.
Merkle Tree (Árbol de Merkle): Una estructura de datos utilizada para verificar la integridad de los datos en una cadena de bloques.
🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad te invitamos a revisar nuestra biblioteca de Layer 2 en español.
Por otro lado, te invitamos a leer sobre nuestra guía de como correr un Full Nodes usando Arbitrum Nitro 👇👇👇
https://mirror.xyz/layer2es.eth/J_kUr6roi4IVEuZXT44rfxO8L9n-yBZpPkOadrElPtw
Si quieren seguir aprendiendo y colaborando con nosotros, le invitamos a unirse a nuestra vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!
Gateway L2 de ERC20 StandardEn el caso de que el token ERC-20 a depositar no tenga una direccion de contrato en L2, la Gateway L2 de ERC20 Standard, extraerá la metadata construida en el paso 2 y llamara a la función ScrollStandardERC20Factory para crear una nueva dirección de contrato en L2.
La misma Gateway L2 de ERC20 Standard se encarga de usar la función mint para emitir nuevos tokens y se los enviara la dirección de destino.
Trie: Una estructura de datos en forma de árbol utilizada en la cadena de bloques para almacenar información.
Depósito (Deposit): La acción de transferir activos a una cadena de bloques.
Retiro (Withdrawal): La acción de transferir activos fuera de una cadena de bloques.
ETH (Ether): La criptomoneda nativa de la plataforma Ethereum.
ERC-20, ERC-721, ERC-1155: Estándares de tokens en la plataforma Ethereum.
Hash: Un valor único generado a partir de datos, utilizado para verificar la integridad de la información.
Batch (Lote): Un grupo de transacciones o activos que se procesan juntos.
Gateway Router (Enrutador de Pasarela): Un componente que selecciona la pasarela adecuada para procesar una transacción.
Custom Token (Token Personalizado): Un token no estándar, diseñado de forma única.
WETH (Wrapped Ether): Ether envuelto, una representación de Ether que se puede utilizar en contratos inteligentes.
En el ecosistema Web3, la función de un bridge (aka puente) puede parecer sencilla a primera vista: facilitar la transferencia de tokens de una cadena a otra. Sin embargo, la realidad es mucho más intrigante y compleja. En su esencia, los bridges son el medio en el que se transmiten mensajes, como por ejemplo, un mensaje que implica la congelación del activo que deseas transferir a una blockchain y, como resultado, emiten tokens equivalentes en la cadena de destino. Estos tokens equivalentes, a menudo denominados "envueltos" o "wrapped," representan la criptomoneda o el token original, pero cuentan con la versatilidad de circular y utilizarse en diferentes blockchains. Por ejemplo, cuando deseas transferir Ethereum a la blockchain de Scroll, el bridge se encarga de inmovilizar el Ethereum original y, a cambio, emite tokens equivalentes en blockchain de Scroll.
En este artículo, nos sumergiremos en la forma en que Scroll aprovecha el poder de su bridge para facilitar la transferencia de activos entre L1 y L2 (capas 1 y 2) y viceversa. Además, exploraremos las implicaciones y las características únicas que distinguen a Scroll en este aspecto.
Mensajes entre Dominios L1 y L2.
Envío de mensajes de L1 a L2.
Proceso de Envío de Mensajes y Transacciones.
Envío de Mensajes Arbitrarios.
Envío de Transacciones Forzadas.
Reintento de Mensajes Fallidos.
Tarifa de Retransmisión de Mensajes.
Alias de Dirección.
Envío de mensajes de L2 a L1.
Withdraw Trie.
Gateways de tokens.
Gateways de depósito
Caso 1: Deposito de ETH.
Caso 2: Depositos de tokens ERC-20 Stardard / Custom ERC-20 / WETH.
Caso 3: Deposito de tokens ERC-721/ERC-1155.
Gateways de Retiro.
Caso 1: Retiro de ETH.
Caso 2: Retiro de tokens ERC-20/Custom tokens/WETH.
Caso 3: Deposito de tokens ERC-721/ERC-1155.
Conclusión.
Glosario.
En Scroll los usuarios tienen la posibilidad de usar un puente para mensajes arbitrarios que permite la transferencia de tokens y a su vez deja a las que dapps puedan comunicarse entre L1 y L2. Por consecuencia, esto significa que una Dapps en L1 puede activar funciones de un contrato en L2 y viceversa.
Tal como se observa en la figura, existen dos enfoques principales a la hora de interactuar desde L1 a L2: el envío de mensajes arbitrarios a través de Scroll Messenger de L1 (o L1ScrollMessenger) y el envío de transacciones forzadas mediante la Gateway para transacciones forzadas (o EnforcedTxGateway). Ambos métodos permiten a los usuarios iniciar una transacción desde L1 a L2 o interactuar con contratos desplegados en L2 desde L1.
Para los mensajes arbitrarios, el sender en L2 es la dirección del Scroll Messenger de L1 con alias. Por otro lado, para las transacciones forzadas, el sender (o remitente en español) en L2 es una cuenta de propiedad externa (EOA). Además, se proporcionan varias Gateways para facilitar el depósito de ETH y conocidos estándares de tokens, tales como ERC-20, ERC-677, ERC-721 y ERC-1155.
En la Figura 1, tanto los mensajes arbitrarios como las transacciones forzadas se agregan a la cola de mensajes en el contrato Message Queue de L1 (o L1MessageQueue). Este contrato ofrece dos funciones clave: appendCrossDomainMessage y appendEnforcedTransaction para agregar mensajes arbitrarios y transacciones forzadas, respectivamente.
appendCrossDomainMessage: permite agregar mensajes iniciados por L1, utilizando la dirección de alias de Scroll Messenger de L1 como sender.
appendEnforcedTransaction solo puede ser llamada por EnforcedTxGateway y utiliza el sender especificado en el parámetro de función como remitente de la transacción. Esto permite a los usuarios ejecutar un retiro o transferencia de ETH desde sus cuentas L2 directamente a través del bridge L1.
Después de que una transacción se ejecute con éxito en L1, el watcher en el secuenciador de Scroll monitorea el contrato Message Queue de L1 y recopila nuevos eventos llamados QueueTransaction. Estos eventos son utilizados por el secuenciador para construir una nueva transacción L1MessageTx, que luego se agrega a su cola de transacciones L1 local.
Las transacciones L1MessageTx siempre aparecen primero en los bloques L2, seguidas de las transacciones L2.
La dirección del contrato Scroll Messenger de L1 proporciona dos funciones sendMessage para enviar mensajes arbitrarios. La diferencia principal entre ellas es que la segunda permite a los usuarios especificar una dirección de reembolso para recibir el exceso de gas.
A nivel de código las 2 funciones se ven de la siguiente manera:
Ambas funciones requieren que los usuarios proporcionen un límite de gas y paguen el fee de retransmisión por adelantado en L1. Los detalles se codifican en un mensaje entre dominios, y luego se utilizan como datos de llamada en la transacción L1MessageTx en L2.
El contrato EnforcedTxGateway ofrece dos funciones sendTransaction para enviar transacciones forzadas. La diferencia clave radica en quién es el remitente de la transacción en L2: el remitente de la transacción o la dirección especificada. Esto permite a un tercero enviar una transacción forzada en nombre del usuario y pagar la tasa 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 remitente.
Ambas funciones exigen que el remitente sea una cuenta EOA y la tarifa de retransmisión se deduzca de la cuenta L1. El valor pasado a la función indica la cantidad de ETH que se transferirá desde la cuenta del remitente en L2, no en L1.
Si una transacción L1MessageTx falla en L2 debido a la falta de gas, los usuarios pueden reintentar con un límite de gas más alto utilizando la función replayMessage del contrato Scroll Messenger de L1. Este mensaje se convertirá en un nuevo L1MessageTx en L2. Tenga en cuenta que no se reembolsará la tarifa del gas por la transacción fallida anterior, por que ya está procesada en L2.
La tarifa de retransmisión de mensajes L1 a L2 se calcula en función del límite de gas y se almacena en la dirección del contrato L2GasPriceOracle (o Oráculo de gas en L2) Esta tarifa se deduce de la cuenta L1 y es igual a gasLimit * l2BaseFee.
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 alias de dirección cuando el emisor del mensaje es un contrato en L1. La dirección del remitente alias de la transacción del mensaje en L1 es l1_contract_address + offset, donde el offset es 0x1111000000000000000000000000000000001111.
En la Capa 2 (L2), los usuarios tienen la capacidad de enviar mensajes arbitrarios utilizando el Scroll Messenger de L2 (o L2ScrollMessenger) para facilitar la retirada de tokens e interactuar con los contratos desplegados en la Capa 1 (L1). Al igual que en L1, Scroll ha desarrollado diversas Gateways de Tokens estándar para simplificar el proceso de inicio de retiros.
Adicionalmente, el contratoScroll Messenger de L2 incluye una función denominada sendMessage. Es importante destacar que esta función difiere de L1ScrollMessenger.sendMessage, ya que no toma en cuenta el parámetro gasLimit. Esto se debe a que, al iniciarse la transacción de ejecución para el retiro en L1, las comisiones de transacción se pagan directamente en L1.
Como resultado, la función sendMessage requiere que la función msg.value coincida con el value especificado en el parámetro. La función codifica los argumentos en un mensaje entre dominios siguiendo el mismo esquema que utiliza Scroll Messenger de L1.
A nivel de código, se veria de la siguiente manera:
Luego, se agrega el hash del mensaje entre dominios a Message Queue de L2 (o L2MessageQueue), usando la función appendMessage. El contrato Message Queue de L2 se encarga del Withdraw Trie, que es un Merkle tree diseñado para almacenar los mensajes nuevos del Message Queue de L2. Cada vez que un nuevo mensaje es agregado a la cola, el contrato lo inserta dentro del withdraw trie y actualiza la root hash del trie.
Luego de que un lote de transacciones que contienen mensajes de L2 a L1 es finalizado en el contrato rollup L1, usuarios deben enviar las transacciones de ejecución de retiro para poder llamar a la función relayMessageWithProof en el contrato Scroll Messenger de L1 para poder ejecutar el retiro en L1. Gracias a las Pruebas Merkle, la finalización de las transacciones de reto es confiable y puede ser presentada por los propios usuarios o por un tercero en nombre de ellos.
Para simplificar el proceso de crear un “MIP” de Retiro (Prueba de Inclusión de Merkle) para Scroll, se tiene un servicio llamado Bridge History API. Esta API monitorea los eventos SentMessage generados por Scroll Messenger de L2 y mantiene un Trie de Retiros interno. Genera activamente pruebas de Merkle para todos los mensajes de retiro, asegurando una experiencia sin problemas para los usuarios y los servicios de terceros. Esto significa que cualquier persona, ya sea un usuario o un servicio de terceros, puede solicitar fácilmente pruebas de Merkle del Bridge History API para incluirlas en sus transacciones de Ejecución de Retiro.
Es importante destacar que estas transacciones de Ejecución de Retiro pueden ser iniciadas tanto por los propios usuarios como por servicios de terceros, lo que proporciona flexibilidad en la forma en que se procesan los retiros.
El Withdraw Trie es un árbol de Merkle binario compacto. En esta estructura, el hash de cada nodo hoja se deriva directamente del hash del mensaje, mientras que el hash de un nodo no hoja se calcula utilizando el resumen de hash de Keccak de los hashes concatenados de sus dos nodos hijos. La profundidad del Withdraw Trie se expande de manera dinámica según la cantidad de mensajes agregados al trie.
Por ejemplo la figura 6 muestra un ejemplo de un Trie de Retiros completo de 3 capas.
Sin embargo, existen casos en donde la cantidad de hojas no llena un árbol binario completo, por ellos se utilizan hashes de valor 0 para rellenar los nodos hoja, como se muestra a continuación:
Luego, cuando llega un nuevo mensaje, este se agrega a un Trie de Retiros incompleto reemplazando el hash de valor 0 por el nuevo hash para el nodo hoja.
De esa forma el arbol va creciendo y agregando nuevos hashes ceros que seran reemplazados por los hashes de las solicitudes de retiro que vayan realizandose en la chain.
Cuando un activo, ya sea, un token, un NFT o simplemente ETH, es depositado o retirado en Scroll, debe pasar por una serie de pasos previos para garantizar una correcta ejecución en Scroll.
Para manejar esto, se crearon una serie de “Gateways”, las cuales son utilizadas para cada tipo de activo que busque transferir entre las cadenas de Scroll y Ethereum. Para cada tipo de activo, existe una gateway especifica, por lo que se necesita guiar a estos activos por la gateway adecuada, este trabajo es responsabilidad del Gateway Router el cual revisa y selecciona el mapeo correspondiente para cada activo que se deposita o retira de Scroll.
Tal como se puede apreciar en la figura 9, a la hora de depositar fondos en Scroll, el usuario necesita enviar la solicitud de deposito al Gateway Router de L1(o L1GatewayRouter), el cual seleccionará la gateway adecuada dependiendo el tipo de activo a depositar. Es importante descatar que para los token de tipo ERC-721 o ERC-1155 no es necesario realizar una llamada al router, ya que Scroll ha configurado gateways especiales para este tipo de activos no fungibles.
Luego de seleccionar la gateway adecuada, esta crea un mensaje codificado que recibe el Scroll Messenger de L1, este mensaje es agregado a una fila de mensajes (Message Queue de L1) que son almacenados para ser escogidos por el secuenciador para ser agregados a la chain de Scroll.
El proceso es bastante simple, sin embargo, dependiendo del tipo de activo que se vaya a depositar pueden existir algunas diferencias.
Para Scroll, ETH es la moneda nativa para pagar las comisiones de la chain, por ello
existe una gran cantidad de ETH en el contrato del Scroll Messenger de L2 para que los usuarios puedan depositar en L1 y retirar en L2 sin la necesidad de emitir nuevos tokens.
El proceso es simple:
Primero se llama al contrato Gateway Router de L1.
Luego se selecciona la Gateway de ETH de L1 y se codifica el mensaje.
El contrato Scroll Messenger de L1 recibe este mensaje codificado y lo agrega al contrato de Message Queue de L1.
Despues que la transacción finalize en L1, el secuenciador incluira una transacción en un bloque en L2.
Esta transacción en L2 llamara a la función L2ScrollMessenger.relayMessage que a su vez llama a L2ETHGateway.finalizeDepositETH del contrato de la Gateway L2 de ETH(o L2ETHGateway) y de esa forma, finaliza el depósito en L2.
Antes de avanzar es importante mencionar que al igual que para el deposito de ETH, lo primero que se debe hacer es llamar al contrato Gateway Router de L1, luego base al mapping se seleccionara la Gateway correspondiente dependiendo si es un token ERC20, WETH o un Custom token. Esto es igual para estos 3 tipos de tokens.
Para los tokens ERC-20 Standard:
La Gateway L1 de ERC20 Standard(o L1StandardERC20Gateway) bloquea los tokens ERC-20 en L1 que seran depositados.
Si es la primera vez que el token ERC-20 se deposita, la Gateway L1 de ERC20 Standard computa una dirección para L2 y agrega toda la metadata del token (nombre, simbolo y decimales) en un mensaje para la “posible” creación de un nuevo contracto en L2.
En caso de que el token ERC-20 que se deposita ya tenga creada un dirección de contrato en L2 almacenada en tokenMapping, la Gateway L1 de ERC20 Standard directamente tomará esta dirección de contrato para emitir nuevos tokens en L2.
Luego de esto la Gateway L1 de ERC20 Standard crea el mensaje codificado y lo envia al Scroll Messenger de L1. Este a su vez lo incluye al contrato de Message Queue de L1.
Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2. Esta transaccíon llama a la función L2ScrollMessenger.relayMessage que a su vez llama a L2StandardERC20Gateway.finalizeDepositERC20 de la Gateway L2 de ERC20 Standard(o L2StandardERC20Gateway) para finalizar el depósito en L2.
En el caso de que el token ERC-20 a depositar no tenga una direccion de contrato en L2, la Gateway L2 de ERC20 Standard, extraerá la metadata construida en el paso 2 y llamara a la función ScrollStandardERC20Factory para crear una nueva dirección de contrato en L2.
La misma Gateway L2 de ERC20 Standard se encarga de usar la función mint para emitir nuevos tokens y se los enviara la dirección de destino.
Para custom ERC-20 tokens:
La Gateway L1 de Custom ERC20 tokens(o L1CustomERC20Gateway) bloquea los tokens en L1 que seran depositados.
La Gateway L1 de Custom ERC20 tokens requiere una dirección de token ERC20 L2 presente en tokenMapping. Esta función recupera la dirección de token ERC20 correspondiente, codifica el mensaje de depósito de token y lo reenvía a Scroll Messenger de L1. Este a su vez lo incluye al contrato de Message Queue de L1.
Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2
Esta transacción llama a L2ScrollMessenger.relayMessage que a su vez llama a L2CustomERC20Gateway.finalizeDepositERC20 de la Gateway L2 de Custom ERC20 tokens(o L2CustomERC20Gateway) para finalizar el depósito.
Es importante destacar que la Gateway L2 de Custom ERC20 tokens llamara a la función mint del contrato del custom token en L2, por lo que este último debera concederle permisos para emitir tokens al contrato de la Gateway L2 de Custom ERC20 tokens.
Para WETH:
La Gateway L1 de WETH(o L1WETHGateway) bloquea los tokens en L1 que seran depositados transfiriendo del remitente a sí mismo y “desenvolviendo el WETH”, es decir convertiendo el token de WETH a ETH nativo.
Luego, este token ETH nativo y msg.value se envian juntos al mediante un mensaje codificado que se le envia a Scroll Messenger de L1. Este último, lo incluye al contrato de Message Queue de L1.
Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2
La transacción L2 correspondiente llama a la función L2ScrollMessenger.relayMessage que a su vez llama a L2WETHGateway.finalizeDepositERC20 de la Gateway L2 de WETH(o L2WETHGateway) para finalizar el depósito.
Una vez realizado esto la Gateway L2 de WETH vuelve a “envolver” de nuevo el token ETH depositado en L2, lo convierte a WETH y lo transfiere a la dirección del destinatario en L2.
El depósito de este tipo de tokens funciona de manera similar a los tokens de tipo ERC-20, sin embargo, tal y como se muestra en la figura 9, los usuarios pueden acceder a las Gateways L1 de ERC-721/ERC-1155 directamente sin la necesidad de depender de la Gateway Router de L1.
Con el objetivo de facilitar el deposito de tokens ERC-721 o ERC-1155, la Gateway L1 de ERC721 y la Gateway L1 de ERC1155 tienen implementadas una función que permite depositar por lotes (o batches) varios tokens al mismo tiempo.
Para la finalización del depósito se utilizan la Gateway L2 de ERC721 y la Gateway L2 de ERC1155, con los mismo comandos como en el caso de un ERC-20.
La figura 10 muestra el flujo de trabajo desde L2 a L1 en donde los usuarios pueden llamar a las diferentes Gateways disponibles para iniciar el retiro de fondos. El retiro de fondo se codifica en un mensaje que recibe el Scroll Messenger de L2(o y que luego es agregado al Message Queue de L2. Este último componente mantiene una Withdraw Trie root que es actualizado cada vez que un nuevo mensaje es incluido.
La Withdraw Trie root final, junto con la state root del estado L2, se confirma en el contrato de rollup de L1. Una vez que la nueva Withdraw Trie root se finaliza en L1, los usuarios o terceros pueden generar una Prueba de Inclusión Merkle válida para la Withdraw Trie root y ejecutar una transacción de retiro en L1.
Al igual que para los depósitos, el proceso para los retiros puede variar dependiendo del tipo de activo que se vaya a retirar.
Se llama a la Gateway Router de L2, luego se secciona la Gateway adecuada (en este caso la Gateway L2 de ETH).
La Gateway L2 de ETH crea el mensaje codificado y lo envia al Scroll Messenger de L2, el cual bloquea el ETH a retirar en su contrato. Luego, este último agrega un mensaje al Message Queue de L2.
La ejecución de la transaccion de retiro en L1 llama a la función L1ScrollMessenger.relayMessageWithProof para finalizar el retiro. En el caso de retiro de ETH la función relayMessageWithProof llama a la función L1ETHGateway.finalizeWithdrawETH y envia el ETH a la dirección del destinatario en L1.
Para este caso lo primero que se hace es llamar al contrato de la Gateway Router de L2 el cual llamará a la Gateway correspondiente.
Para ERC-20 Standard y Custom ERC-20tokens:
La Gateway Router de L2 llama a la Gateway correspondiente segun activo (sea ERC20 Standard o Custom ERC20)
Los contratos de las Gateways L2 de ERC20 Standard o Custom ERC20 queman, según el activo, la cantidad de token ERC20 a retirar y al mismo tiempo generan un mensaje codificado, el cual es enviado al Scroll Messenger de L2.
La ejecución del retiro en L1 llama a la función L1ScrollMessenger.relayMessageWithProof para finalizar el retiro en L1. En el caso de un token ERC20 Standard o Custom, la transacción llama a la función finalizeWithdrawERC20 de Gateway L1 de ERC20 Standard o L1CustomERC20Gateway respectivamente.
En el contrato de Gateway L1 de ERC20 Standard, si se trata de la primera transacción de retirada de un token ERC20, la función finalizeWithdrawERC20 actualizará la mapping de la dirección del token L1 a su dirección del token L2 en el tokenMapping.
Finalmente, la Gateway L1 de ERC20 Standard libera los tokens ERC20 bloqueados transfiriéndolos desde sí misma a la dirección del destinatario en L1.
Para WETH:
La Gateway Router de L2 llama a la Gateway L2 de WETH.
Luego, la Gateway L2 de WETH se transfiere los WETH asi mismo y los “desenvuelve” convirtiendolos en ETH nativo que son transferidos al Scroll messenger de L2 junto con un mensaje codificado.
La ejecución del retiro en L1 llama a la función L1ScrollMessenger.relayMessageWithProof para finalizar el retiro en L1. Para el caso de WETH, la transacción llama a L1WETHGateway.finalizeWithdrawERC20 y envia este monto en ETH a la Gateway L1 de WETH.
Finalmente, la Gateway L1 de WETH vuelve a convertir los ETH a WETH y los envia a dirección del destinatario en L1.
El retiro de este tipo de tokens funciona de manera similar a los tokens de tipo ERC-20, sin embargo, tal y como se muestra en la figura 10, los usuarios pueden acceder a las Gateways L1 de ERC-721/ERC-1155 directamente sin la necesidad de depender de la Gateway Router de L2.
Al igual que en el caso de los depositos, la Gateway L2 de ERC721 y la Gateway L2 de ERC1155 tienen implementadas una función que permite depositar por lotes (o batches) varios tokens al mismo tiempo.
Para la finalización del depósito se utilizan la Gateway L1 de ERC721 y la Gateway L1 de ERC1155, con los mismos comandos como en el caso de un ERC-20.
La arquitectura del puente de Scroll brinda la capacidad de transferir activos entre las capas L1 y L2. A través de mensajes entre dominio, Scroll facilita la comunicación entre L1 y L2 para las Dapps, lo que simplifica la interacción entre contratos y la transferencia de tokens.
Los procesos de envío de mensajes y transacciones, tanto de L1 a L2 como de L2 a L1, implican una serie de contratos y pasos, que incluyen la codificación de mensajes, la gestión de gateways de tokens y la ejecución de transacciones.
Lo notable del puente de Scroll es su versatilidad, ya que no se limita a un solo tipo de token. Puede manejar diversos tipos de activos, como ETH, tokens ERC-20 Standard, Custom tokens y tokens ERC-721/ERC-1155. Cada uno de estos activos tiene su propio flujo de trabajo y procesos de depósito/retiro, que incluye la selección de gateways adecuadas, así como también un mecanismo para forzar transacciones en caso de que el secuenciador falle o actúe maliciosamente.
Indudablemente, Scroll ha desarrollado una sólida y altamente adaptable arquitectura de puente que permite a los usuarios transferir activos de manera eficiente entre diferentes capas de la cadena. Esta arquitectura aporta flexibilidad y facilidad de uso, aspectos esenciales en el creciente ecosistema Web3. La tecnología de Scroll desempeña un papel crucial en la facilitación de la interoperabilidad en este entorno y se posiciona como una valiosa solución para la comunidad blockchain.
Bridge (Puente): Un sistema que permite la transferencia de activos entre dos blockchains o cadenas de bloques.
Web3: Un término que se refiere a la tercera generación de la web, que se centra en la descentralización y la interoperabilidad de las aplicaciones y activos en línea.
Tokens: Representaciones digitales de activos o valores, como criptomonedas.
Mensaje (Message): Una comunicación digital que se envía de un lugar a otro, en este contexto, un mensaje puede ser una solicitud para transferir activos.
Blockchain: Cadena de bloques, una tecnología de registro distribuido utilizada para almacenar transacciones de forma segura y transparente.
Envueltos (Wrapped): Tokens que representan otro activo y pueden circular en diferentes blockchains.
L1 y L2 (Capas 1 y 2): Capas de una solución de escalabilidad en la cadena de bloques, donde L1 se refiere a la cadena principal y L2 a una capa secundaria.
Sender (Remitente): La entidad que inicia una transacción o mensaje.
Gateways (Pasarelas): Plataformas o contratos inteligentes que facilitan el depósito o retiro de activos entre diferentes blockchains.
Fee (Tarifa): El costo asociado con una transacción en una cadena de bloques.
Alias de Dirección: Una dirección alternativa utilizada para mejorar la seguridad y evitar abusos.
Merkle Tree (Árbol de Merkle): Una estructura de datos utilizada para verificar la integridad de los datos en una cadena de bloques.
Trie: Una estructura de datos en forma de árbol utilizada en la cadena de bloques para almacenar información.
Depósito (Deposit): La acción de transferir activos a una cadena de bloques.
Retiro (Withdrawal): La acción de transferir activos fuera de una cadena de bloques.
ETH (Ether): La criptomoneda nativa de la plataforma Ethereum.
ERC-20, ERC-721, ERC-1155: Estándares de tokens en la plataforma Ethereum.
Hash: Un valor único generado a partir de datos, utilizado para verificar la integridad de la información.
Batch (Lote): Un grupo de transacciones o activos que se procesan juntos.
Gateway Router (Enrutador de Pasarela): Un componente que selecciona la pasarela adecuada para procesar una transacción.
Custom Token (Token Personalizado): Un token no estándar, diseñado de forma única.
WETH (Wrapped Ether): Ether envuelto, una representación de Ether que se puede utilizar en contratos inteligentes.
🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad te invitamos a revisar nuestra biblioteca de Layer 2 en español.
Por otro lado, te invitamos a leer sobre nuestra guía de como correr un Full Nodes usando Arbitrum Nitro 👇👇👇
https://mirror.xyz/layer2es.eth/J_kUr6roi4IVEuZXT44rfxO8L9n-yBZpPkOadrElPtw
Si quieren seguir aprendiendo y colaborando con nosotros, le invitamos a unirse a nuestra vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!
L2 en EspañolIntroducción a la Data Availability
📌IntroducciónUno de los conceptos que más se repiten en la industria cripto es “trustless”, lo cual significa en esencia que no debes confiar en nadie sin validarlo primero. Es por esto que las blockchains poseen nodos completos, los cuales descargan y ejecutan la data que proporcionan los “bloques” (blocks en inglés) y se aseguran que los cálculos propuestos por el block producer coinciden precisamente con los cálculos hechos por el validador. De esta manera, los nodos verifican que esta nu...
L2 en EspañolIntroducción al Optimistic Rollup de Arbitrum
🔵IntroducciónEl Optimistic Rollup de Arbitrum es una solución de capa 2 diseñada para abordar los desafíos de escalabilidad de la red Ethereum. Arbitrum ofrece una forma más rápida y económica de realizar transacciones en Ethereum al aprovechar la técnica de los Optimistic Rollups. En este sistema, la mayoría de las operaciones se realizan fuera de la cadena principal (es decir fuera de mainnet ó off-chain), lo que permite aumentar la eficiencia y reducir los costos. En este artículo, explic...
L2 en EspañolArbitrum Nitro: Guía para correr un full node
IntroducciónLos Rollups, al igual que cualquier blockchain, operan en función de un nodo completo. En una blockchain de capa 1, el nodo completo representa la unidad fundamental que impulsa la seguridad y descentralización de la red. Para el usuario individual, proporciona accesibilidad, soberanía y privacidad al interactuar con la red. En un Optimistic Rollup completamente funcional, la noción de un "nodo completo" no ofrece el mismo nivel de beneficios desde la perspectiva de la red, debido...
Comunidad dedicada al estudio de soluciones de escalabilidad en Ethereum. Impulsado y administrado por DeFi para Principiantes y SEED Latam.
Share Dialog
Share Dialog
Subscribe to L2 en Español
Subscribe to L2 en Español
<100 subscribers
<100 subscribers
No activity yet