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.

📝Índice

1. Mensajes entre Dominios L1 y L2.

   1. Envío de mensajes de L1 a L2.

   2. Proceso de Envío de Mensajes y Transacciones.

   3. Envío de Mensajes Arbitrarios.

   4. Envío de Transacciones Forzadas.

   5. Reintento de Mensajes Fallidos.

   6. Tarifa de Retransmisión de Mensajes.

   7. Alias de Dirección.

   8. Envío de mensajes de L2 a L1.

   9. Withdraw Trie.

2. Gateways de tokens.

   1. Gateways de depósito

      1. Caso 1: Deposito de ETH.

      2. Caso 2: Depositos de tokens ERC-20 Stardard / Custom ERC-20 / WETH.

      3. Caso 3: Deposito de tokens ERC-721/ERC-1155.

   2. Gateways de Retiro.

      1. Caso 1: Retiro de ETH.

      2. Caso 2: Retiro de tokens ERC-20/Custom tokens/WETH.

      3. Caso 3: Deposito de tokens ERC-721/ERC-1155.

3. Conclusión.

4. Glosario.

1.🤝Mensajes entre Dominios L1 y L2

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.

1.1 Envío de mensajes de L1 a L2

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.

1.2 Proceso de Envío de Mensajes y Transacciones

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.

1.3 Envío de Mensajes Arbitrarios

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.

1.4 Envío de Transacciones Forzadas

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.

1.5 Reintento de Mensajes Fallidos

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.

1.6 Tarifa de Retransmisión de Mensajes

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.

1.7 Alias de Dirección

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.

1.8 Envío de mensajes de L2 a L1

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.

1.9 Withdraw Trie

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.

2. 🚪Gateways de tokens

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.

2.1 Gateways de depósito

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.

Caso 1: Deposito de ETH

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:

1. Primero se llama al contrato Gateway Router de L1.

2. Luego se selecciona la Gateway de ETH de L1 y se codifica el mensaje.

3. El contrato Scroll Messenger de L1 recibe este mensaje codificado y lo agrega al contrato de Message Queue de L1.

4. Despues que la transacción finalize en L1, el secuenciador incluira una transacción en un bloque en L2.

5. 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.

Caso 2: Depositos de tokens ERC-20 Stardard / Custom ERC-20 / WETH

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:

1. La Gateway L1 de ERC20 Standard(o L1StandardERC20Gateway) bloquea los tokens ERC-20 en L1 que seran depositados.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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:

1. La Gateway L1 de Custom ERC20 tokens(o L1CustomERC20Gateway) bloquea los tokens en L1 que seran depositados.

2. 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.

3. Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2

4. 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:

1. 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.

2. 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.

3. Ahora el secuenciador toma la transacción del contrato de Message Queue de L1 y la agrega en un bloque en L2

4. 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.

5. 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.

Caso 3: Deposito de tokens ERC-721/ERC-1155

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.

2.2 Gateways de Retiro

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.

Caso 1: Retiro de ETH

1. Se llama a la Gateway Router de L2, luego se secciona la Gateway adecuada (en este caso la Gateway L2 de ETH).

2. 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.

3. 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.

Caso 2: Retiro de tokens ERC-20/Custom tokens/WETH

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:

1. La Gateway Router de L2 llama a la Gateway correspondiente segun activo (sea ERC20 Standard o Custom ERC20)

2. 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.

3. 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.

4. 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.

5. 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:

1. La Gateway Router de L2 llama a la Gateway L2 de WETH.

2. 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.

3. 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.

4. Finalmente, la Gateway L1 de WETH vuelve a convertir los ETH a WETH y los envia a dirección del destinatario en L1.

Caso 3: Retiro de tokens ERC-721/ERC-1155

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.

3. 👨‍🎓Conclusión

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.

4. 📄Glosario

1. Bridge (Puente): Un sistema que permite la transferencia de activos entre dos blockchains o cadenas de bloques.

2. 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.

3. Tokens: Representaciones digitales de activos o valores, como criptomonedas.

4. 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.

5. Blockchain: Cadena de bloques, una tecnología de registro distribuido utilizada para almacenar transacciones de forma segura y transparente.

6. Envueltos (Wrapped): Tokens que representan otro activo y pueden circular en diferentes blockchains.

7. 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.

8. Sender (Remitente): La entidad que inicia una transacción o mensaje.

9. Gateways (Pasarelas): Plataformas o contratos inteligentes que facilitan el depósito o retiro de activos entre diferentes blockchains.

10. Fee (Tarifa): El costo asociado con una transacción en una cadena de bloques.

11. Alias de Dirección: Una dirección alternativa utilizada para mejorar la seguridad y evitar abusos.

12. Merkle Tree (Árbol de Merkle): Una estructura de datos utilizada para verificar la integridad de los datos en una cadena de bloques.

13. Trie: Una estructura de datos en forma de árbol utilizada en la cadena de bloques para almacenar información.

14. Depósito (Deposit): La acción de transferir activos a una cadena de bloques.

15. Retiro (Withdrawal): La acción de transferir activos fuera de una cadena de bloques.

16. ETH (Ether): La criptomoneda nativa de la plataforma Ethereum.

17. ERC-20, ERC-721, ERC-1155: Estándares de tokens en la plataforma Ethereum.

18. Hash: Un valor único generado a partir de datos, utilizado para verificar la integridad de la información.

19. Batch (Lote): Un grupo de transacciones o activos que se procesan juntos.

20. Gateway Router (Enrutador de Pasarela): Un componente que selecciona la pasarela adecuada para procesar una transacción.

21. Custom Token (Token Personalizado): Un token no estándar, diseñado de forma única.

22. WETH (Wrapped Ether): Ether envuelto, una representación de Ether que se puede utilizar en contratos inteligentes.

🫂 Agradecimientos

🎉 ¡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!

Los 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 a que no sigue la misma lógica de a mayor cantidad de nodos mayor confianza como la L1. Sin embargo, sigue siendo una fuente valiosa de ventajas desde la perspectiva del usuario, y ofrece otras propiedades igualmente importantes.

En Arbitrum, los usuarios tienen la opción de ejecutar un nodo de la red, lo que implica tener una copia completa del rollup en forma de nodo completo o nodo archivo. Además, tanto los productores de bloques (secuenciadores) como aquellos encargados de proponer nuevas transiciones de estado (validadores) deben operar una versión de nodo completo que abarque todas sus responsabilidades en el proceso.

Si deseas explorar con mayor profundidad los roles y responsabilidades de estos participantes en Arbitrum, te recomendamos que leas este artículo. Te proporcionará una comprensión más completa de cómo funcionan estos agentes en la red.

Como comentamos anteriormente, existen diversas razones para considerar la ejecución de un nodo completo de Arbitrum:

• Verificación Independiente del Estado del Rolup: Esto permite detectar transiciones de estado inválidas de manera local e independiente. Esta propiedad es independiente de si el mecanismo de pruebas de fraude está habilitado o no.

• Acceso al Estado Actual o Anterior: Los usuarios pueden acceder al estado actual o anterior del rollup, lo que les permite solicitar información o interactuar con la red sin depender de servicios de terceros.

• Interacción Directa en la L2: Los usuarios pueden interactuar directamente en la capa 2 (L2) e incluso generar pruebas locales para realizar retiros e incluir transacciones de manera autónoma.

• Persistencia de los datos: los usuarios tienen acceso al historial del rollup. Esto cobrará más importancia luego de implementarse la EIP-4844.

Cualquier proveedor de infraestructura en la red Arbitrum, como exploradores, puentes, keepers e indexadores, opera directamente o depende de un nodo completo. Esto demuestra la importancia de ejecutar y mantener un nodo completo para contribuir al funcionamiento eficiente de la red y aprovechar todas sus capacidades.

¿Cómo correr un full node de Arbitrum Nitro?

A continuación encontrarás la información necesaria para configurar un nodo completo de Arbitrum Nitro en tu casa. Recorreremos el camino desde las precondiciones hasta la configuración del docker, de la forma más simple posible.

1. Precondiciones

1.a. Hardware mínimo necesario

En esta sección, detallamos los requisitos de hardware mínimos necesarios para configurar un nodo completo de Arbitrum Nitro (no es un nodo de archivo) de manera efectiva. Para garantizar un funcionamiento óptimo, se recomienda contar con al menos la siguiente configuración:

• RAM: 8-16 GB

• CPU: 2-4 núcleos

• Almacenamiento: Mínimo 1.2 TB SSD (asegúrese de que sea posible agregar más espacio)

• Tasa de crecimiento estimada: Aproximadamente 3 GB por día

Es importante tener en cuenta que estos requisitos mínimos de almacenamiento pueden cambiar con el tiempo a medida que la red Nitro crece. Por lo tanto, se aconseja utilizar hardware que supere estos requisitos mínimos para ejecutar un nodo completo de manera eficiente.

1.b. Herramientas necesarias:

Para configurar el nodo, necesitarás la siguiente herramienta:

• Última imagen de Docker: offchainlabs/nitro-node:v2.0.14-2baa834

Esto dependerá del sistema operativo de tu computadora. Te recomendamos consultar la documentación de Docker y seguir los pasos correspondientes para tu sistema. Por ejemplo, si utilizas Ubuntu, puedes consultar la guía en https://docs.docker.com/engine/install/ubuntu/.

Antes de comenzar, es crucial asegurarse de tener el Docker instalado en tu sistema. Si ya lo tienes instalado, desinstálalo y asegúrate de tener la última versión. Para verificar que la instalación se realizó correctamente, puedes ejecutar el siguiente comando en tu terminal:

sudo docker run hello-world

Si recibes un mensaje de confirmación, la instalación de Docker se completó con éxito.

2. Cómo configurar tu PC

Para esta etapa, se recomienda descargar Visual Studio Code, ya que facilita la visualización de carpetas y la apertura de múltiples terminales.

2.a Creación de Carpetas y Archivos

• Abrí Visual Studio Code y dirígete a File > Open Folder > Filesystem.

• Abrí una nueva terminal en VS Code.

• Navega hasta la carpeta "home" y crea una carpeta llamada "user" dentro de ella. Si encuentras problemas de permisos, puedes utilizar el siguiente comando dentro de /home:

sudo chmod 777 /home

• A continuación, crea una carpeta llamada ".arbitrum" dentro de la carpeta "user". La dirección de esta carpeta será: home/user/.arbitrum.

Para crear estas carpetas utilizando la terminal, el camino sería el siguiente:

La dirección de la carpeta quedaría en: home/user/.arbitrum.

Recarga el explorador en VS Code para visualizar las carpetas recién creadas.

Dentro de la carpeta principal, dirígete a la carpeta "user" y luego a "local", donde crearás otra carpeta llamada "arbitrum". Si experimentas problemas de permisos para crear la carpeta "arbitrum", puedes usar nuevamente el comando "sudo chmod" mencionado anteriormente.

Dentro de /arbitrum, crea un nuevo archivo llamado "docker-compose.yml". Puedes hacerlo fácilmente desde VS Code. La dirección de esta carpeta será: /usr/local/arbitrum/docker-compose.yml.

2.b Permisos

La imagen de Docker está configurada para ejecutarse como un usuario no root con UID 1000. Esto significa que si estás utilizando Linux u OSX y encuentras errores de permisos al intentar ejecutar la imagen de Docker, deberás ejecutar el siguiente comando para permitir que todos los usuarios actualicen las carpetas persistentes. Asegúrate de estar dentro de la carpeta "usr/local/arbitrum" al ejecutar este comando en la terminal:

chmod -fR 777 arbitrum

Con esto, hemos otorgado al Docker permisos de escritura en nuestro directorio. Aún no utilizaremos el archivo, ya que iremos agregando contenido gradualmente.

3. Descargar un Snapshot de Arbitrum

Ahora vas a proceder a descargar los datos históricos de la blockchain de Arbitrum y los ubicarás en la carpeta /usr/local/arbitrum.

Es importante que te asegures de estar en la carpeta /usr/local/arbitrum utilizando el comando "cd". Se recomienda realizar la descarga mediante la terminal, ya que si se produce algún error de conexión (lo cual es posible), la terminal realizará automáticamente la solicitud para reanudar la descarga.A continuación, procederemos a descargar los datos históricos de la blockchain de Arbitrum. Estos datos se almacenarán en la carpeta /home/user/.arbitrum.

Podés realizarlo de 2 formas:

3.a. A través de la terminal:

Asegúrate de estar ubicado en la carpeta /home/user/.arbitrum antes de ejecutar este comando. Puedes navegar a esta carpeta utilizando el comando "cd" (change directory)

wget https://snapshot.arbitrum.foundation/arb1/nitro-pruned.tar

3.b. Por medio de un navegador web:

Deberías identificar el archivo llamado "nitro-pruned.tar" y descargarlo desde acá.

En pantalla vas a ver lo siguiente:

Aclaración: Al momento de escribir esta guía, el tamaño del archivo es de alrededor de 310 GB.

4. Parámetros requeridos

El siguiente paso implica obtener un URL RPC de Ethereum para la Capa 1. Debes proporcionar la siguiente información:

-l1.url=<Layer 1 Ethereum RPC URL>

Este parámetro requiere un enlace RPC de nodo estándar de Layer 1 que esté en funcionamiento, ya sea uno que administres tú mismo o que provenga de un proveedor de nodos confiable (si quisieras también correr tu propio nodo de Ethereum, podés revisar la guía creada por SeedLatam aquí).

-l2.chain-id=<L2 Chain ID>

Para obtener el URL necesario, en esta guía aprenderás cómo conectarte a un nodo proporcionado por Alchemy, uno de los principales proveedores de nodos en la red. Esto te permitirá obtener los recursos necesarios para continuar con la configuración.

Con estos pasos, estarás en camino de configurar tu propio nodo completo de Arbitrum Nitro de manera efectiva y contribuir al fortalecimiento de la red.

5. Cómo conectarse a un Nodo de Ethereum en Alchemy

Aquí tienes una guía paso a paso sobre cómo puedes conectarte a un nodo de Ethereum utilizando Alchemy como tu proveedor de nodo para conectarlo a tu nodo de Arbitrum:

Paso 1: Registro en Alchemy

Tu primer paso consiste en dirigirte al sitio web de Alchemy para registrarte y proporcionar algunos detalles. Si ya te habías registrado anteriormente, simplemente inicia sesión.

Paso 2: Creación de una Nueva Aplicación de Ethereum

Dirígete a la sección de "Aplicaciones" en el menú izquierdo y haz clic en el botón "Crear nueva aplicación". Luego, selecciona lo siguiente:

Cadena: Ethereum

Red: Ethereum Mainnet

Nombre: [Elige un nombre]

Descripción: [Elige una descripción]

Una vez configurado, haz clic en "Crear aplicación". Regresa a la página de inicio, donde encontrarás la aplicación recién creada.

Haz clic en "API key" (la clave del API) y guarda el código HTTPS que necesitarás en el Paso 5: Configuración del Docker.

5. Configuración del docker

Dirígete a /home/usr/local/arbitrum/docker-compose.yml y pega el siguiente contenido:

version: '3.3' 
services:
nitro-node:
network_mode:host 
image: 'offchainlabs/nitro-node:v2.0.14-2baa834' 
user: 1000:1000 
restart: always 
stop_grace_period: 30s 
volumes: 
# localPath : containerPath 
- '/usr/local/arbitrum:/home/user/.arbitrum' 
ports:
- '0.0.0.0:8547:8547' 
- '0.0.0.0:8548:8548' 
command: 
- --init.url=file:///home/user/.arbitrum/nitro.tar 
- --l1.url=https://eth-mainnet.g.alchemy.com/v2/4FMFgbhtdTwvS-Mtt1V7PfUqh_CwYRN4 
- --l2.chain-id=42161 
- --http.api=net,web3,eth,debug 
- --http.corsdomain=* 
- --http.addr=0.0.0.0 
- --http.vhosts=* 
logging: 
driver: json-file 
options: 
max-size: 10m 
max-file: "10"

Observación Importante: Cuando escribas el archivo manualmente, asegúrate de agregar espacios desde el comienzo de cada línea en lugar de usar tab, ya que el archivo podría no ser leído correctamente.

Asegúrate de guardar el archivo después de pegar (Ctrl+S).

Consideraciones importantes:

• Es fundamental que el parámetro image: 'offchainlabs/nitro-node:v2.0.14-2baa834' coincida con la versión especificada en la documentación de Arbitrum. Ten en cuenta que esta versión puede cambiar con el tiempo, por lo que debes verificar la versión actual en la documentación de Arbitrum y utilizar la que esté publicada allí.

En l2.chain-id, debes asignar el valor 42161, ya que la documentación de Arbitrum indica que ese es el Chain ID de Arbitrum One.

El puerto en el que se ejecutará el RPC es 8547.

6. Ejecutando el Nodo (Putting it all together)

Ahora que has preparado la PC y configurado el Docker, es hora de ejecutar tu nodo de Arbitrum. Sigue estos pasos con atención para asegurarte de que todo funcione sin problemas.

Para iniciar el nodo, dirígete a la terminal y navega hasta /usr/local/arbitrum, luego ejecuta el siguiente comando:

sudo chmod 666 /var/run/docker.sock

Este comando te permitirá ejecutar los comandos de Docker que necesitas. A continuación, ejecutaras el comando principal para iniciar el nodo:

docker run --rm -it -v /usr/local/arbitrum:/home/user/.arbitrum 
-p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v2.0.14-2baa834 
--l1.url https://eth-goerli.g.alchemy.com/v2/b-CFpogLW7ZBL5idfoWOF3Tm5hI4OMk_ 
--l2.chain-id=421613 
--http.api=net,web3,eth,debug 
--http.corsdomain=* 
--http.addr=0.0.0.0 
--http.vhosts=*

Este es el desglose de los parámetros del comando:

• -docker run --rm -it -v /usr/local/arbitrum:/home/user/.arbitrum

• -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v2.0.14-2baa834

• --l1.url https://eth-goerli.g.alchemy.com/v2/b-CFpogLW7ZBL5idfoWOF3Tm5hI4OMk_

• --l2.chain-id=42161

• --http.api=net,web3,eth,debug

• --http.corsdomain=*

• --http.addr=0.0.0.0

• --http.vhosts=*

Esto es una versión acortada del archivo de Docker que configuraste anteriormente, vas a tener que reemplazar los parámetros por tus valores. Al parámetro chain-id lo debes dejar en 4261 si estas en mainnet (Ver la tabla del paso anterior donde se indica el Chain ID dependiendo de la red a la cual nos queremos conectar).

Es importante que reemplaces el url de la L1 que obtuviste en Alchemy. Una vez que hayas reemplazado los parámetros necesarios con tus propios valores, ejecuta el comando.

Vas a ver la siguiente imagen en pantalla:

6.a Verificación del Nodo

Si puedes ver información como se muestra en la imagen, ¡Felicitaciones, tu nodo está funcionando correctamente!

6.b Detener el nodo

Para detener el nodo, abrí otra terminal y ejecuta el siguiente comando:

docker stop --time=300 $(docker ps -aq)

Este comando asegura un apagado ordenado de todas las imágenes de Docker en ejecución. Al apagar una imagen de Docker, es importante permitir un cierre ordenado para que el estado actual pueda ser guardado en disco.

6.c Probando comandos

Ahora vas a volver a levantar el Nodo utilizando el siguiente comando:

(este comando utiliza el archivo que creaste en docker-compose.yml)

Así verás que tu nodo esta funcionando nuevamente y de forma correcta:

7. Adicional

Puedes enviar varios comandos al nodo una vez que esté en funcionamiento. Consulta la documentación de Ethereum para obtener una lista de métodos que puedes utilizar.

También, si deseas probar comandos, puedes utilizar Postman. (shout out Juanu por el link)

De querer obtener algún dato en particular, podés utilizar los comandos que brinda la documentación de Ethereum, por ejemplo el blockNumber actual:

Vas a dirigirte a Postman y realizamos el post, se debe hacer desde la misma pc desde donde corre al nodo:

Conclusión

En resumen, con esta guía contarás con la información necesaria para correr tu propio nodo completo de Arbitrum y contar con la capacidad de verificar transacciones de forma independiente y con menos requisitos de confianza lo que termina fomentando la accesibilidad de la red.

Los recursos requeridos para un nodo completo son accesibles y su configuración, aunque técnica, es alcanzable para aquellos con conocimientos básicos de desarrollo Web3. Los pasos que hemos delineado, desde otorgar permisos del Docker y su configuración hasta la descarga del snapshot y ejecución del nodo, son el camino hacia la autonomía y la contribución activa a la resistencia de Arbitrum.

Además, al interactuar directamente con la L2 y tener acceso al estado de la red, podrás presenciar de primera mano los resultados de tu contribución al ecosistema.

Si consideras la soberanía, la resistencia a la censura y la accesibilidad como conceptos fundamentales, la ejecución de un nodo completo se convierte en un acto poderoso.

¡Es hora de correr tu propio nodo y formar parte del ecosistema activamente!

Hoy en día, los Optimistic Rollups que incorporan sistemas de validación de pruebas de fraude, como Arbitrum One y Nova, llevan a cabo la validación de su estado en la cadena de Ethereum. Este proceso involucra a un conjunto de entidades conocidas como "validadores", los cuales emiten afirmaciones sobre el estado de la capa 2 (L2) en un contrato inteligente, después de haber verificado su autenticidad. Durante un periodo de 7 días, otros validadores tienen la posibilidad de impugnar estas afirmaciones, dando inicio a un proceso de resolución de disputas. Una vez que una afirmación es confirmada, el estado subyacente se considera como válido desde la perspectiva de Ethereum. Este proceso de validación es esencial para garantizar la seguridad en la transferencia de activos entre las cadenas de Arbitrum y Ethereum L1, aunque conlleva un cierto retraso.

No obstante, en la actualidad, la validación en Arbitrum One y Nova, a través de pruebas de fraude, se encuentra limitada debido a la vulnerabilidad de sus protocolos de disputa frente a ataques de denegación de servicio (DoS). Un validador malintencionado podría gastar repetidamente fondos con el objetivo de evitar que las afirmaciones sean confirmadas, lo que resultaría en un retraso en los retiros de L2 a L1 durante el tiempo que él esté dispuesto a mantener dicha acción.

📝 Índice

1. ¿Qué son los ataques de denegación de servicio (DoS)?

2. Arbitrum BOLD

3. Arquitectura de BOLD

4. ¿Cómo funciona?

5. Conclusión

🤷‍♂️¿Qué son los ataques de denegación de servicio (DoS)?

Por definición, los DoS Attacks son un tipo de ataque por el cual actores maliciosos buscan evitar que los usuarios de un sistema informático en línea puedan acceder al mismo saturándolo con peticiones ilegítimas de servicio.

Esta situación evita que los usuarios legítimos hagan uso del sistema y del servicio que el mismo presta. Este tipo de ataques pueden estar dirigidos a afectar la fuente que ofrece la información, la aplicación o el canal de transmisión del sistema. Algo que generalmente se logra al explotar vulnerabilidades o sobrecargar la capacidad de los servidores. El último caso es el más común de ellos, pues es sencillo, rápido y muy efectivo.

Antes estas premisas, nos llega la pregunta:

¿Existe alguna solución para evitar un escenario distópico en donde se puede afectar el sistema de disputas de Arbitrum?

⚔Arbitrum BOLD

En el contexto de las cadenas L2, es esencial abordar los desafíos relacionados con los retrasos al asegurar la confirmación del estado  de la misma en la red Ethereum. En este sentido, BOLD surge como una evolución del sistema de resolución de disputas de Arbitrum, presentando un enfoque notablemente robusto.

BOLD representa el primer protocolo práctico de desafío que ofrece una eficiente gestión de disputas entre múltiples participantes. Las ventajas que ofrece BOLD son significativas:

• Confirmaciones más Rápidas: BOLD garantiza límites superiores fijos en los tiempos de confirmación para la determinación del estado en el Optimistic Rollup.

• Equidad y Eficiencia: BOLD garantiza que incluso una sola entidad honesta pueda prevalecer frente a un número considerable de afirmaciones maliciosas.

En el marco de BOLD, las disputas se vinculan con la ejecución determinista de un estado en la capa 2, y no con un staker o entidad específica. Esto implica que cualquier entidad que esté de acuerdo con un estado tiene el poder de defenderlo, hasta que surja un único punto de desacuerdo. Debido a la naturaleza determinista del estado L2 honesto, las entidades honestas siempre prevalecerán al participar, ya que las entidades maliciosas no pueden falsificar pruebas de ejecución, ya que las mismas tienen garantizada su realización en Ethereum.

🧩Arquitectura de BOLD

Al analizar la interconexión de los componentes de BOLD, es útil tener en mente el software utilizado por un validador real en Arbitrum: Arbitrum Nitro. Entre sus responsabilidades clave se encuentran:

• Ejecutar transacciones entrantes desde un contrato Inbox y generar post-estados conforme a la transición de estado en la capa 2.

• Transmitir lotes de transacciones a Ethereum L1 a través de un contrato denominado SequencerInbox.

• Validar transacciones y emitir afirmaciones, conocidas como aserciones, acerca del estado en la capa 2 a intervalos regulares en Ethereum, utilizando un contrato denominado RollupCore.sol.

• Refutar las aserciones incorrectas enviadas por validadores deshonestos a RollupCore.sol

Además, es importante destacar que la tecnología Arbitrum se está transformando en una arquitectura más modular, permitiendo la ejecución independiente de componentes específicos como binarios separados. BOLD implementa un componente de Nitro encargado de emitir aserciones y desafiar afirmaciones inválidas, dependiendo, por lo tanto, de otras partes del nodo Nitro para acceder a los datos de estado necesarios.

Adicionalmente, el repositorio de BOLD es un proyecto autónomo en GitHub, independiente de Nitro, y se conecta a las cadenas de Nitro como una dependencia para cumplir sus funciones.

🛠¿Cómo funciona?

El BOLD Challenge Manager de arriba interactúa con algunos elementos de un nodo Arbitrum, permitiéndole hacer movimientos de retos y enviar compromisos de historia a los contratos en Ethereum. En código de Arbitrum, se abstraen esos componentes del nodo L2 a través de una pequeña interfaz llamada L2 State Provider.

Recordemos que el núcleo primitivo del protocolo son los challenge edges, donde un edge representa un compromiso histórico de inicio y fin de una cadena Arbitrum. Los participantes en el protocolo pueden hacer movimientos en los retos, y los validadores pueden participar en muchos retos simultáneamente. Es decir, el software necesita rastrear edges dentro de un reto y su ciclo de vida para ganar contra entidades maliciosas.

La arquitectura detallada es la siguiente:

Funciona de la siguiente manera:

1. Un Assertion Poster frecuentemente toma mensajes validados del validador L2 y los publica on-chain.

2. Un Assertion Scanner comprueba los contratos inteligentes en Ethereum en busca de nuevas aserciones publicadas y las compara con la base de datos local del nodo Nitro (o “DB” por sus siglas en inglés). Esto se hace a través de una abstracción conocida como L2 State Provider. Esto está dentro de assertions/scanner.go

3. Si no estamos de acuerdo con una aserción, nuestro Challenge Manager envía un desafío on-chain creando un canal de nivel cero, y rastrea ese canal como una go routine.

4. Nuestro Chain Watcher, en segundo plano, escanea otros edges creados en la cadena y genera goroutines “Edge trackers” para los edges honestos que aún no se han rastreado.

Cada Edge es rastreado como una goroutine llamada Edge Tracker. Los Edge Tracker son goroutines autónomos que se activan a intervalos de tick especificados y utilizan una máquina de estados finitos para decidir qué movimiento de desafío realizar. Por ejemplo, después de crear un edge, intentará dividirla, y confirmarla mediante una prueba de un paso o crear un subdesafío, dependiendo de cómo se presenta el estado actual.

Este es el aspecto de la máquina de estados finitos de un rastreador de aristas, cuyo estado final es confirmado:

Una vez que se confirma un edge de nivel cero para un desafío sobre una afirmación, la afirmación puede validarse y la parte honesta saldrá victoriosa.

👨‍🎓Conclusión

Arbitrum ha creado un nuevo enfoque para la validación que nos da un límite superior fijo de 7 días de retraso adicional en las confirmaciones sin sufrir ataques de retraso. BOLD puede hacer que la validación de las cadenas Arbitrum sea segura y sin permisos, lo que las hace subir muchos peldaños en la escalera de la descentralización. El enfoque permite a un único validador honesto ganar disputas en Ethereum contra cualquier número de adversarios.

Con su incorporación, BOLD busca añadir a Arbitrum, una mejor seguridad, liveness y latencia para establecer estados en su cadena y, al mismo tiempo, evitar que las partes deshonestas aumenten el costo de las partes honestas.

Con Arbitrum BOLD, Ethereum contará con una implementación de Optimistic Rollup de propósito general completamente funcional, el cual permitirá asegurarlo bajo suposiciones de confianza ideales (1 de n) y escalar el ecosistema genuinamente y sin compromisos.

🫂 Agradecimientos

🎉 ¡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.

Si quieres conocer mas a fondo la tecnología detrás de Arbitrum te invitamos a leer estos artículos👇👇👇

Introducción al Optimistic Rollup de Arbitrum

https://mirror.xyz/layer2es.eth/L0YiPok0FymbnHZyA5GqbKL4OL0U4jBDwTuTGzD4PiE

Arbitrum One vs Arbitrum Nova

https://mirror.xyz/layer2es.eth/InEgFG-fRvNv4LTIUSGp0vF9PTyl58AdqswqaYJYu3M

Arbitrum Orbit

https://mirror.xyz/layer2es.eth/yqFRGQzBnGqV0z-fFeuwScBfwf3FVAaplYhThGs5E2E

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!

Con el objetivo de seguir aumentando la adopción de la red de Arbitrum Offchain Labs lanzó un interesante producto llamado Arbitrum Orbit. Esta poderosa herramienta permite a los usuarios y desarrolladores crear sus propias cadenas Layer 3 (L3) en la infraestructura subyacente de las cadenas públicas de Capa 2 (L2) de Arbitrum. Estas cadenas L3, también conocidas como "cadenas Orbit", se pueden configurar como un Arbitrum Rollup o AnyTrust, según las necesidades del usuario.

En este artículo, exploraremos en detalle qué son las cadenas Orbit y cómo pueden brindar a los usuarios características mejoradas de escalabilidad, personalización e interoperabilidad, al tiempo que mantienen los principios de seguridad de la capa base de Ethereum. También discutiremos los beneficios que las cadenas Orbit ofrecen a sus propietarios y las diversas posibilidades que se abren gracias a su implementación.

¡Sigue leyendo para descubrir cómo Arbitrum Orbit puede llevar tus aplicaciones y proyectos a un nivel completamente nuevo de personalización y funcionalidad!

📝 Índice

1. ¿Qué es Arbitrum Orbit?.

2. ¿Qué son las Orbit chains?.

3. Problemas que Orbit soluciona.

4. Beneficios de las Orbit chains.

5. Aplicaciones descentralizadas en Orbit (Dapps).

6. Compatibilidad entre Orbit chains.

7. Licencias de Arbitrum Orbit.

8. Guía de como desplegar una Orbit Chain.

   1. Prerrequisitos.

   2. Paso 1: Adquirir ETH en Arbitrum Goerli.

   3. Paso 2: Configurar el despliegue de la Orbit chain.

   4. Paso 3: Despliegue de los contratos base de la cadena en Arbitrum Goerli.

   5. Paso 4: Configure los validadores de la cadena.

   6. Paso 5: Configure el publicador de lotes de la cadena.

   7. Paso 6: Descargue los archivos de la chain y despliegue de la misma. Paso 7: Clone el repositorio de scripts de configuración y agregue sus archivos.

   8. Paso 8: Ejecute el nodo de su cadena y el explorer.

   9. Paso 9: termine de configurar su la chain.

9. Comandos útiles.

   1. Registros.

   2. Depositar ETH.

   3. Resolución de problemas.

10. Conclusión.

1.🤷‍♂️¿Qué es Arbitrum Orbit?.

Arbitrum Orbit es una herramienta creada por Offchain Labs que permite a los usuarios o desarrolladores crear su propia cadena Layer 3 (o L3) que se establece de manera subyacente en una de las cadenas públicas de L2 de Arbitrum.  Estas L3, también llamadas “Orbit chains”, pueden ser configuradas para ser de tipo Arbitrum Rollup o AnyTrust dependiendo de las necesidades del usuario.

2.⛓¿Qué son las Orbit chains?.

Las Orbit chains o “cadenas Orbit” pueden ser definidas como forks desplegables y configurables creadas a partir de la tecnología L2 Nitro de Arbitrum, las cuales están estrechamente conectadas a las cadenas L2 de Arbitrum. También pueden ser visualizadas como cadenas personalizadas, diseñadas específicamente para adaptarse a un caso determinado, ya sea de uso personal o empresarial.

Al utilizar estas chains personalizadas, los usuarios pueden encontrar una forma adicional de descentralizar gradualmente sus aplicaciones y adoptar de manera intrínseca las características de seguridad y supuestos de confianza de la Layer 2 de Arbitrum, ya que ésta actúa como capa base de las Orbit chains.

Por otro lado, estas chains están diseñadas para permitir integrar de forma continua las mejoras realizadas a Arbitrum Nitro, que es el código que alimenta los nodos que respaldan las cadenas L2 y Orbit de Arbitrum.

Es importante destacar que Arbitrum One y Arbitrum Nova implementan los protocolos Arbitrum Rollup y AnyTrust, respectivamente. Cada cadena Orbit puede configurarse para utilizar la tecnología Rollup o AnyTrust dependiendo de los gustos o necesidades del usuario que será propietario de la Orbit chain.

Arbitrum One y Arbitrum Nova son propiedad y están gobernadas por la DAO de Arbitrum. Por otro lado, con las cadenas Orbit, cada propietario determina cómo se gobernará su cadena. Aun así, la DAO de Arbitrum permite que cualquier propietario de una Orbit chain pueda establecerse y ser gobernada por la comunidad tal como las redes de Arbitrum One y Arbitrum Nova.

3.🔧Problemas que Orbit soluciona.

El espacio de bloques en Ethereum posee una alta demanda, por tal motivo, muchos usuarios quedan “atascados” esperando que la red esté un poco menos congestionada (y además de menos costosa en cuestión de comisiones).

Los protocolos Rollup y AnyTrust de Arbitrum abordan este reto descargando parte del trabajo pesado de la red Ethereum a otra red descentralizada de nodos que soportan las cadenas Arbitrum One y Arbitrum Nova L2, respectivamente.

Estas dos cadenas públicas satisfarán las necesidades de la mayoría de los proyectos. Pero las cadenas públicas compartidas no son para todos. Algunos proyectos pueden beneficiarse de sus propias cadenas AnyTrust o Rollup que ofrecen la misma seguridad, pero con un mayor grado de control sobre las características de la cadena y la gobernanza.

Las cadenas Orbit te ofrecen la posibilidad de crear tus propias cadenas AnyTrust y Rollup utilizando tu propia infraestructura. Puedes pensar en tu cadena Orbit como un carril prioritario autogestionado en Ethereum. Cada cadena Orbit es capaz de soportar varias veces la capacidad de Ethereum, al tiempo que se beneficia directamente de la seguridad de Ethereum.

En pocas palabras, las cadenas Arbitrum One y Arbitrum Nova desbloquean dos opciones públicas de despliegue de contratos gestionados por DAO que escalan Ethereum y satisfacen las necesidades de la mayoría de los proyectos.

Por su parte, las cadenas Arbitrum Orbit desbloquean un jardín infinito de opciones de despliegue de contratos autogestionados que escalan Ethereum aún más, con cada cadena Orbit individual adaptada con precisión a las necesidades de su propietario.

4.✅Beneficios de las Orbit chains.

Al ser propietario de alguna de estas Orbit chains puede personalizar su privacidad, permisos, tarifas, gobernanza y mucho más. Algunos ejemplos de posibilidades que esto desbloquea:

• Lanzar una red blockchain descentralizada impulsada por Nitro, y que se beneficie de las pruebas de fraude, la compresión avanzada, la compatibilidad con EVM+ a través de Stylus y las mejoras continuas de Nitro.

• Ofrecer fiabilidad en el precio del gas a sus usuarios finales gracias al rendimiento dedicado y al aislamiento del tráfico que las cadenas Orbit tienen por defecto.

• Acceso con permisos para controlar quién puede leer los datos de su cadena y quién puede desplegar contratos inteligentes en ella. Su cadena puede ser completamente sin permisos como Ethereum y Arbitrum One, o puede implementar sus propias políticas de permisos.

• Cobrar comisiones utilizando activos diferentes a ETH para iterar rápidamente sobre diseños de mecanismos específicos del dominio y oportunidades de captura de valor.

5.📱Aplicaciones descentralizadas en Orbit (Dapps).

Una de los usos de las orbit chains puede ser para desplegar alguna aplicación descentralizada, ya que generalmente estas dependen de un control y actualización recurrente por parte de los desarrolladores de la misma. Entre los beneficios que las orbits chains traen para este tipo de soluciones:

• Rendimiento dedicado: Al ejecutar una dApp en su propia cadena orbit aumentará significativamente la disponibilidad de recursos.

• Compatibilidad con EVM+: Las orbit chains son compatibles con Ethereum gracias a Stylus, lo que significa que se pueden crear códigos usando Solidity, pero también en C, C++ y Rust sin problemas.

• Roadmaps independientes: Si desea desvincular la hoja de ruta de su cadena de aplicaciones de la de Ethereum y/o Arbitrum, Orbit lo hace posible. Esto le permite implementar funciones de vanguardia como la Account Abstraction antes de los proyectos que siguen la hoja de ruta pública de Ethereum.

• Mayor confiabilidad en el precio del gas: Diversos tipos de dApps utilizan costos de transacción predecibles. Al optar por las cadenas Orbit, que están separadas del tráfico de Arbitrum L2 y Ethereum L1, el impacto de la actividad en cadena de otras aplicaciones no afectará significativamente su funcionamiento. Esto permite a los usuarios de su dApp disfrutar de tarifas de gas más estables y confiables.

• Di hola a Account Abstraction: La estabilidad en los precios del gas es de gran utilidad para prever y calcular los costos comerciales, permitiendo así explorar enfoques tradicionalmente costosos, como subsidiar las tarifas de transacción. Esto simplifica la complejidad técnica de las aplicaciones descentralizadas para los usuarios finales, lo que les brinda experiencias descentralizadas que resultan familiares para audiencias no técnicas, quienes pueden no estar familiarizadas o interesadas en los detalles de la implementación.

• Tokens para los fees: Las cadenas Orbit pueden usar cualquier token que elija como token de tarifa, lo que facilita la integración perfecta con el ecosistema de su dApp.

• Lógica de protocolo personalizable: Puede ser necesario ajustar la lógica de los procedimientos de liquidación, ejecución o gobierno de su red blockchain para satisfacer requisitos particulares. Las redes de Orbit ofrecen esta capacidad al tiempo que aprovechan la seguridad de Ethereum mediante cadenas L2 que son gobernadas por la organización autónoma descentralizada (DAO) de Arbitrum.

• Compatibilidad con Arbitrum Nitro: Las cadenas Orbit tendrán acceso a todas las actualizaciones de código Nitro, adiciones de funciones y mejoras, lo que le dará a su cadena Orbit la opción de mantenerse actualizada e incorporar lo último y lo mejor en tecnología de escalado de Ethereum.

• Opciones de descentralización: Puede crear una cadena Arbitrum Rollup que use Ethereum para la disponibilidad de datos, o puede crear una cadena Arbitrum AnyTrust que use un Comité de Disponibilidad de Datos (DAC) según las necesidades y gustos del usuario.

• Seguridad: La tecnología Arbitrum impulsa las L2 más seguras, y puede usar este mismo stack de tecnología para su cadena Orbit.

6.🧩Compatibilidad entre Orbit chains.

Todas las cadenas de Orbit funcionan con nodos autogestionados que ejecutan su propia instancia del software del nodo de Arbitrum Nitro. Esto significa que una cadena Orbit personalizada no es una red completamente aislada, ya que cuando esta es creada, se une a un ecosistema de cadenas conectadas que pueden intercambiar información entre sí.

Actualmente las funciones de interoperabilidad nativa entre cadenas Orbit no se han lanzado, pero si están bajo desarrollo y planeadas en la hoja de ruta de Arbitrum.

7.📜Licencias de Arbitrum Orbit.

Estas licencias no son más que permisos completos, que dan la posibilidad a los usuarios de modificar el código base de Arbitrum Nitro para satisfacer sus necesidades. Existen 2 tipos de licencias:

• Perpetua: Dura indefinidamente.

• Recursiva: Que su cadena Orbit puede albergar otras cadenas regidas por la misma licencia.

Es importante destacar que la licencia de Arbitrum Orbit no incluye cadenas establecidas en una cadena no gobernada por la DAO de Arbitrum. Lo que quiere decir que si se quiere lanzar una cadena Nitro como L2 independiente de Ethereum deberá obtener una licencia personalizada.  Esto se puede lograr preguntando directamente a Offchain Labs (dueño del software) o través de la DAO (mediante un propuesta).

8.👨‍🍳Guía de como desplegar una Orbit Chain.

8.1 Prerrequisitos.

• Se debe tener el Docker instalado.

• Por lo menos 1.5 ETH en la testnet de Ethereum Goerli.

• Una wallet de Ethereum con soporte en un browser. (Por ejemplo: MetaMask)

Una vez reunidos los requisitos procederemos a ingresar al portal de implementación de Orbit chain.

8.2 Paso 1: Adquirir ETH en Arbitrum Goerli.

Necesitará al menos 1.5 ETH en Arbitrum Goerli para cubrir el costo de implementar los contratos base de su cadena Orbit en su cadena base (Arbitrum Goerli).

Para hacer esto se recomienda usar el faucet goerlifaucet.com para adquirir los ETH Goerli testnet L1 necesarios. Luego de ello, transfiere dichos fondos desde Goerli testnet L1 a la Goerli Arbitrum L2 usando el Bridge de Arbitrum.

8.3 Paso 2: Configurar el despliegue de la Orbit chain.

Visite el portal de implementación de la Orbit chain. Se le pedirá que conecte su billetera. Es posible que se le solicite agregar la red Arbitrum Goerli a su billetera y/o cambiar su billetera a esta red; luego de ello apruebe dicha solicitud.

El portal de implementación mostrará un formulario similar a este:

En este IU muestra los siguientes campos que deben ser debidamente rellenados, aunque algunos son puestos automáticamente por la plataforma:

Chain ID

No te preocupes por esto; es intrascendente para los desarrolladores. En escenarios de producción (que aún no son compatibles), querrá usar un identificador entero único que represente la red de su cadena en índices de cadena como Chainlist.org.

Chain name

Es el nombre de la chain, es una manera de para que cada Orbit chain pueda diferenciarse de otras. Se recomienda usar un nombre fácil de recordar y distintivo entre los usuarios.

Challenge period (blocks)

El Challenge period (blocks) es parámetro determina la cantidad de tiempo que los validadores de su cadena tienen para disputar, o "desafiar", la integridad de las transacciones publicadas en la cadena base de su cadena Orbit en L2 (Arbitrum Goerli por ahora; la liquidación en las cadenas principales One y Nova aún no es compatible).

Un período de desafío más largo significa que los nodos de su cadena tendrán más tiempo para disputar transacciones fraudulentas, pero también significa que los usuarios de su cadena tendrán que esperar más tiempo para que finalicen sus transacciones. Esta es una de las muchas compensaciones que Orbit le permite hacer al configurar su cadena.

Tenga en cuenta que el período de desafío se mide en bloques en la cadena L1 subyacente, no en la cadena base (L2). Si su cadena Orbit se establece en Arbitrum Goerli, la ventana del período de desafío sería el número de Challenge period (blocks) multiplicado por el tiempo de bloque L1 Goerli (~12 segundos).

Stake token

Su cadena Orbit estará respaldada por al menos un nodo. Para que los nodos de su cadena registren transacciones, deben hacer stake de algún valor como una forma de incentivar la participación honesta.

Este parámetro Stake token especifica el tipo de token que los nodos de su cadena deben depositar en este contrato cuando hacen stake. Esto se especifica utilizando la dirección del contrato del token en la cadena L2 en la que su cadena se está asentando a Arbitrum Goerli

Base stake

El parámetro Base stake especifica la cantidad de ETH que el validador de su cadena debe depositar para comenzar a proponer lotes de transacciones de su cadena Orbit a sus contratos base. Esto se especifica mediante un valor flotante.

Si el Base stake es bajo, la barrera de participación será baja, por lo que la cadena será más vulnerable a ciertos tipos de ataques.

Por ejemplo, una cadena Orbit con un stake base de 0,01 ETH podría ser detenida por un adversario que puede permitirse el lujo de implementar validadores de sacrificio que desafían maliciosamente cada RBlock enviado a la cadena base de su cadena Orbit.

Los desafíos maliciosos darían como resultado validadores de la cadena Orbit castigados (un validador castigado por desafío malicioso), pero desde la perspectiva del adversario, el castigo periódico es solo el precio que tienen que pagar para mantener su cadena fuera de línea.

Una apuesta base más alta incentiva la participación honesta al hacer que sea más costoso lanzar este tipo de ataques. Sin embargo, una apuesta base más alta también se traduce en una barrera de entrada más alta para los operadores validadores de su cadena. Esta es otra compensación a considerar.

Owner

Esta dirección de cuenta es responsable de implementar, poseer y actualizar los contratos base de su cadena Orbit en su cadena base.

En escenarios de producción, esta es una dirección de alto riesgo que a menudo está controlada por un protocolo de gobernanza de DAO o la multisig. Para su cadena de desarrollo Orbit, piense en esto como una cuenta de servicio administrativo de bajo riesgo.

Tenga en cuenta que deberá financiar esta dirección con suficiente ETH para cubrir los costos de gas de implementar sus contratos principales en L2.

Esta dirección debe ser una dirección de billetera Ethereum estándar (precisamente hablando, un EOA); no puede ser un contrato inteligente/contrato de billetera.

8.4 Paso 3: Despliegue de los contratos base de la cadena en Arbitrum Goerli.

Haga clic en el botón Deploy Rollup ubicado debajo del formulario de configuración. Su billetera debería indicarle que envíe una transacción a Arbitrum Goerli. Tendrá que pagar un poco de gas; su billetera puede denominar esto en $ ETH; siempre que vea Arbitrum Goerli en los detalles de la transacción, esta tarifa de gas se pagará en ETH de Arbitrum Goerli.

Una vez que se confirme esta transacción de envío de transacción, verá que aparecen varias direcciones de contrato debajo de su Deployment Summary. Estos son los contratos base de su cadena Orbit, desplegados en su cadena base (Arbitrum Goerli).

Antes de continuar, repasemos brevemente lo que acaba de suceder:

• Envió una transacción de implementación a un contrato inteligente de "fábrica" ​​de Orbit en Arbitrum Goerli, la cadena L2 pública en la que su cadena Orbit local liquidará las transacciones.

• Este contrato inteligente de Orbit luego inicializó los contratos base de su cadena Orbit con los valores que especificó en el paso anterior e implementó estos contratos base en Arbitrum Goerli.

Los contratos base de su cadena Orbit son responsables de facilitar el intercambio de información entre los nodos de su cadena y los nodos de su cadena base. Esto incluye la publicación por lotes de transacciones desde su cadena Orbit a su cadena base, el replanteo de tokens por parte de los validadores de su cadena Orbit, el mecanismo de desafío, los mecanismos puente y más.

Una vez terminado esto, haga clic en Next para continuar con el siguiente paso.

8.5 Paso 4: Configure los validadores de la cadena.

Debería ver una sección llamada Configure Validators, con un formulario que se ve así:

El primer campo de entrada es un valor entero que determina la cantidad de validadores que admitirán su implementación inicial. Los campos subsiguientes le permiten especificar cada una de las direcciones de estos validadores.

La primera dirección del validador se genera aleatoriamente y no se puede cambiar. Su clave privada se generará automáticamente y se almacenará dentro de uno de los archivos de configuración JSON que se generarán en un momento.

Los validadores de su cadena son responsables de validar la integridad de las transacciones y publicar afirmaciones del estado actual de su cadena Orbit en su cadena base. En escenarios de producción, su cadena Orbit probablemente estaría alojada en una red de nodos de validación que trabajan juntos. Para su cadena Orbit local, puede ceñirse a la dirección de validación única generada automáticamente.

Cada una de las direcciones de validación especificadas en este paso se agregará a una lista de permitidos en uno de los contratos base de su cadena, lo que les permitirá validar y validar las transacciones enviadas a su cadena Orbit.

Haga clic Submit para emitir otra transacción de Arbitrum Goerli que incluya en la lista de permitidos sus direcciones de validación configuradas dentro de los contratos base de su cadena Orbit.

Una vez que se confirme esta transacción, debería ver una notificación mostrando Validator set changed! la IU del portal. Una vez finalizado esto, haga clic en Next para continuar con el siguiente paso.

8.6 Paso 5: Configure el publicador de lotes de la cadena.

Debería ver una sección llamada Configure Batch Poster, con un formulario que se ve así:

Su dirección de publicación de lotes es responsable de publicar lotes de transacciones desde su cadena Orbit a sus contratos base en su cadena base. Se generará automáticamente una dirección para usted; su clave privada se generará automáticamente y se almacenará dentro de uno de los archivos de configuración JSON que se generarán en un momento.

Haga clic en Submit para emitir la transacción final de Arbitrum Goerli que configura la dirección del publicador de lotes especificado dentro de los contratos base de su cadena Orbit.

Una vez que se confirme esta transacción, debería ver una notificación que diga Batch poster changed! en la IU del portal.

Una vez concluido esto, haga clic en Next para continuar con el siguiente paso.

NOTA: Es importante aclarar que a partir de este punto, los siguientes pasos se encuentran en construcción y serán actualizados posteriormente en su debido momento.

8.7 Paso 6: Descargue los archivos de la chain y despliegue de la misma.

Debería ver aparecer dos botones: Download Rollup JSON y Download L3Config JSON. Siga las instrucciones en la interfaz de usuario para descargar sus archivos de configuración e implementar su cadena Orbit localmente usando Docker.

1. Descargue Rollup JSON: Esto generará nodeConfig.json, que contiene la configuración del nodo de su cadena. Tenga en cuenta que esto incluye las claves privadas para su validador (staker) y el publicador de lotes, que se utilizan para firmar transacciones que publican RBlocks en los contratos base de su cadena en L2.

2. Descargue L3Config JSON: Esto generará orbitSetupScriptConfig.json, que contiene la configuración de su cadena, incluida la que admite el contrato Token Bridge.

8.8 Paso 7: Clone el repositorio de scripts de configuración y agregue sus archivos.

1. Clone el repositorio orbit-setup-script: git clone https://github.com/OffchainLabs/orbit-setup-script.git

2. Mueva el archivo nodeConfig.json que se descargó dentro directorio de la chain. En la raíz del repositorio orbit-setup-script clonado.

3. Mueva el archivo orbitSetupScriptConfig.json que descargó al directorio config. En la raíz del repositorio orbit-setup-script clonado.

4. Instale las dependencias ejecutándo yarn install desde la raíz del repositorio orbit-setup-script.

8.9 Paso 8: Ejecute el nodo de su cadena y el explorer.

Ejecute Docker, luego ejecúte docker-compose up -d desde la raíz del repositorio orbit-setup-script.

Se iniciará un nodo Nitro y una instancia del explorador BlockScout. Visite http://localhost:4000/ para acceder a su instancia de explorador de BlockScout; esto le permitirá ver las transacciones y los bloques de su cadena, lo que puede ser útil para la depuración.

8.10 Paso 9: termine de configurar su la chain.

Hemos proporcionado un script Hardhat que maneja las siguientes tareas:

1. Financiar las cuentas del publicador de lotes y validador (staker) en su cadena L2 subyacente.

2. Depositar ETH en su cuenta en la cadena utilizando el bridge recién implementado de su cadena.

3. Implementar sus Contratos Token Bridge tanto en L2 como en cadenas.

4. Configurar parámetros en la cadena.

Para ejecutar este script, emita el siguiente comando desde la raíz del repositorio orbit-setup-script, reemplazando OxYourPrivateKey con la clave privada de la cuenta Owner que usó para implementar los contratos de su cadena y reemplazando http://localhost:8449 con la URL RPC del nodo de su cadena.

PRIVATE_KEY="0xYourPrivateKey" L2_RPC_URL="https://goerli-rollup.arbitrum.io/rpc" L3_RPC_URL="http://localhost:8449" yarn run setup

🎉¡Felicitaciones!

Ahora su Orbit chain está en funcionamiento. Podrá ver un archivo outputInfo.json en el directorio principal en la carpeta script. Este contiene información sobre la chain, incluyendo las direcciones de los contratos base de la misma.

9.👨‍💻Comandos útiles.

9.1 Registros.

Ejecute el comando docker-compose logs -f nitro ,  para poder ver los registros de la cadena.

9.2 Depositar ETH.

Si necesita depositar más ETH en su validador o en las direcciones del publicador de lotes, ejecute este comando en el directorio base del script de configuración, reemplazando 0xYourPrivateKey y <AMOUNT>:

PRIVATE_KEY="0xYourPrivateKey" L2_RPC_URL="https://goerli-rollup.arbitrum.io/rpc" L3_RPC_URL="http://localhost:8449" AMOUNT="<AMOUNT>" yarn run deposit

9.3 Resolución de problemas.

Puede que se vea error getting latest batch count en los registros de salida de su nodo (Cuando se usa el comando de Registros). Por lo general, es seguro ignorarlo, ya que  se muestra cuando la implementación del contrato base de su cadena Orbit aún no ha finalizado en la cadena L1. Esta finalización puede demorar entre 15 y 20 minutos, pero no se preocupe: no es necesario que la implementación finalice en L1 para que su cadena funcione correctamente.

10.👩‍🎓Conclusión.

Arbitrum Orbit ofrece a los usuarios y desarrolladores una poderosa herramienta para crear sus propias cadenas Layer 3 (L3) en la infraestructura subyacente de las cadenas públicas de Capa 2 (L2) de Arbitrum. Estas "cadenas Orbit" proporcionan una mayor descentralización y permiten aprovechar las propiedades y supuestos de seguridad de la capa base de Ethereum.

Al permitir la configuración tanto como Arbitrum Rollup o AnyTrust, Arbitrum Orbit ofrece diversas posibilidades para los propietarios de las cadenas. Esto resuelve problemas relacionados con la alta demanda y congestión en Ethereum, brindando a los usuarios la capacidad de personalizar su privacidad, permisos, tarifas y gobernanza, entre otros aspectos.

La configuración y despliegue de una cadena Orbit se pueden realizar siguiendo una guía paso a paso, lo que facilita a los desarrolladores el proceso de creación y personalización de su propia cadena. Aunque algunos aspectos todavía están en construcción y serán actualizados en el futuro.

🫂 Agradecimientos

🎉 ¡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.

Si quieres conocer mas a fondo la tecnología detrás de Arbitrum te invitamos a leer estos artículos👇👇👇

https://mirror.xyz/layer2es.eth/L0YiPok0FymbnHZyA5GqbKL4OL0U4jBDwTuTGzD4PiE

https://mirror.xyz/layer2es.eth/InEgFG-fRvNv4LTIUSGp0vF9PTyl58AdqswqaYJYu3M

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!

La escalabilidad ha sido un desafío clave en la adopción masiva de las blockchains. A medida que la demanda de transacciones y creación de contratos inteligentes aumenta, se necesitan soluciones capaces de manejar un mayor volumen de operaciones sin comprometer la seguridad y la descentralización.

En este sentido, Arbitrum One y Arbitrum Nova se han destacado como soluciones de escalabilidad prometedoras. En este artículo, compararemos estas dos implementaciones de Arbitrum y explicaremos sus características, similitudes y diferencias.

📝 Índice

1. Capas de una Blockchain.

   1. Capa de ejecución (Execution Layer).

   2. Capa de disponibilidad de datos (Data Availability Layer).

   3. Capa de consenso (Consensus Layer).

2. Estructura.

3. Arbitrum One: Optimización de capa 2 para Ethereum.

4. Arbitrum Nova: Optimización de capa 2 para Ethereum con supuestos de confianza.

5. Similitudes y diferencias clave.

   1. Seguridad Técnica.

   2. Descentralización.

   3. Desempeño.

   4. Ecosistema.

6. Conclusión.

7. Agradecimientos.

1. 📚 Capas de una Blockchain

Para poder entender cómo están construidas Arbitrum One y Arbitrum Nova es necesario explicar cuáles son las capas de un blockchain

Para que un blockchain pueda funcionar necesita 3 Capas:

1.1 🛠 Capa de ejecución (Execution Layer)

Esta es donde se realizan las operaciones y se ejecutan los contratos inteligentes en una blockchain. Esta capa contiene el código y la lógica de las aplicaciones descentralizadas (DApps) que se ejecutan en la blockchain. Aquí es donde se procesan las transacciones y se realizan las operaciones específicas de cada blockchain, como transferencias de activos, intercambios o cualquier otra funcionalidad programable.

1.2 📑 Capa de disponibilidad de datos (Data Availability Layer)

Esta es la responsable de almacenar y distribuir los datos de la cadena de bloques. En esta capa, se almacenan todas las transacciones, bloques y otros elementos de datos necesarios para mantener el estado actual de la blockchain. La información almacenada en esta capa debe estar disponible y ser accesible para todos los participantes de la red. La capa de disponibilidad de datos garantiza la integridad y la transparencia de los datos en la blockchain.

1.3 🤝 Capa de consenso (Consensus Layer)

La capa de consenso es fundamental para el funcionamiento de una blockchain, ya que es la encargada de lograr un acuerdo entre los nodos de la red sobre el estado actual de la blockchain. En esta capa, se determina qué transacciones son válidas y se alcanza el consenso sobre la versión autorizada de la blockchain. Los algoritmos de consenso, como Prueba de Trabajo (Proof of Work), Prueba de Participación (Proof of Stake) u otros mecanismos, se utilizan en esta capa para validar las transacciones y agregar nuevos bloques a la cadena.

2. 👨‍💻 Estructura

En una blockchain descentralizada como Ethereum, con las 3 capas explicadas anteriormente trabajan juntas, suele implicar un carga computacional grande, lo cual se refleja en altas comisiones y bajas velocidades de transacción.

Ahora bien, en una blockchain la mayoría de esta carga computacional corresponde a la capa de ejecución, es por ello que las soluciones de escalabilidad modulares como los rollups, toman esta capa de ejecución la separan fuera la cadena con el objetivo de reducir la carga computacional de red y así reducir los costos al mismo tiempo que se aumenta la velocidad y cantidad de transacciones por segundo (TPS). Por otro lado, la disponibilidad de datos y consenso son aseguradas en un capa base robusta como puede ser Ethereum.

Teniendo en cuenta todo esto, podemos decir que las capas de distribuyen de la siguiente manera:

3. 🔵 Arbitrum One: Optimización de capa 2 para Ethereum

Arbitrum One es una implementación de capa 2 (layer 2) diseñada para abordar los problemas de escalabilidad en Ethereum. Es un Optimistic Rollup, cuya tecnología permite a los usuarios realizar transacciones fuera de la cadena principal de Ethereum. En lugar de ejecutar cada transacción en la blockchain principal de Ethereum, Arbitrum One agrupa varias transacciones en un solo rollo y las envía a la cadena principal para su validación. Este diseño ha demostrado tener un procesamiento más rápido y eficiente, al tiempo que mantiene la seguridad y la descentralización de la cadena de bloques subyacente, al menos desde el punto de vista teórico.

En esta solución, la capa de ejecución se encuentra dentro de la red de Arbitrum One, mientras que las capas de Disponibilidad de Datos y Consenso se encuentran en Ethereum. Se vería de la siguiente manera:

Una de las principales ventajas de Arbitrum One es su compatibilidad nativa con Ethereum. Los desarrolladores pueden utilizar las mismas herramientas y contratos inteligentes que en la cadena principal de Ethereum sin necesidad de realizar cambios significativos. Además, Arbitrum One ofrece una alta capacidad de rendimiento, lo que permite procesar miles de transacciones por segundo. Esto significa que los usuarios pueden experimentar una experiencia similar a la cadena principal de Ethereum, pero con tiempos de confirmación más rápidos y costos reducidos.

Arbitrum One fue elaborada con el objetivo de dar soporte a proyectos asociados a DeFi, ya que, al tener las capas de disponibilidad de datos y consenso en Ethereum, está hereda la seguridad directamente de la misma, lo cual es necesario debido a que los proyectos DeFi generalmente manejan grandes cantidades de recursos económicos que deben ser asegurados de la mayor forma posible.

4. 🟠 Arbitrum Nova: Optimización de capa 2 para Ethereum con supuestos de confianza

Por otro lado, Arbitrum Nova también aborda el problema de la escalabilidad en Ethereum de manera diferente que el enfoque de Arbitrum One. En esencia Arbitrum Nova es una Anytrust chain (un tipo de Optimistic Chain, según L2Beat, y dentro de la categoría semi-L2, según nuestra definición) que busca también mejorar el rendimiento de la blockchain principal de Ethereum basándose en técnicas de reducción de carga a través de la ejecución de transacciones fuera de la cadena y la mejora de la eficiencia en el uso de la L1.

En esta versión, la capa de ejecución se encuentra dentro de la red Arbitrum Nova, por su parte el consenso está asegurado en Ethereum y la capa de disponibilidad de datos se encuentra controlada con un comité de disponibilidad de datos externo (o DAC por sus siglas en inglés). Actualmente, este comité se encuentra conformado por 7 miembros al momento de redactar este artículo. Se vería de la siguiente manera:

Una de las diferencias más destacadas de Arbitrum Nova radica en su menor consumo de recursos en la red de Ethereum. Esto se traduce en una reducción de los costos de las transacciones al ocupar menos espacio en Layer 1. Sin embargo, es importante tener en cuenta que este menor costo viene acompañado de un nivel de garantías de seguridad inferior, ya que como bien se menciona, ahora estas también recaen en el comité externo de disponibilidad de datos para su apropiado funcionamiento.

En cuanto a la capa de consenso, esta depende los Data Availability Certificates (o DACert por sus siglas en inglés) los cuales son publicado en la L1. Estos certificados contienen cierta información asociada a las transacciones, como por ejemplo, los hashs, el tiempo de expiracion o la prueba de que N-1 miembros del comité han firmado o aprobado una transacción. Debido al supuesto de confianza 2 de N, el DACert constituye una prueba que de los datos del block estarán disponibles para al menos 1 miembros del comité honesto.

Es importante destacar que en el caso de que el secuenciador falle en recolectar firmas suficientes, luego de unos minutos, este abandonara la dependencia del comité, conviertiendose automaticamente en un rollup, el cual publicara toda la data directamente en la L1, como lo hace Arbitrum One.

Al igual que Arbitrum One, Arbitrum Nova también es compatible con la EVM de Ethereum, lo que facilita a los desarrolladores la adopción de la solución sin problemas.

En cuanto a la aplicación, Arbitrum Nova fue pensado en proyectos asociados a videojuegos, redes sociales  y NFTs, en donde no se busca un nivel de seguridad tan exhaustivo como en DeFi, pero permitiendo una gran velocidad y a un menor costo.

5. 👩🏽‍🤝‍🧑🏻 Similitudes y diferencias clave

Aunque tanto Arbitrum One como Arbitrum Nova tienen como objetivo abordar la escalabilidad en Ethereum, existen algunas diferencias clave entre las dos soluciones.

5.1👮‍♂️ Seguridad Técnica

• Tipo de Proving: Tanto Arbitrum One como Arbitrum Nova se usan las fraud proofs interactivas para poder resolver las disputas entre el retador y el validador.

• Tecnología: Arbitrum One utiliza el diseño de optimistic rollup para agrupar y procesar transacciones fuera de la cadena principal delegando la responsabilidad de la disponibilidad de datos a Ethereum, mientras que, Arbitrum Nova utiliza la tecnología Anytrust la cual asigna el control de la capa de disponibilidad de datos a un comité externo controlado por entidades aprobadas por la gobernanza de Arbitrum.

• Disponibilidad de datos En Arbitrum One, la capa de disponibilidad de datos se encuentra en Ethereum, lo que quiere decir que cualquiera puede participar en la validación de la cadena y garantizar su seguridad, es decir, 1 de N. Por su parte Arbitrum Nova, utiliza supuestos de confianza, en donde se confía en un comité de disponibilidad de datos finito y que actuarán honestamente.

  En un caso hipotético de que 6 de 7 miembros del comité y el Secuenciador se confabulen y empiecen a actuar maliciosamente, pueden romper la seguridad de la cadena (y, por ejemplo, robar los fondos de los usuarios); es aquí donde está el supuesto de confianza. Sin embargo, el Anytrust protocol posee un mecanismo en donde si 2 de 7 de los miembros del comité se comportan honestamente, la cadena AnyTrust cambiaría a "modo Rollup" automáticamente; es decir, que los datos se publican en L1.

5.2 🧩 Descentralización

• Operadores: Actualmente Arbitrum One esta operado por 1 Secuenciador y 13 Validadores autorizados por una whitelist. Por otro lado, Arbitrum Nova se encuentra operado por 1 secuenciador, 7 miembros de comité de disponibilidad de datos y 9 validadores autorizados.

• Actualizable: Los contratos inteligentes (tanto para Arbitrum One como Arbitrum Nova) pueden ser actualizadas por la gobernanza de Arbitrum o el Security Council. Esto implica que ambas arquitecturas pueden modificarse en un futuro, siendo útil para implementar mejoras y resolver bugs, pero supone un punto de centralización importante.

5.3 📈 Desempeño

• Compatibilidad: Ambas soluciones son compatibles con Ethereum y permiten a los desarrolladores utilizar las mismas herramientas y desplegar contratos inteligentes tal y como suele hacerse en la red principal de Ethereum.

• Costos: Arbitrum One es mucho más caro que Arbitrum Nova, ya que utiliza más la red de Ethereum al tener las capas de consenso y disponibilidad de datos en la misma. Mientras que Arbitrum Nova solo utiliza Ethereum para asegurar el consenso nada más.

5.4 🌳 Ecosistema

• Aplicación: Arbitrum One fue diseñado para proyectos de DeFi, debido a su mayor seguridad. Mientras que Arbitrum Nova, fue desarrollado principalmente para juegos, redes sociales y NFTS, en donde la seguridad es importante pero no tan demandante como en DeFi.

• TPS actual: La TPS de Arbitrum se ajusta dependiendo del sistema de Arbitrum Nitro. Para Arbitrum One el TPS es de aproximadamente 5.18 y para Arbitrum Nova 1.4 (al momento de redactar este artículo).

A Continuación, presentamos una tabla comparativa que resume todos los datos explicados anteriormente:

6. 👨‍🎓 Conclusión

Tanto Arbitrum One como Arbitrum Nova son soluciones prometedoras para abordar el desafío de la escalabilidad en Ethereum. Arbitrum One ofrece una solución de capa 2 mediante la tecnología de los optimistic rollups. Es compatible con Ethereum y hereda la seguridad de la misma, lo cual es esencial para aquellos proyectos DeFi que manejan grandes cantidades de fondos y requieren una seguridad eficiente y robusta como pieza fundamental

Por su parte, Arbitrum Nova utiliza la tecnológica Anytrust la cual se enfoca en el uso de un comité de disponibilidad de datos para segurar la red. Arbitrum Nova tiene menos garantías de seguridad en comparación a Arbitrum One, pero tiene menores costos, lo cual es ideal para proyectos como juegos, redes sociales y NFTs, que no requieren una seguridad tan robusta como el DeFi.

La elección entre las dos soluciones dependerá de las necesidades y objetivos específicos de cada proyecto. Sin embargo, ambas opciones brindan mejoras significativas en términos de rendimiento y escalabilidad, allanando el camino para una adopción más amplia de las aplicaciones descentralizadas basadas en Ethereum.

🫂 Agradecimientos

🎉 ¡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.

Si quieres conocer mas a fondo la tecnología detrás de Arbitrum te invitamos a leer este artículo👇👇👇

https://mirror.xyz/layer2es.eth/L0YiPok0FymbnHZyA5GqbKL4OL0U4jBDwTuTGzD4PiE

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!

El 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, explicaremos en detalle qué es Arbitrum, cómo funciona su rollup optimista y cómo se lleva a cabo el proceso de transacciones en el mismo.

Índice.

1. ¿Qué es Arbitrum?.

2. ¿Qué es un Rollup?.

3. ¿Qué es un Optimistic Rollup?.

4. Ciclo de vida de una transacción en Arbitrum.

5. El Secuenciador.

   1. Flujo de trabajo del Secuenciador.

   2. Core Inbox.

   3. Caso Feliz/Común.

   4. Caso Infeliz/Inusual.

6. ArbOS.

7. Mensajes entre L1 Y L2.

   1. Contratos L1 pueden enviar transacciones a L2.

   2. Transacciones basadas en tickets de L1 a L2.

   3. Llamadas basadas en tickets de L2 a L1.

8. Gas.

9. El límite de velocidad.

10. Tarifas.

    1. Tarifas de gas de L2.

    2. Tarifas de calldata de L1.

11. Nodos validadores.

12. Desafíos.

    1. Protocolo de Disección: Versión Simplificada.

    2. ¿Por qué la Disección Identifica Correctamente a un actor malicioso?.

    3. El Protocolo Real de Disección.

    4. Prueba de un Paso (One Step Proofs).

    5. Eficiencia.

13. Arbitrum Bridge.

    1. Depósito y Retiro de Ether (ETH).

    2. Depósito y Retiro de ERC-20 tokens.

    3. Tipo de Diseño.

    4. Implementación canónica L2 por contrato de token L1.

    5. Implementación del puente canónico de tokens.

    6. Puente estándar por defecto.

    7. Ejemplo: Depósito/retirada de Arb-ERC20 estándar.

    8. La Gateway personalizada genérica de Arbitrum.

    9. Configuración del token con la Gateway personalizada genérica

14. Conclusión.

1.🤷‍♂️¿Qué es Arbitrum?.

Arbitrum es una solución de capa 2, creada por OffChain Labs para agregar escalabilidad a la red Ethereum. Esto significa que al utilizar Arbitrum, los usuarios pueden realizar transacciones en Ethereum de manera más rápida y económica

La plataforma se compone de dos redes diferentes: Arbitrum One y Arbitrum Nova. Arbitrum One es la red original enfocada en aplicaciones de finanzas descentralizadas (DeFi) y es la que utiliza la tecnología de los "Optimistic Rollups” (o “Rollups Optimistas”).

Por otro lado, Arbitrum Nova está dirigida al mundo de los juegos descentralizados (GameFi) y las aplicaciones sociales. Mientras que Arbitrum One implementa el protocolo Rollup, Arbitrum Nova implementa el protocolo AnyTrust. La diferencia clave entre los protocolos Rollup y AnyTrust es que este último introduce un supuesto de confianza adicional en forma de comité de disponibilidad de datos (DAC).

2.⛓¿Qué es un Rollup?.

Los Rollups son una solución de Capa 2 que agrupa o “enrolla” (de allí viene su nombre) los datos de varias transacciones y los transfiere fuera de la cadena principal (es decir offchain). En un rollup, la ejecución de las transacciones se realiza fuera de la cadena principal, mientras que los activos se mantienen en un contrato inteligente en la cadena. Una vez completada la transacción, los datos se envían de vuelta a la cadena principal.

Las principales ventajas que tiene este sistema son:

1. Eficiencia en transacciones: Los rollups permiten aumentar la eficiencia en el procesamiento de transacciones al agrupar múltiples transacciones en un solo bloque, lo que aumenta significativamente la capacidad de procesamiento de la blockchain. Esto resulta en una mayor velocidad de confirmación de las transacciones y una reducción de los costos de gas.

2. Escalabilidad: Al trasladar gran parte de la carga de trabajo fuera de la cadena principal (Capa 1), los rollups permiten que la cadena de bloques maneje un mayor número de transacciones sin comprometer su rendimiento. Esto es especialmente importante en cadenas de bloques con alta demanda y congestión.

3. Costos reducidos: Al realizar la mayor parte del procesamiento de transacciones fuera de la cadena principal, los rollups pueden reducir significativamente los costos asociados con las transacciones en la cadena de bloques. Esto hace que las transacciones sean más asequibles para los usuarios y fomenta la adopción masiva.

4. Interoperabilidad: Los rollups pueden ser utilizados en diferentes cadenas de bloques, lo que permite la interoperabilidad entre ellas. Esto significa que los activos pueden moverse y ser utilizados en diferentes cadenas de bloques sin problemas, lo que amplía las posibilidades y casos de uso.

5. Flexibilidad en las funcionalidades: Los rollups pueden implementar diferentes funcionalidades y características, como contratos inteligentes, sin necesidad de que estén soportadas directamente en la cadena de bloques principal. Esto permite una mayor flexibilidad y personalización en el desarrollo de aplicaciones descentralizadas (dApps).

3.✅¿Qué es un Optimistic Rollup?.

En un Optimistic Rollup, la mayoría de las operaciones y cálculos se realizan fuera de la cadena principal (Capa 1), al igual que en otros tipos de Rollups. Sin embargo, los Rollups Optimistas utilizan un enfoque basado en la presunción de validez de las transacciones. Es decir se asume un ambiente o conducta optimista por parte de todos los participantes.

En lugar de verificar cada transacción de forma exhaustiva en la cadena principal, un Rollup Optimista permite que las transacciones se ejecuten y se incluyan rápidamente en la cadena de bloques de Layer 2. Sin embargo, en lugar de proporcionar pruebas criptográficas de validez en cada transacción, se confía en que los participantes actuaran correctamente y no intentaran realizar actividades maliciosas.

La verificación de las transacciones se realiza de manera retroactiva y periódica, generalmente a través de un mecanismo llamado "periodo de desafío" que dura 7 días. Durante este período, cualquier participante de la cadena puede presentar una prueba de fraude en donde se compruebe que una transacción es inválida y así cuestionar su validez. Si esta prueba de fraude es aprobada, entonces se pueden aplicar sanciones o penalizaciones a los validadores involucrados que aprobaron la transacción errónea, como la pérdida de fondos o garantías depositadas.

De esta manera, se logra que los validadores de las transacciones se comporten de manera correcta, ya que en caso de ser descubiertos en actos maliciosos serán castigados retirándoles todos sus fondos stakeados.

4.📝Ciclo de vida de una transacción en Arbitrum.

1. Las transacciones son recibidas por el Secuenciador, quien las ordena para formar un lote de transacciones.

2. Luego este lote se publica en Ethereum dentro de un contrato inteligente en L1.

3. Después, un nodo validador leerá los datos de este lote y las procesa localmente en su copia del estado L2.

4. Una vez procesadas, se genera localmente un nuevo estado L2 y el validador publicará esta nueva raíz de estado en un contrato inteligente en L1.

5. A continuación, todos los demás validadores procesarán las mismas transacciones en sus copias locales del estado L2 y compararán su raíz de estado L2 resultante con la original publicada en el contrato inteligente L1.

6. Los validadores tienen un período de tiempo determinado (7 días) para reportar cualquier fraude en la raíz de estado.

7. Si uno de los validadores obtiene una raíz de estado diferente a la publicada en L1, iniciará un desafío. El desafío requerirá que el retador y el validador que publicó la raíz de estado original se turnen para demostrar cuál debería ser la raíz de estado correcta.

8. El usuario que pierda el reto, perderá su depósito inicial (Stake). Mientras que, si la raíz de estado L2 original publicada que no era válida, será destruida por futuros validadores y no se incluirá en la cadena L2.

9. Por otro lado, si no se reporta fraude durante el período de tiempo determinado (7 días), el estado del rollup es considerado finalizado en su totalidad, habilitando al puente completar transacciones de retiro incluidas dentro del ciclo.

En el siguiente diagrama se puede visualizar estos pasos:

5.👮‍♂️El Secuenciador.

El Sequencer (o Secuenciador) es un nodo completo de Arbitrum especialmente designado que, en condiciones normales, es responsable de enviar las transacciones de los usuarios a L1. En principio, el Sequencer de una cadena puede adoptar diferentes formas; tal como está configurado Arbitrum One actualmente, el Sequencer es una entidad única y centralizada; eventualmente, se podrían otorgar capacidades de secuenciación a un comité distribuido de secuenciadores que lleguen a un consenso sobre el orden. Sin embargo, independientemente de su forma, el Sequencer tiene una limitación fundamental que no se aplica a ninguna otra parte del sistema: debe operar bajo sus propias suposiciones de seguridad, es decir, en principio no puede obtener seguridad directamente desde la capa 1 (en este caso Ethereum). Esto plantea la pregunta de cómo Arbitrum mantiene su capacidad de resistencia a la censura en caso de que el Sequencer se comporte de manera incorrecta.

Por ello arbitrum creó una vía alterna que permite evitar por completo al Sequencer para enviar cualquier transacción de Arbitrum (incluyendo una que, por ejemplo, inicie un mensaje de L2 a L1 para retirar fondos) directamente desde la capa 1. Este mecanismo preserva la resistencia a la censura incluso si el Sequencer no responde en absoluto o incluso si actúa de manera maliciosa.

5.1 Flujo de trabajo del Secuenciador.

Primero, el usuario crea una transacción, la firma utilizando su billetera y la envía al Sequencer. El trabajo del Sequencer, como su nombre indica, es tomar las transacciones que llegan, colocarlas en una secuencia ordenada y publicar esa secuencia.

Una vez que las transacciones están secuenciadas, se ejecutan a través de la función de transición de estado, una por una, en orden. La función de transición de estado toma como entrada el estado actual de la cadena (saldos de cuentas, código de contrato, etc.) junto con la siguiente transacción. Actualiza el estado y, a veces, emite un nuevo bloque de Capa 2 en la cadena.

Dado que el protocolo no confía en que el Sequencer no inserte basura en su secuencia, la función de transición de estado detectará y descartará cualquier transacción inválida (por ejemplo, mal formada) en la secuencia. Un Sequencer bien comportado filtrará las transacciones inválidas para que la función de transición de estado nunca las vea, lo que reduce los costos y mantiene bajas las tarifas de transacción. Sin embargo, este mecanismo seguirá funcionando correctamente independientemente de lo que el Sequencer incluya en su secuencia. (Las transacciones en la secuencia están firmadas por sus remitentes, por lo que el Sequencer no puede crear transacciones falsificadas).

La función de transición de estado es determinista, lo que significa que su comportamiento depende únicamente del estado actual y del contenido de la próxima transacción, y nada más. Debido a este determinismo, el resultado de una transacción T dependerá únicamente del estado inicial de la cadena, las transacciones anteriores a T en la secuencia y T misma.

Cualquier persona que conozca la secuencia de transacciones puede calcular la función de transición de estado por sí misma, y todas las partes honestas que lo hagan están garantizadas de obtener resultados idénticos. Esta es la forma normal en que operan los nodos en arbitrum: obtienen la secuencia de transacciones y ejecutan la función de transición de estado localmente. No se necesita un mecanismo de consenso para esto.

5.2 Core Inbox.

Cuando hablamos de "enviar una transacción a una cadena de Arbitrum", nos referimos a incluirla en la Core Inbox de la cadena. Una vez que las transacciones se incluyen en la Core Inbox, su ordenamiento queda establecido, la ejecución es completamente determinista y podemos considerar el estado resultante como finalizado en el nivel L1. El rol del Sequencer, o su falta de él, se limita estrictamente a lo que ocurre antes, es decir, cómo una transacción que llega a la Core Inbox.

Hay dos posibles rutas que una transacción puede seguir en dos escenarios diferentes: cuando hay un Sequencer que funciona correctamente (Caso Feliz/Común) y cuando hay un Sequencer defectuoso (Caso Infeliz/Raro).

5.3 Caso Feliz/Común.

Sequencer está activo y se comporta correctamente, partimos del supuesto de que el Sequencer está totalmente operativo y funciona con la intención de procesar las transacciones de los usuarios de la manera más segura y oportuna posible. El Sequencer puede recibir una transacción del usuario de dos formas: directamente mediante una solicitud RPC o a través de una L1 subyacente.

Si un usuario está enviando una transacción de Arbitrum "estándar" (es decir, interactuando con una aplicación nativa de L2), el usuario enviará la transacción firmada directamente al Sequencer, de manera similar a cómo un usuario envía una transacción a un nodo de Ethereum al interactuar con L1. Al recibirlo, el Sequencer lo ejecutará y entregará al usuario un receipt casi instantáneamente. Un corto tiempo después, generalmente no más de unos minutos, el Sequencer incluirá la transacción del usuario en un batch (o lote en español) y la publicará en L1 llamando a la función “addSequencerL2Batch” de la Core Inbox. Hay que destacar que solo el Sequencer tiene la autoridad para llamar a esta función; esta garantía de que ninguna otra parte puede incluir un mensaje directamente es, de hecho, lo que le da al Sequencer la capacidad única de proporcionar receipts instantáneos de "confirmación suave". Una vez publicadas en un batch, las transacciones tienen finalidad a nivel de L1.

Alternativamente, un usuario puede enviar su mensaje de L2 publicándolo en la L1 subyacente. Esta ruta es necesaria si el usuario desea realizar alguna operación en L1 junto con el mensaje de L2 y preservar la atomicidad entre ambos. El ejemplo típico aquí es un depósito de tokens a través de un bridge (es decir, poner una garantía en L1, y se mintearla en L2). El usuario lo hace publicando una transacción de L1 (es decir, enviando una transacción normal a un nodo de L1) que llama a uno de las funciones relevantes en el contrato Inbox, por ejemplo, “sendUnsignedTransaction”. Esto agrega un mensaje a lo que llamaremos delayed inbox (representada por delayedInboxAccs en el contrato Bridge), que es efectivamente una cola en la que los mensajes esperan antes de ser movidos a la Core Inbox. El Sequencer emitirá un receipt de L2 aproximadamente 10 minutos después de que la transacción se haya incluido en la delayed inbox (el motivo de este retraso es minimizar el riesgo de reorganizaciones tanto en L1 como en L2 que pueden invalidar los receipt de L2 del Sequencer). Nuevamente, el último paso es que el Sequencer incluya el mensaje de L2 en un batch, especificando cuántos mensajes de la delayed inbox se deben incluir, finalizando así la transacción.

En resumen, en cualquiera de los casos felices, el usuario primero entrega su mensaje al Sequencer, el cual se asegura de que llegue a la Core Inbox.

5.4 Caso Infeliz/Inusual.

Supongamos ahora que el Sequencer, por alguna razón, no está llevando a cabo su tarea de enviar mensajes. Aún así, un usuario puede lograr que su transacción se incluya en dos pasos:

Primero, envía su mensaje de L2 a través de L1 a la delayed inbox como se describió anteriormente. Es importante destacar que, aunque los mensajes atómicos (es decir, mensajes rápidos) entre cadenas son el caso común para usar la delayed inbox, en principio se puede utilizar para enviar cualquier mensaje de L2.

Una vez en la delayed inbox, obviamente no podemos confiar en el Sequencer para incluir la transacción en un lote. En su lugar, podemos utilizar la función “forceInclusion” de la Core Inbox. Una vez que un mensaje ha estado en la delayed inbox durante un tiempo suficiente, se puede llamar a forceInclusion para moverlo de la delayed inbox a la Core Inbox, momento en el cual se finaliza. Es crucial destacar que cualquier cuenta usuario puede llamar a la función “forceInclusion”.

Actualmente, en Arbitrum One, el tiempo de retraso entre el envío y la inclusión forzada es aproximadamente de 24 horas. Una inclusión forzada desde L1 afectaría directamente el estado de cualquier transacción de L2 no confirmada; al mantener un valor de retraso alto de manera conservadora, se asegura que solo se utilice en circunstancias extraordinarias. Además del retraso en sí, la ruta de inclusión forzada tiene la desventaja de la incertidumbre en cuanto al ordenamiento de las transacciones. Mientras se espera a que pase el retraso máximo de un mensaje, un Sequencer malintencionado podría, en principio, publicar directamente mensajes delante de él. Sin embargo, en última instancia, no hay nada que el Sequencer pueda hacer para evitar que se incluya en la Core Inbox, momento en el cual se fija su ordenamiento.

Si bien la ruta lenta e "infeliz" no es óptima y rara vez, o nunca, debería ser necesaria, su disponibilidad como opción garantiza que el Rollup de Arbitrum siempre preserve su modelo de seguridad trustless, incluso si las partes con permisos del sistema se comportan de manera defectuosa.

6.💻ArbOS.

El ArbOS es un componente confiable que actúa como un "pegamento del sistema" que se ejecuta en la Capa 2 como parte de la Función de Transición de Estado. ArbOS está diseñado para proporcionar funciones necesarias para un sistema de Capa 2, como la comunicación entre cadenas, la contabilidad de recursos y la economía de tarifas relacionadas con la Capa 2, y la gestión de cadenas.

El ArbOS existe principalmente porque tiene la capacidad de realizar de manera confiable, rápida y económica una gran parte del trabajo que anteriormente se realizaba en la Capa 1 (L1). El soporte de estas funciones en un software confiable de Capa 2, en lugar de incorporarlas en las reglas impuestas por la Capa 1, como lo hace Ethereum, ofrece ventajas significativas en costos, ya que estas operaciones pueden beneficiarse del menor costo de cómputo y almacenamiento en la Capa 2, en lugar de tener que gestionar esos recursos como parte de un contrato de Capa 1.

Tener un sistema operativo confiable en la Capa 2 también tiene ventajas significativas en flexibilidad, ya que el código de la Capa 2 es más fácil de evolucionar o personalizar para una cadena en particular, en comparación con una arquitectura impuesta por la Capa 1.

7.🎫Mensajes entre L1 Y L2.

7.1 Contratos L1 pueden enviar transacciones a L2

Un contrato en L1 tiene la capacidad de enviar una transacción a L2 de forma similar a un usuario, utilizando la llamada al contrato "inbox" en la cadena de Ethereum. Sin embargo, el resultado de esta transacción de L2 no estará disponible para el llamador en L1. Aunque la transacción se ejecutará en L2, el llamador en L1 no podrá ver los resultados.

La ventaja de este enfoque es su simplicidad y baja latencia. No obstante, la desventaja, en comparación con el otro método que se describirá pronto, es que la transacción de L2 podría revertirse si el llamador en L1 no especifica correctamente el precio del gas y la cantidad máxima de gas de L2. Dado que el llamador en L1 no puede ver el resultado de la transacción de L2, no puede estar seguro de que la transacción en L2 será exitosa.

Este escenario puede generar problemas significativos para ciertos tipos de interacciones entre L1 y L2. Por ejemplo, consideremos una transacción que involucra el depósito de un token en L1 para que esté disponible en una dirección de L2. Si la parte en L1 tiene éxito pero la parte en L2 se revierte, los tokens enviados al contrato "inbox" en L1 no se pueden recuperar ni en L2 ni en L1. Esta situación es claramente indeseable.

7.2 Transacciones basadas en tickets de L1 a L2.

Afortunadamente, existe un método alternativo para las llamadas de L1 a L2 que es más robusto ante problemas relacionados con el gas. Este método utiliza un sistema basado en tickets.

La idea principal es que un contrato de L1 puede enviar una transacción "reintentable" a la cadena. La cadena intentará ejecutar esta transacción y, si tiene éxito, no se requerirá ninguna acción adicional. Sin embargo, si la transacción falla, se generará un "ticketID" que identifica esa transacción fallida. Posteriormente, cualquier persona puede llamar a un contrato especial precompilado en L2, proporcionando el ticketID, con el fin de intentar redimir el ticket y volver a ejecutar la transacción.

Cuando se guarda una transacción para reintentar, se registra la dirección del remitente, la dirección de destino, el valor y los datos de la llamada. Todos estos detalles se almacenan, y el valor de la llamada se deduce de la cuenta del remitente y se "adjunta" lógicamente a la transacción guardada. Si el redimir tiene éxito, la transacción se completa, se emite un recibo y el ticketID se cancela, quedando inutilizable. Sin embargo, si el redimir falla, por ejemplo, porque la transacción empaquetada falla, se informará del fallo del redimir y el ticketID seguirá disponible para su redención.

Normalmente, el remitente original intentará que su transacción tenga éxito de inmediato, por lo que nunca será necesario registrarla ni reintentarla. Por ejemplo, en el caso de nuestro ejemplo de "depósito de tokens", en la situación ideal y común, solo se requerirá una única firma del usuario. Si esta ejecución inicial falla, el ticketID seguirá existiendo como una medida de respaldo que otros pueden redimir más adelante.

El envío de una transacción de esta manera tiene un costo en ETH que el remitente debe pagar, y este costo varía según el tamaño de los datos de la llamada de la transacción. Una vez enviada, el ticket es válido durante aproximadamente una semana. Si el ticket no se ha redimido durante ese período, se eliminará.

Cuando se redime el ticket, la transacción preempaquetada se ejecuta con el remitente y el origen siendo iguales al remitente original, y con el destino, el valor y los datos de la llamada proporcionados por el remitente en el momento del envío.

Este mecanismo es un poco más complejo que las transacciones habituales de L1 a L2, pero tiene la ventaja de que el costo de envío es predecible y el ticket estará siempre disponible para su redención si se paga el costo de envío. Mientras haya algún usuario dispuesto a redimir el ticket, la transacción de L2 podrá ejecutarse eventualmente y no se perderá de forma silenciosa.

7.3 Llamadas basadas en tickets de L2 a L1.

Las llamadas de L2 a L1 operan de manera similar, utilizando un sistema basado en tickets. Cuando un contrato de L2 desea enviar una transacción a L1, puede llamar a una función del contrato precompilado ArbSys. Después de que la transacción de L2 se confirma y se ejecuta en L1 (por lo general, después de algunos días), se genera un ticket en el contrato de salida (outbox) de L1. Cualquier persona puede activar este ticket llamando a una función específica del contrato de salida de L1 y proporcionando el ID del ticket correspondiente. El ticket se marca como redimido sólo si la transacción de L1 se completa sin revertirse.

Estos tickets de L2 a L1 no tienen una limitación de tiempo y permanecen válidos hasta que se redimen exitosamente. No se requiere ningún pago de almacenamiento, ya que los tickets (representados por un hash en Merkle tree de tickets) se registran en el almacenamiento de Ethereum, el cual no implica ningún costo de almacenamiento. Los gastos asociados con el almacenamiento de las raíces de Merkle de los tickets están cubiertos por las tarifas de transacción de L2.

8.⛽Gas.

NitroGas (llamado así para evitar confusiones con el gas de Ethereum en la Capa 1) se utiliza en Arbitrum para rastrear el costo de ejecución en una cadena Nitro. Funciona de manera similar al gas en Ethereum, en el sentido de que cada instrucción EVM tiene un costo de gas igual al que tendría en Ethereum.

9.🛑El límite de velocidad.

La seguridad de las cadenas Nitro depende de la suposición de que cuando un validador crea un RBlock (es decir un block en el Rollup), otros validadores lo verificarán y responderán con un RBlock correcto y un desafío si está equivocado. Esto requiere que los demás validadores tengan el tiempo y los recursos necesarios para verificar cada RBlock lo suficientemente rápido como para emitir un desafío oportuno. El protocolo Arbitrum tiene esto en cuenta al establecer plazos para los RBlocks.

Esto establece un límite de velocidad efectivo en la ejecución de una cadena Nitro: a largo plazo, la cadena no puede avanzar más rápido de lo que un validador puede emular su ejecución. Si los RBlocks se publican a una velocidad más rápida que el límite de velocidad, sus plazos se alejarán cada vez más en el futuro. Debido al límite, impuesto por los contratos del protocolo de rollup, de cuán lejos en el futuro puede estar un plazo, esto eventualmente ralentizará los nuevos RBlocks, lo que impondrá el límite de velocidad efectivo.

Poder establecer el límite de velocidad de manera precisa depende de poder estimar el tiempo requerido para validar un RBlock, con cierta precisión. Cualquier incertidumbre en la estimación del tiempo de validación nos obligará a establecer un límite de velocidad más bajo para estar seguros. Y no queremos establecer un límite de velocidad más bajo, así que tratamos de permitir una estimación precisa.

10.💸Tarifas.

Las transacciones de los usuarios pagan tarifas para cubrir el costo de operar la cadena. Estas tarifas son evaluadas y recolectadas por ArbOS en L2. Están denominadas en ETH. Se cobran tarifas por dos recursos que una transacción puede utilizar:

10.1 Tarifas de gas de L2.

Las tarifas de gas de L2 funcionan de manera muy similar al gas en Ethereum. Una transacción utiliza una cierta cantidad de gas, y esto se multiplica por la tarifa base de L2 para obtener la tarifa de gas de L2 cobrada a la transacción.

La tarifa base de L2 se establece mediante una versión del "mecanismo exponencial" que se ha discutido ampliamente en la comunidad de Ethereum y que se ha demostrado equivalente al mecanismo de fijación de precios de gas EIP-1559 de Ethereum.

El algoritmo compara el uso de gas con un parámetro llamado "límite de velocidad", que es la cantidad objetivo de gas por segundo que la cadena puede manejar de manera sostenible a lo largo del tiempo. (Actualmente, el límite de velocidad es de 7 millones de gas por segundo). El algoritmo realiza un seguimiento de un saldo de gas pendiente. Cada vez que una transacción consume gas, ese gas se agrega al saldo pendiente. Cada vez que el reloj avanza un segundo, se resta el límite de velocidad del saldo pendiente, pero el saldo pendiente nunca puede ser inferior a cero.

De manera intuitiva, si el saldo pendiente aumenta, el algoritmo debe aumentar el precio del gas para reducir el uso de gas, porque el uso está por encima del nivel sostenible. Si el saldo pendiente disminuye, el precio debería disminuir nuevamente porque el uso ha estado por debajo del límite sostenible, por lo que se puede dar la bienvenida a un mayor uso de gas.

Para hacer esto más preciso, la tarifa base es una función exponencial del saldo pendiente, F = exp(-a(B-b)), donde a y b son constantes adecuadamente elegidas: “a” controla la rapidez con la que el precio aumenta con el saldo pendiente, y “b” permite un saldo pendiente pequeño antes de que comience la escalada de la tarifa base.

10.2 Tarifas de calldata de L1.

Las tarifas de calldata de L1 se aplican sólo si una transacción entra en L2 a través del Sequencer (es decir, no se recibe a través de una transacción L2 a L2). Estas tarifas se pagan al Sequencer y cubren los costos de operar el Sequencer y mantener la sincronización con L1.

La tarifa se basa en el tamaño del calldata de L1 de la transacción. Hay una tarifa base por unidad de calldata, y la tarifa total se calcula multiplicando la tarifa base por el tamaño del calldata.

Es importante tener en cuenta que estas tarifas no se pagan a los validadores de L2. Los validadores reciben recompensas de validación separadas que provienen del contrato ArbRewarder y están diseñadas para incentivar la validación en lugar de las tarifas de transacción.

11.🕵️‍♂️Nodos validadores.

Algunos nodos de Arbitrum optarán por actuar como validadores. Esto significa que supervisan el progreso del protocolo de rollup y participan en ese protocolo para avanzar el estado de la cadena de manera segura.

No todos los nodos elegirán hacer esto. Debido a que el protocolo de rollup no decide lo que hará la cadena, sino que simplemente confirma el comportamiento correcto que está completamente determinado por los mensajes del inbox, un nodo puede ignorar el protocolo de rollup y simplemente calcular por sí mismo el comportamiento correcto.

Cada validador puede elegir su propio enfoque, pero esperamos que los validadores sigan tres estrategias comunes:

La estrategia del validador activo intenta avanzar el estado de la cadena proponiendo nuevos RBlocks. Un validador activo siempre tiene un stake, ya que crear un RBlock requiere tener uno. Una cadena realmente sólo necesita un validador activo honesto; tener más es un uso ineficiente de recursos. Para la cadena Arbitrum One, Offchain Labs ejecuta un validador activo.

La estrategia del validador defensivo observa el funcionamiento del protocolo de rollup. Si solo se proponen RBlocks correctos, esta estrategia no realiza stake. Pero si se propone un RBlock incorrecto, esta estrategia interviene publicando un RBlock correcto o haciendo stake en un RBlock correcto que otra parte haya publicado. Esta estrategia evita los stakes cuando las cosas van bien, pero si alguien es deshonesto, realiza una stake para defender el resultado correcto.

La estrategia del validador de vigilancia nunca realiza stakes. Simplemente observa el protocolo de rollup y si se propone un RBlock incorrecto, da la alarma (por los medios que elija) para que otros puedan intervenir. Esta estrategia asume que otras partes disponibles a hacer stake estarán dispuestas a intervenir para tomar parte de la apuesta del proponente deshonesto, y que esto puede suceder antes de que expire el plazo del RBlock deshonesto.

(En la práctica, esto permitirá varios días para una respuesta).

En condiciones normales, los validadores que utilizan las estrategias defensivas y de vigilancia no harán nada más que observar. Un actor malicioso que esté considerando hacer trampa no podrá saber cuántos validadores defensivos y de vigilancia están operando de incógnito. Quizás algunos validadores defensivos se anuncien, pero otros probablemente no lo hagan, por lo que un posible atacante siempre tendrá que preocuparse de que los defensores estén esperando para aparecer.

12.⚔Desafíos.

Para poder entender cómo funciona el sistema de desafíos en arbitrum, usaremos el siguiente ejemplo:

Los RBlocks 93 y 95 son hermanos (ambos tienen 92 como predecesor). Alice tiene un stake en el Rblock 93 y Bob tiene una stake en el Rblock 95.

En este punto, sabemos que Alice y Bob no están de acuerdo sobre la corrección del RBlock 93, ya que Alice está convencida de que el 93 es correcto, mientras que Bob está convencido de que el 93 es incorrecto. (Bob tiene una stake en el bloque 95, que implícitamente afirma que el 92 es el último RBlock correcto antes que él, lo que implica que el 93 debe ser incorrecto).

Cuando dos participantes tienen stakes en RBlocks hermanos y ninguno de ellos está desafiando actualmente, cualquier persona puede iniciar un desafío entre los dos. El protocolo de agregación de transacciones registrará el desafío y actuará como árbitro, declarando eventualmente un ganador y confiscando el stake del perdedor. El perdedor será eliminado como staker.

El desafío es un juego en el que Alice y Bob se turnan para hacer movimientos, con un contrato de Ethereum como árbitro. Alice, como defensora, comienza primero.

El juego consta de dos fases: El protocolo de disección y prueba de un solo paso (o one-step proof en inglés). La fase de disección reducirá el tamaño de la disputa hasta que se trate de una disputa sobre una sola instrucción de ejecución. Luego, la prueba de un solo paso determinará quién tiene razón en esa instrucción en particular.

Describiremos dos veces la parte de la disección del protocolo. Primero, explicaremos una versión simplificada que es más fácil de entender pero menos eficiente. Luego, describiremos cómo difiere la versión real de la simplificada.

12.1 Protocolo de Disección: Versión Simplificada.

Alice está defendiendo la afirmación de que, comenzando con el estado en el RBlock predecesor, la Máquina Virtual puede avanzar al estado especificado en el RBlock A. Básicamente, está afirmando que la Máquina Virtual puede ejecutar N instrucciones, y que esa ejecución consumirá M mensajes de el inbox y transformará el hash de las salidas de H' a H.

El primer movimiento de Alice requiere que ella divida sus afirmaciones sobre los estados intermedios entre el inicio (0 instrucciones ejecutadas) y el final (N* instrucciones ejecutadas*). Por lo tanto, requerimos que Alice divida su afirmación por la mitad y publique el estado en el punto intermedio, después de que se hayan ejecutado N/2 instrucciones.

Ahora Alice ha dividido efectivamente su afirmación de N pasos en dos afirmaciones de (N/2) pasos. Bob tiene que señalar una de esas dos afirmaciones de tamaño reducido y afirmar que es incorrecta.

En este punto, estamos básicamente en la situación original: Alice ha hecho una afirmación con la que Bob no está de acuerdo. Pero hemos reducido el tamaño de la afirmación a la mitad, de N a N/2. Podemos aplicar el mismo método nuevamente, con Alice dividiendo y Bob eligiendo una de las mitades, para reducir el tamaño a N/4. Y podemos continuar dividiendo por la mitad, de acuerdo con lo cual, después de un número logarítmico de rondas, Alice y Bob estarán en desacuerdo sobre un solo paso de ejecución. Ahí es donde termina la fase de disección del protocolo y Alice debe presentar una prueba de un solo paso que será verificada por el EthBridge.

12.2 ¿Por qué la Disección Identifica Correctamente a un actor malicioso?.

Antes de hablar sobre las complejidades del protocolo real de desafío, detengámonos a comprender por qué la versión simplificada del protocolo es correcta. La corrección implica dos cosas:

• (1) si la afirmación inicial de Alice es correcta, Alice siempre puede ganar el desafío.

• (2) si la afirmación inicial de Alice es incorrecta, Bob siempre puede ganar el desafío.

Para demostrar (1), observa que si la afirmación inicial de Alice es correcta, ella puede ofrecer una afirmación veraz del punto intermedio y ambas afirmaciones de tamaño reducido implicadas serán correctas. Por lo tanto, sin importar a cuál de las dos mitades se oponga Bob, Alice estará nuevamente en la posición de defender una afirmación correcta. En cada etapa del protocolo, Alice estará defendiendo una afirmación correcta. Al final, Alice tendrá una afirmación correcta de un solo paso que probar, por lo que esa afirmación será demostrable y Alice puede ganar el desafío.

Para demostrar (2), observa que si la afirmación inicial de Alice es incorrecta, esto solo puede deberse a que su punto final afirmado después de N pasos es incorrecto. Ahora, cuando Alice ofrece su afirmación del estado intermedio, esa afirmación puede ser correcta o incorrecta. Si es incorrecta, Bob puede desafiar la afirmación de la primera mitad de Alice, que será incorrecta. Si la afirmación de Alice sobre el estado intermedio es correcta, entonces su afirmación de la segunda mitad debe ser incorrecta, por lo que Bob puede desafiar eso. Entonces, pase lo que pase, Bob podrá desafiar una afirmación incorrecta de tamaño reducido. En cada etapa del protocolo, Bob puede identificar una afirmación incorrecta para desafiar. Al final, Alice tendrá una afirmación incorrecta de un solo paso que probar, lo cual no podrá hacer, por lo que Bob puede ganar el desafío.

(Si eres exigente con la precisión matemática, debería estar claro cómo estos argumentos pueden convertirse en pruebas mediante inducción sobre N).

12.3 El Protocolo Real de Disección.

El protocolo real de disección es conceptualmente similar al simplificado descrito anteriormente, pero con varios cambios que mejoran la eficiencia o tratan casos especiales necesarios. Aquí tienes una lista de las diferencias.

Disección sobre bloques L2 y luego sobre instrucciones: La afirmación de Alice se basa en un RBlock, que afirma el resultado de crear algunos bloques de Nitro de Capa 2. La disección ocurre primero sobre estos bloques de Capa 2 para reducir la disputa a una disputa sobre un solo bloque de Nitro de Capa 2. En este punto, la disputa se transforma en una disputa sobre una ejecución única de la Función de Transición de Estado o, en otras palabras, sobre la ejecución de una secuencia de instrucciones WAVM. Luego, el protocolo ejecuta nuevamente el subprotocolo de disección recursiva, esta vez sobre las instrucciones WAVM, para reducir la disputa a una sola instrucción. La disputa concluye con una prueba de un solo paso de una instrucción (o una parte que no actúa y pierde por tiempo de espera).

Disección de K vías: En lugar de dividir una afirmación en dos segmentos de tamaño N/2, la dividimos en K segmentos de tamaño N/K. Esto requiere publicar K-1 afirmaciones intermedias en puntos uniformemente espaciados a lo largo de la ejecución afirmada. Esto reduce el número de rondas en un factor de log(K)/log(2).

Responder una disección con una disección: En lugar de requerir dos movimientos en cada ronda del protocolo, donde Alice disecciona y Bob elige un segmento para desafiar, requerimos que Bob, al desafiar un segmento, publique su propio estado final afirmado para ese segmento (que debe diferir del de Alice) y su propia disección de su versión del segmento. Luego, Alice responderá identificando un subsegmento, publicando un estado final alternativo para ese segmento y diseccionándolo. Esto reduce el número de movimientos en el juego en un factor adicional de 2, ya que el tamaño se reduce en un factor de K en cada movimiento, en lugar de cada dos movimientos.

Manejo del caso de inbox vacía: El AVM real no siempre puede ejecutar N unidades de gas sin quedarse atascado. La máquina puede detenerse o puede tener que esperar porque su inbox se agotó y no puede continuar hasta que lleguen más mensajes. Por lo tanto, se permite que Bob responda a la afirmación de Alice de N pasos alegando que N pasos no son posibles. El protocolo real permite que cualquier respuesta (excepto la afirmación inicial) reclame un estado final especial que significa esencialmente que la cantidad especificada de ejecución no es posible bajo las condiciones actuales.

Límites de tiempo: A cada jugador se le asigna un tiempo permitido. El tiempo total que un jugador utiliza para todos sus movimientos debe ser menor que el tiempo permitido, de lo contrario, perderá el juego. Piensa en el tiempo permitido como aproximadamente una semana.

Debería quedar claro que estos cambios no afectan la corrección básica del protocolo de desafío. Sin embargo, mejoran su eficiencia y le permiten manejar todos los casos que pueden surgir en la práctica.

12.4 Prueba de un Paso (One Step Proofs).

Las pruebas de un Paso (OSP, por sus siglas en inglés) se basan en ciertas suposiciones sobre los casos que pueden derivar en una ejecución correcta. En este documento se detallan esas suposiciones sobre lo que se está ejecutando.

Si un caso es "Imposible", es decir, se asume que el caso nunca surgirá en una ejecución correcta, entonces el OSP puede implementar cualquier semántica de instrucción en ese caso.

En un desafío entre partes malintencionadas, cualquier caso puede surgir. El protocolo de desafío debe tomar medidas seguras en cada caso. Sin embargo, la semántica de las instrucciones puede ser peculiar en tales casos, ya que si ambas partes en un desafío son malintencionadas, al protocolo no le importa quién gana el desafío.

En un desafío con una parte honesta, dicha parte nunca necesitará probar de forma incremental un caso Imposible. La parte honesta solo afirmará ejecuciones correctas, por lo que sólo deberá probar casos posibles.

En un desafío con una parte honesta y otra deshonesta, esta última podría afirmar una ejecución que transicione a un caso “imposible”. Sin embargo, tal ejecución debe incluir una ejecución inválida de un caso “posible” anterior en la afirmación. Dado que un desafío que involucra a una parte honesta eventualmente requerirá una OSP sobre la primera instrucción en la que las partes no están de acuerdo, la OSP se realizará en el punto de divergencia anterior y no en la ejecución posterior de un caso “imposible”.

En general, algunos casos “imposibles” serán detectables por el verificador de OSP y otros no. Para garantizar la seguridad, los casos imposibles detectables deben definirse mediante la transición de la máquina a un estado de error, lo que permitiría que la gobernanza eventualmente promueva una actualización para recuperarse del error. Un caso imposible indetectable, en caso de que ocurra en una ejecución correcta, podría provocar una falla de seguridad.

Las siguientes suposiciones, en conjunto, deben evitar que surja un caso imposible en una ejecución correcta:

El código WAVM se genera mediante Arbitrator a partir de WASM válido.

WAVM es el nombre del conjunto de instrucciones personalizado similar a WASM utilizado para las pruebas. Arbitrator transpila el código WASM a WAVM. También invoca a wasm-validate de wabt (WebAssembly Binary Toolkit) para garantizar que el WASM de entrada sea válido. Se asume que el WAVM producido por Arbitrator a partir de WASM válido nunca encontrará un caso inalcanzable. Los mensajes de la inbox no deben ser demasiado grandes.

El método actual de hash de la inbox requiere que el mensaje completo de la misma esté disponible para la prueba. Dicho mensaje no debe ser demasiado grande como para impedir que se suministre para la prueba, y esto está garantizado para las inboxes.

El límite de longitud actual es de 117,964 bytes, que corresponde al 90% del tamaño máximo de transacción que aceptará Geth, dejando 13,108 bytes para otros datos de prueba.

Las preimágenes solicitadas deben ser conocidas y no demasiado grandes.

WAVM tiene un opcode que resuelve la preimagen de un hash Keccak-256. Sin embargo, esto solo se puede ejecutar si la preimagen ya es conocida por todos los nodos y solo se puede probar si la preimagen no es demasiado larga. Las violaciones de esta suposición no pueden ser detectadas por el verificador de OSP. El límite de longitud actual es de 117,964 bytes por las razones mencionadas anteriormente.

A continuación se presenta una lista de las preimágenes que pueden ser solicitadas por Nitro y por qué son conocidas por todas las partes y no son demasiado grandes:

• Headers de los bloques:

Nitro puede solicitar hasta los últimos 256 headers de bloques de Capa 2 (L2). El último header de bloque es necesario para determinar el estado actual, y los bloques anteriores son necesarios para implementar la instrucción EVM BLOCKHASH.

Esto es seguro, ya que los headers de los bloques anteriores tienen un tamaño fijo y son conocidos por todos los nodos.

• Acceso al trie de estado:

Para resolver el estado, Nitro recorre el trie de estado resolviendo preimágenes. Esto es seguro, ya que los validadores retienen el estado de archivo de los bloques no confirmados, cada rama del trie tiene un tamaño fijo y la única entrada de tamaño variable en el trie es el código de contrato, que está limitado por la EIP-170 a aproximadamente 24KB.

Estas suposiciones, en conjunto, están diseñadas para evitar que surja un caso imposible en una ejecución correcta. Se han establecido salvaguardias para garantizar la validez, la seguridad de las ejecuciones y pruebas en el protocolo OSP.

12.5 Eficiencia.

El protocolo de desafío está diseñado de manera que la disputa pueda resolverse con un mínimo de trabajo requerido por el protocolo (a través de sus contratos de Ethereum de Capa 1) en su papel de árbitro. Cuando es el turno de Alice, el protocolo solo necesita realizar un seguimiento del tiempo que Alice utiliza y asegurarse de que su movimiento incluya los K-1 puntos intermedios requeridos. El protocolo no necesita prestar atención a si esas afirmaciones son correctas de alguna manera; solo necesita saber si el movimiento de Alice "tiene la forma correcta".

El único punto en el que el protocolo necesita evaluar un movimiento "por sus méritos" es en la prueba de un solo paso, donde necesita examinar la prueba de Alice y determinar si la prueba proporcionada realmente establece la corrección o incorrección de la instrucción en disputa. Sin embargo, dado que esta es una prueba de un solo paso y el tamaño de la instrucción es relativamente pequeño, el costo computacional y de almacenamiento asociado también es manejable.

En general, el protocolo de desafío está diseñado para ser eficiente y escalable, minimizando la carga en el árbitro y permitiendo resolver las disputas de manera justa y confiable.

13.🌉Arbitrum Bridge.

Gracias a la habilidad de protocolo de arbitrum de intercambiar mensajes entre L1 y L2, los usuarios de la red pueden aprovecharse de esto para mover activos o tokens de una manera trustless de la red de Arbitrum a Ethereum y viceversa. En principio cualquier tipo de activo puede ser punteado, ya sea, Ether, tokens ERC20, tokens ERC-721, etc.

13.1 Depósito y Retiro de Ether (ETH).

Para mover Ether de la red de Etherum a la red de Arbitrum, se debe ejecutar un transacción de depósito usando la función “Inbox.depositEth”. Esto transfiere los fondos hacia el contrato de bridge en L1 y acredita al usuario como los mismos fondos en la red de Arbitrum hacia una dirección específica.

A nivel de programacion la sintaxis se ve de la siguente manera:

function depositEth(address destAddr) external payable override returns (uint256)

La siguiente imagen ilustra todo esto de una manera más sencilla:

Nota: en criptografía, el término “Época” ( o epoch en inglés) se refiere a una unidad de tiempo en la que los validadores de la red permanecen constantes. Se mide en bloques.

Se puede retirar ether utilizando la funcion “ withdrawEth” de ArbSys:

ArbSys(100).withdrawEth{ value: 2300000 }(destAddress)

Al realizar el retiro, el saldo de Ether se quema en el lado de Arbitrum y luego estará disponible en el lado de Ethereum.

ArbSys.withdrawEth es en realidad una función conveniente que es equivalente a llamar a ArbSys.sendTxToL1 con calldataForL1 vacío. Al igual que cualquier otra llamada sendTxToL1, requerirá una llamada adicional a Outbox.executeTransaction en L1 después de que el período de disputa haya pasado para que el usuario finalice el reclamo de sus fondos en L1. Una vez que se ejecuta el retiro desde el Outbox, el saldo de Ether del usuario se acreditará en L1.

13.2 Depósito y Retiro de ERC-20 tokens.

El protocolo de arbitrum técnicamente no distingue entre los diferentes standards de tokens que existen, por ello, no le da ventajas especiales a ningún tipo de bridge en particular. Sin embargo, el equipo de Off Chain Labs ha creado el “Canonical Bridge”, el cual es el recomendado para los usuarios que usan arbitrum. Básicamente este “Canonical Bridge” es una Dapp con contratos tanto en Ethereum como en Arbitrum que se aprovecha de la capacidad de paso de mensajes entre L1 y L2 explicados anteriormente.

13.3 Tipo de Diseño.

Para el puente de tokens se utiliza el término “Gateway”, el cual es un mecanismo utilizado para facilitar las transferencias de activos entre los dominios de Ethereum y Arbitrum.

La razón principal que motivó a crear el mecanismo “Gateway” fue la funcionalidad.

Generalmente, la funcionalidad de gateway estándar es suficiente para la mayoría de tokens, esto implica lo siguiente: un contrato de un token en Ethereum se asocia con un contrato de token emparejado en Arbitrum. Depositar un token involucra depositar cierta cantidad del token en un bridge contract en L1 y mintear la misma cantidad en el contrato previamente emparejado en L2. En L2, el contrato emparejado se comporta igual que un contrato de token ERC20 normal.

Por otro lado, al retirar es necesario quemar cierta cantidad del token, que luego de un tiempo se puede reclamar del bridge contract en L1.

Sin embargo, muchos tokens requieren sistemas con gateways personalizadas, en donde las posibilidades son complicadas de generalizar. Por ejemplo:

• Aquellos tokens que producen intereses para sus holders deben garantizar que los mismos sean distribuidos correctamente entre las redes y que no se acumulen en el bridge contract.

• Las implementaciones de WETH entre dominios (Ethereum y Arbitrum) requieren que los tokens pasen de wrapped a unwrapped a medida que se mueven entre L1 a L2 y viceversa.

Por lo tanto, la arquitectura del bridge no solo debe ser diseñada para la funcionalidad estándar (depósitos/retiros), sino también para casos personalizados que necesiten otras funciones.

13.4 Implementación canónica L2 por contrato de token L1.

Está muy bien tener varias Gateways personalizadas, sin embargo se debe evitar que un único token de L1 pueda estar emparejado por varios contratos en L2 (lo que puede generar problemas de colisión y confusión entre los usuarios y desarrolladores). Por ello, es necesario tener una forma que rastree que token L1 y que gateway utilizará, y al mismo tiempo, tener un oráculo que mapee las direcciones de los tokens a través de los dominios de Ethereum y Arbitrum.

13.5 Implementación del puente canónico de tokens.

Con lo anterior en mente, se muestra una visión general de la arquitectura de puente de tokens. La misma está conformada de 3 tipos de contratos:

1. Contrato de Activos: Son los propios contratos de tokens, es decir, un ERC20 en L1 y su homólogo en Arbitrum.

2. Gateways: Pares de contratos (uno en L1, otro en L2) que implementan un tipo particular de puente de activos entre cadenas.

3. Routers: Exactamente dos contratos (uno en L1, uno en L2) que dirigen cada activo a su Gateway designada.

Todas las transferencias de tokens de Ethereum a Arbitrum se inician a través del contrato llamado L1GatewayRouter. Este reenvía la llamada de depósito del token al contrato L1ArbitrumGateway correspondiente. L1GatewayRouter es responsable de asignar las direcciones de los tokens L1 a L1Gateway, actuando así como oráculo de direcciones L1/L2 y garantizando que cada token corresponde a una única Gateway. El L1ArbitrumGateway se comunica con un L2ArbitrumGateway (usando los tickets reintentables explicados anteriormente).

Del mismo modo, las transferencias de Arbitrum a Ethereum se inician a través del contrato L2GatewayRouter, que reenvía las llamadas a la L2ArbitrumGateway del token, que a su vez se comunica con su correspondiente L1ArbitrumGateway (típicamente/esperado a través del envío de mensajes a la Outbox).

Para cualquier emparejamiento de gateway dado, requerimos que las llamadas se inicien a través del GatewayRouter, y que los gateways se ajusten a las interfaces TokenGateway; las interfaces TokenGateway deben ser lo suficientemente flexibles y extensibles como para soportar cualquier funcionalidad de puente que pueda requerir un token en particular.

13.6 Puente estándar por defecto.

Por defecto, cualquier token ERC20 en L1 que no esté registrado en una gateway puede ser puenteado a la gateway estándar ERC20 sin problemas.

Puede utilizar el front-end del bridge o este script para cruzar un token desde L1 a L2 y viceversa.

13.7 Ejemplo: Depósito/retirada de Arb-ERC20 estándar.

Para ayudar a ilustrar cómo se ve todo esto en la práctica, vamos a ir a través de los pasos de cómo depositar y retirar SomeERC20Token a través de nuestra Gateway ERC20 estándar. Suponemos que SomeERC20Token ya se ha registrado en el L1GatewayRouter para utilizar la Gateway ERC20 estándar.

Depósitos.

1. Un usuario llama a GatewayRouter.outboundTransferCustomRefund (con la dirección L1 de SomeERC20Token como argumento).

2. GatewayRouter busca la gateway de SomeERC20Token y descubre que se trata de una Gateway ERC20 estándar (el contrato L1ERC20Gateway).

3. GatewayRouter llama a L1ERC20Gateway.outboundTransferCustomRefund, reenviando los parámetros apropiados.

4. L1ERC20Gateway deposita los tokens y crea un ticket reintentable para activar la función finalizeInboundTransfer de L2ERC20Gateway en L2.

5. finalizeInboundTransfer mintea la cantidad apropiada de tokens en el contrato arbSomeERC20Token en L2.

Nota: Hay que tener en cuenta que es posible que algunas gateways personalizadas antiguas no tengan implementado outboundTransferCustomRefund y GatewayRouter.outboundTransferCustomRefund no recurra a outboundTransfer. En esos casos, se utiliza la función GatewayRouter.outboundTransfer.

Tenga en cuenta que arbSomeERC20Token es una instancia de StandardArbERC20, que incluye las funciones bridgeMint y bridgeBurn que solo pueden ser llamadas por la gatewayL2ERC20Gateway.

Retiros.

1. En Arbitrum, un usuario llama a L2GatewayRouter.outBoundTransfer, que a su vez llama a outBoundTransfer en la gateway de arbSomeERC20Token (es decir, L2ERC20Gateway).

2. Esto quema los tokens de arbSomeERC20Token y llama a ArbSys con un mensaje codificado a L1ERC20Gateway.finalizeInboundTransfer, que se ejecutará finalmente en L1.

3. Una vez que expira la ventana de disputa y se confirma la aserción con la transacción del usuario, éste puede llamar a Outbox.executeTransaction, que a su vez llama al mensaje codificado L1ERC20Gateway.finalizeInboundTransfer, liberando los tokens del usuario de la custodia del contrato L1ERC20Gateway.

13.8 La Gateway personalizada genérica de Arbitrum.

El hecho de que un token tenga requisitos más allá de los que se ofrecen a través de la Gateway StandardERC20, no significa necesariamente que haya que crear una unica Gateway personalizada para el token en cuestión.

Gateway personalizada genérica de Arbitrum está diseñada para ser lo suficientemente flexible como para adaptarse a la mayoría (pero no necesariamente a todas) las necesidades de tokens fungibles personalizados.

Como regla general:

Si un token personalizado tiene la capacidad de aumentar su suministro (es decir, mintear) directamente en el L2, y desea que los tokens minteados en el L2 puedan retirarse de nuevo al L1 y sean reconocidos por el contrato L1, probablemente requerirá su propia Gateway especial. De lo contrario, la Gateway personalizada genérica es probablemente la solución adecuada.

Algunos ejemplos de características de los tokens adecuadas para la Gateway personalizada genérica:

• Contrato de token L2 actualizable a través de un proxy.

• El contrato de token L2 incluye whitelisting o blacklisting de direcciones.

• El deployer determina la dirección del contrato de token L2.

13.9 Configuración del token con la Gateway personalizada genérica.

Aquí se encuentran los pasos para configurar un token para utilizar la Gateway personalizada genérica:

0) Tener un token en L1.

El token en L1 debe ajustarse a la interfaz ICustomToken (para saber como hacer esto puedes ver TestCustomTokenL1) Además, debe tener una función isArbitrumEnabled en su interfaz.

1) Despliegue de su token en Arbitrum.

El token debe ajustarse a la interfaz mínima de IArbToken; es decir, debe tener las funciones bridgeMint y bridgeBurn que solo pueden ser usadas por el contrato L2CustomGateway, y la dirección de su correspondiente token Ethereum accesible a través de l1Address. Para ver un ejemplo de implementación, consulta TestArbCustomToken.

2) Registre su token en L1 a su token en L2 a través del contrato L1CustomGateway

Haga que el contrato de su token L1 realice una llamada externa a L1CustomGateway.registerTokenToL2. Este registro puede realizarse alternativamente como un registro de propietario de cadena a través de una propuesta en la Arbitrum DAO.

3) Registre su token en L1 en el router L1Gateway

Una vez completado el registro de su token en la Custom Gateway, haga que el contrato de su token L1 realice una llamada externa a L1GatewayRouter.setGateway; al igual que en el paso anterior, este registro también puede realizarse alternativamente como un registro de propietario de cadena a través de la propuesta Arbitrum DAO.

14.👨‍🎓Conclusión.

El Optimistic Rollup de Arbitrum se ha establecido como una solución prometedora para mejorar la escalabilidad de la red Ethereum. Mediante el uso de rollups optimistas, Arbitrum ha logrado aumentar la eficiencia en el procesamiento de transacciones, reducir los costos y brindar una mayor flexibilidad en las funcionalidades de las aplicaciones descentralizadas.

Toda la criptografía asociada al ecosistema de arbitrum, como por ejemplo, el secuenciador, los tickets reintentables, los mensajes de L1-L2 y el bridge,etc. han sido cuidadosamente estudiada y diseñada para tener respuesta ante cualquier evento malicioso o las necesidades personales de cada usuario y, al mismo tiempo, manteniendo los principios trustless y permissionless de Ethereum.

Con su enfoque basado en la presunción de validez de las transacciones y un sistema de desafío para garantizar la integridad, Arbitrum ofrece una alternativa sólida para mejorar la experiencia de los usuarios de Ethereum. A medida que esta tecnología continúa evolucionando, se espera que Arbitrum desempeñe aún más el papel que está tomando en la adopción masiva de las aplicaciones descentralizadas y la expansión del ecosistema blockchain.

🫂 Agradecimientos

🎉 ¡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.

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!

Series Polygon zkEVM 2/2

¡Hola comunidad! 👋

¡Bienvenidos a la segunda parte de la serie Polygon zkEVM! En la primera parte, hicimos una introducción general sobre la arquitectura y componentes de esta tecnología, así como su pensamiento en cuanto a la compatibilidad/equivalencia con ETH, junto con su ética y valores fundamentales (Ethos).

En este artículo, explicaremos cómo se llega a un consenso a través de un Smart Contract y cómo funciona este mecanismo de incentivación económica.

También exploraremos cómo funcionan los estados de las transacciones y cómo se simulan y controlan varios estados para garantizar la validez de las transacciones con la seguridad en la capa de ETH, así como una parte de exploración de transacciones para aprender a visualizar esta información.

🤝 Contrato de Consenso

En la Parte 1 introducimos PoD (Proof of Donation) como un mecanismo de consenso utilizado en la blockchain. A diferencia de resolver problemas matemáticos complejos para validar transacciones y crear nuevos bloques, PoD funciona como una subasta descentralizada.

📄 Modelo de implementación

El modelo de implementación del Contrato de Consenso PolygonZkEVM.sol, emplea una técnica más sencilla y eficiente que el PoD para resolver los desafíos del consenso. Múltiples coordinadores producen batch en L2 y estos batch se crean a partir de las transacciones enrolladas de L1, este nuevo modelo es conocido como PoE (Proof of Efficiency)

La implementación estratégica del consenso basado en contratos tiene como objetivo garantizar que la red:

• 🌐 - Alcance un nivel aceptable de descentralización.

• 🔐 - Mantenga su característica Permissionless para producir batches L2.

• ⚡️ - Sea altamente eficiente, lo que es fundamental para el rendimiento general de la red.

• 🛡️ - Esté protegida de ataques malintencionados, especialmente por parte de los validadores.

• ⚖️ - Mantenga un equilibrio justo entre el esfuerzo global de validación y el valor de la red.

🤝🟣 Contrato de Consenso PolygonZkEVM.sol

El contrato de Consenso PolygonZkEVM.sol desplegado en L1, se utiliza para garantizar que las transiciones de estado en el protocolo zkEVM se realizan de manera correcta, siguiendo un conjunto de reglas predefinidas. Este protocolo emplea una prueba de validez para asegurar la corrección de las transiciones de estado.

Para verificar que cada transición se completa correctamente, se utiliza un contrato inteligente que emplea circuitos zk-SNARK. El proceso se realiza en dos pasos, transacciones por batches y validación de transacciones.

En zkEVM, se utilizan dos tipos de participantes, Secuenciadores y Agregadores, para llevar a cabo los procedimientos.

• Los Secuenciadores: proponen batch de transacciones enrolladas en el Contrato de Consenso.

• Los Agregadores: verifican la validez de los batch y proporcionan pruebas de validez.

El contrato inteligente realiza dos llamadas, una para recibir los batch de los Secuenciadores y otra para validarlos con los Agregadores. Cualquier Agregador sin permisos puede enviar la prueba para demostrar la exactitud del cálculo de transición de estado.

📊 Tokenomics

El contrato inteligente de Consenso PolygonZkEVM.sol, establece los siguientes requisitos para los Secuenciadores y Agregadores:

Secuenciadores: actualmente, solo existe una entidad controladora que actúa como Secuenciador, aunque en el futuro se espera descentralizar este mecanismo. Por el momento, el contrato garantiza que solo el poseedor de la clave privada puede enviar secuencias. Sin embargo, veremos como habilitado en cierto casos prácticos el mecanismo forcebatch se consigue evitar la censura.

Para obtener el derecho a crear y proponer batches, el Secuenciador debe pagar una tarifa en forma de token MATIC. Si el Secuenciador propone batches válidos (que consisten en transacciones válidas), será incentivado con la tarifa pagada por los solicitantes de transacciones o los usuarios de la red.

Agregadores: son los responsable de recopilar todos los datos necesarios para una transacción y enviarlos al probador. El probador realizará cálculos polinómicos complejos para proporcionar una prueba zk que el contrato inteligente verificará para validar la transacción.

El Agregador también recibe la salida del proveedor y envía la información completa al contrato inteligente para su validación final.

Para poder proporcionar pruebas de validez para transacciones de capa 2, los Agregadores deben tener hardware especializado y ejecutar el software zkNode de zkEVM. Además, deben competir para producir pruebas de validez lo antes posible y el primer Agregador en presentar una prueba de validez gana la tarifa MATIC que paga el Secuenciador para ese batch específico.

En resumen, la tarea principal de un Agregador es proporcionar pruebas de validez para las transacciones propuestas por los Secuenciadores y competir para producir la primera prueba de validez y así ganar la tarifa MATIC. En cuanto a las tarifas y los incentivos, se ha diseñado una estructura adecuada para ellos, que se describe a continuación más detallada.

💰 Estructura de incentivación

Como ya hemos visto en la arquitectura de zkEVM, la red cuenta con dos tipos de participantes: Secuenciadores y Agregadores. Es importante destacar que se han diseñado estructuras de incentivos adecuadas para cada uno de ellos con el fin de mantener la red rápida y segura. A continuación, se presenta un resumen de la estructura de tarifas para ambos.

🤖 Secuenciador

El Secuenciador se encarga de recoger transacciones y publicarlas en batches. A cambio, recibe comisiones de las transacciones publicadas.

• Recoge transacciones y publica batches: el Secuenciador es responsable de recoger transacciones y agruparlas en batches para su procesamiento en la red zkEVM.

• Recibe comisiones: el Secuenciador recibe una comisión por cada transacción publicada en su batch.

• Paga las tarifas de transacción: el Secuenciador debe pagar las tarifas de transacción de L1 y MATIC (dependiendo de los batches pendientes).

• MATIC va a los Agregadores: parte de las tarifas de transacción pagadas por el Secuenciador se destinan a los Agregadores como incentivo para su participación.

• Es rentable si: las comisiones de las transacciones en el batch son mayores que la llamada L1 más la tarifa MATIC.

🛡️ Agregador

Los Agregadores son responsables de procesar las transacciones publicadas por los Secuenciadores, construir la prueba zk Proof y recibir MATIC como incentivo.

• Procesa las transacciones: los Agregadores procesan las transacciones publicadas por los Secuenciadores.

• Construyen zk Proof: los Agregadores deben construir la prueba zk Proof que valida la integridad de los batches de transacciones procesadas.

• Reciben MATIC: los Agregadores reciben MATIC como incentivo por su participación en la red zkEVM.

• Costo estático: los Agregadores deben pagar el costo de la llamada L1 y el costo del servidor para construir la prueba zk Proof.

• Es rentable si: la tarifa MATIC recibida es mayor que la llamada L1 más el costo del servidor.

Con estas estructuras de incentivos, zkEVM se mantiene rápido y seguro para sus participantes.

⚙️💰 Mecanismo de incentivos zkEVM

Para garantizar la sostenibilidad del sistema, los actores deben ser compensados por desempeñar correctamente sus roles y dar la finalidad del protocolo.

A menos que se especifique lo contrario, las medidas y reglas presentadas aquí se aplican a los casos en que los roles de Secuenciador y Agregador están descentralizados (es decir, cuando no haya Secuenciador de Confianza ni Agregador de Confianza), aunque veremos como aún esto no es el del todo posible, dado a la Confianza del Secuenciador.

Tasas de transacción L2

La moneda nativa utilizada en L2 es Bridged Ether, que se origina en L1. Esta es la moneda que se utiliza para pagar las tarifas de transacción L2. Se puede transferir a una relación de intercambio 1: 1 de L1 a L2 y viceversa.

Tarifas de Secuenciación

El Secuenciador gana las tarifas de transacción pagadas por los usuarios de L2 por enviar transacciones y, por lo tanto, se paga directamente en Bridged Ether. El monto de las tarifas pagadas depende del precio del gas, que es establecido por los usuarios en función de cuánto están dispuestos a pagar por la ejecución de sus transacciones.

Para incentivar al Agregador para cada batch secuenciado, el Secuenciador debe bloquear una serie de tokens MATIC en el Contrato de L1 PolygonZkEVM.sol proporcional al número de batches en la secuencia. El número de tokens MATIC bloqueados por batch secuenciado se guarda en la variable batchFee.

Para maximizar sus ingresos, el Secuenciador prioriza las transacciones con precios más altos de gas. Además, hay un umbral por debajo del cual no es rentable para el Secuenciador ejecutar transacciones porque las tarifas ganadas por los usuarios de L2 son menores que las tarifas pagadas por las tarifas de secuenciación (más la transacción de secuenciación y fee en L1).

Los usuarios deben asegurarse de que sus tarifas de transacción sean mayores que esto umbral para que el Secuenciador sea incentivado a procesar sus transacciones.

El valor neto de Ether obtenido por el Secuenciador para secuenciar una secuencia de batch está representado por la siguiente expresión:

• totalL2TxGasFeeses: es la suma total de las tarifas recaudadas de todas las transacciones L2 incluidas en la secuencia de lotes.

• L1SeqTxGasFeees: es la tarifa de gas de transacción de secuenciación pagada en L1.

• batchFee: es la variable de almacenamiento en el SC PolygonZkEVM.sol

• nBatcheses: es el número de batch en la secuencia.

• MATIC/ETH: es el precio de la ficha MATIC expresada en ETH.

Tarifas de Agregación

El Agregador también necesita una compensación por cumplir correctamente su función.

El número de tokens MATIC que gana el Agregador cada vez que agrega una secuencia, denominado como batchReward, está determinado por el balance total del contrato MATIC y el número de batches agregados.

El MATIC ganado por batch agregado se calcula por el contrato L1 PolygonZkEVM.sol antes de la agregación de la secuencia utilizando la siguiente expresión:

La siguiente expresión representa la cantidad total de valor ETH que el Agregador ganará por la agregación de una secuencia de batches:

• L1AggTxGasFee: es la tarifa de gas de transacción de agregación pagada en L1.

• batchReward: es la cantidad de MATIC ganado por lote agregado.

• nBatches: es el número de batches en la secuencia

• MATIC/ETH: es el precio del token MATIC expresado en ETH.

Ahora procedamos a analizar en el explorador filtrado por la dirección del proxy con el token MATIC, para observar las entradas y salidas. De esta manera, podremos entender cómo el Secuenciador brinda un incentivo para el Agregador y cómo se retira una vez que el verificador ha realizado la prueba y se ha consolidado el estado.

En este caso, es importante destacar que la suma de las entradas de MATIC de los Sequence Batches debe ser igual a la salida de MATIC por los Verify Batches Trusted Aggregator, la cual indicará el estado ya consolidado con la prueba en L1 en la que vemos también un intervalo de tiempo entre Sequence Batches de 10 min entre ellos. Si en alguna ocasión estas sumas no coinciden, se debe revisar las transacciones y verificar que todo sea correcto, ya que a veces la visualización en el explorador puede ser engañosa y coincidir con la anterior “IN” y luego procesar una salida anterior.

Además, como aprendimos estos batches deben tener al menos 1 batch. En la imagen superior se aprecia que hay hasta 5 batches. En el ejemplo que estamos analizando, las sumas de "IN" coinciden con las de "OUT" de 2.8 y 2.2 MATIC, respectivamente.

🌐 Polygon zkEVM State Management

Ahora explicaremos cómo el Protocolo Polygon zkEVM gestiona los estados del Rollup L2 al tiempo que proporciona verificabilidad y seguridad de transición estatal.

Administración de Estados en L2

El Secuenciador de Confianza genera batches, pero para lograr una finalidad rápida de las transacciones L2 y evitar la necesidad de esperar el próximo bloque L1, se comparten con los nodos de red L2 a través de un canal de transmisión. Cada nodo ejecutará los batches para calcular el estado L2 resultante localmente.

Una vez el Secuenciador ha comprometido las secuencias de batches obtenidos directamente de los nodos de red L1, L2 los ejecutarán nuevamente, y ya no tendrán que confiar en ellos.

La ejecución fuera de cadena de los batches eventualmente se verificará en cadena a través de una zk Proof, y se comprometerá la raíz resultante del Estado L2. A medida que avanza el protocolo zkEVM, las nuevas raíces de estado L2 se sincronizarán directamente desde los nodos de red L1 en L2.

Tanto la disponibilidad de los datos como la verificación de la ejecución de las transacciones dependen únicamente de los supuestos de seguridad de L1 y, en la fase final del protocolo, los nodos sólo dependerán de los datos presentes en L1 para mantenerse sincronizados con cada transición de estado de L2.

Los nodos L2 pueden recibir datos de batches de tres maneras diferentes:

• Directamente desde el Secuenciador antes de que los batches estén comprometidos con L1, o bien.

• Directamente desde L1 después de que los batches hayan sido secuenciados.

• O sólo después de que el Agregador haya probado la corrección de la ejecución y verificado por el contrato PolygonZkEVM.sol

Vale la pena señalar que los tres formatos de datos de batch son recibidos por los nodos L2 en orden cronológico enumerado anteriormente.

🔄 Tres Estados L2

Hay tres etapas del estado L2, cada una correspondiente a las tres formas diferentes en que los nodos L2 pueden actualizar su estado. Los tres casos dependen del formato de los datos del batch utilizados para actualizar el estado L2.

En el primera instancia, la actualización se basa únicamente en la información (i.e., batches que consisten en transacciones ordenadas) que provienen directamente del Secuenciador de Confianza, antes de cualquier disponibilidad de datos en L1. El estado L2 resultante se llama Estado de Confianza “Trusted State”.

En el segundo caso, la actualización se basa en información recuperada de la red L1 por nodos L2. Es decir, después de que los batches hayan sido secuenciados y los datos se hayan puesto a disposición en L1. El estado L2 se conoce como el Estado virtual “Virtual State”.

La información utilizada para actualizar el estado L2 en el último caso incluye zk Proof verificadas de integridad computacional. Es decir, después de que la zk Proof se haya verificado con éxito en los nodos L1, L2 sincronizan su raíz local del estado “State root” L2 con el cometido en L1 por el Agregador de Confianza “Trusted Aggregator”. Como resultado, dicho Estado L2 se conoce como el Estado Consolidado “Consolidated State”.

La siguiente figura muestra la línea de tiempo de las etapas del estado L2 desde una perspectiva de un batch, así como las acciones que desencadenan la progresión de una etapa a la siguiente.

Enviar transacción

Las transacciones en la red Polygon zkEVM se crean en las billeteras de los usuarios y se firman con sus claves privadas.

Una vez generado y firmado, las transacciones se envían al nodo del Secuenciador de Confianza a través de su interfaz JSON-RPC. Las transacciones se almacenan en el grupo de transacciones pendientes, donde esperan la selección del Secuenciador para su ejecución o descarte.

Los usuarios y el zkEVM se comunican utilizando JSON-RPC, que es totalmente compatible con Ethereum RPC. Este enfoque permite que cualquier aplicación compatible con EVM, como el software de billetera, funcione y se sienta como usuarios reales de la red Ethereum.

Transacciones y bloques en zkEVM

En el diseño actual, una sola transacción es equivalente a un bloque.

Esta estrategia de diseño no solo mejora la comunicación RPC y P2P entre nodos, sino que también mejora la compatibilidad con las herramientas existentes y facilita la finalidad rápida en L2. También simplifica el proceso de localización de transacciones de usuarios.

1️⃣🔄 Estado de Confianza

Ejecución de transacciones

El Secuenciador de Confianza ”Trusted Sequencer “, lee las transacciones del grupo y decide si descartar ellos u ordenar y ejecutar ellos. Las transacciones que se han ejecutado se agregan a un batch de transacciones, y se actualiza el estado local de L2 del Secuenciador.

Una vez que se agrega una transacción al estado L2, se transmite a todos los demás nodos zkEVM a través de un servicio de transmisión. Vale la pena señalar que confiando en el Secuenciador de Confianza, podemos lograr una finalidad de transacción rápida (más rápida que en L1). Sin embargo, el Estado L2 resultante estará en un estado confiable hasta que el batch se comprometa en el Contrato de Consenso.

Verificación en Layer 1

Los usuarios suelen interactuar con el Estado L2 de Confianza. Sin embargo, debido a determinadas características del protocolo, el proceso de verificación de las transacciones L2 (en la capa 1 para permitir las retiradas) puede llevar mucho tiempo, normalmente unos 30 minutos, pero hasta 2 semanas en casos excepcionales. En consecuencia, los usuarios deben ser conscientes de los riesgos potenciales asociados a las transacciones de alto valor, en particular las que no pueden anularse, como las retiradas, las transacciones en ventanilla y los puentes alternativos.

Procesamiento por Batch

El Secuenciador de Confianza debe procesar las transacciones por batches utilizando la siguiente estructura BatchData especificada en el contrato PolygonZkEVM.sol.

  struct BatchData {
     bytes transactions;
     bytes32 globalExitRoot;
     uint64 timestamp;
     uint64 minForcedTimestamp;
}

Transacciones

Son arrays de bytes (estructura de datos con elementos homogéneos, del mismo tipo, numérico o alfanumérico) que contienen las transacciones por batches concatenados.

Cada transacción se codifica según los formatos Ethereum pre-EIP-155 o EIP-155 utilizando el estándar RLP (prefijo de longitud recursiva), pero los valores de firma, v, r y s, se concatenan como se muestra a continuación;

1. EIP-155: RLP (nonce,gasprice,gasLimit,to,value,data,chainid,0,0,)#v#r#s

2. pre-EIP-155: RLP (nonce,gasprice,gasLimit,to,value,data)#v#r#s.

GlobalExitRoot

Es la raíz del árbol Merkle de salida global del puente, que se sincronizará en el estado L2 al inicio de la ejecución por batches.

El puente transporta activos entre L1 y L2, y una transacción de reclamación desbloquea el activo en la red de destino.

Timestamp

Al igual que los bloques de Ethereum tienen marcas de tiempo, cada batch tiene una marca de tiempo.

Hay dos restricciones que cada marca de tiempo debe satisfacer para asegurar que los batches están ordenados en el tiempo y sincronizados con los bloques L1:

1. La marca de tiempo de un batch determinado debe ser mayor o igual que la marca de tiempo del último batch secuenciado.

2. La marca de tiempo máxima que un Secuenciador de Confianza puede asignar a un batch es la marca de tiempo del bloque en el que se ejecuta la transacción L1 de secuenciación.

minForcedTimestamp

Si un batch es de los denominados forzados, este parámetro debe ser mayor que cero. La censura se contrarresta utilizando batches forzados.

2️⃣🔄 Estado Virtual

Secuenciación de Batches

Los batches deben secuenciarse y validarse antes de que puedan formar parte del Estado Virtual L2.

El Secuenciador de Confianza añade con éxito un lote a una secuencia de batches utilizando el mapeo sequencedBatches del contrato L1 PolygonZkEVM.sol, que es básicamente una estructura de almacenamiento que contiene la cola de secuencias que definen el Estado Virtual.

// SequenceBatchNum --> SequencedBatchData
mapping(uint64 => SequencedBatchData) public sequencedBatches;

Para que un batch pueda ser secuenciado, debe ser parte de la colección de batches que se secuenciarán. El Secuenciador de Confianza llama al Contrato PolygonZkEVM.sol, que utiliza su mapeo sequenceBatches. Este mapeo acepta una matriz de batches que se secuenciarán como argumento.

Límites máximos y mínimos de tamaño de batch

La constante pública del contrato, MAX_TRANSACTIONS_BYTE_LENGTH, determina el número máximo de transacciones que pueden incluirse en un lote (300000).

Del mismo modo, el número de batches de una secuencia está limitado por la constante pública del contrato MAX_VERIFY_BATCHES (1000). La matriz de batches debe contener al menos un batch y no más que el valor de la constante MAX_VERIFY_BATCHES.

Validez de los batches e integridad del estado L2

La función sequencedBatches itera sobre cada batch de la secuencia, comprobando su validez. Un batch válido debe cumplir los siguientes criterios:

• Debe incluir un valor globalExitRoot que esté presente en el GlobalExitRootMap del contrato L1 PolygonZkEVMGlobalExitRoot.sol del puente. Un batch sólo es válido si incluye un globalExitRoot válido.

• La longitud de la matriz de bytes de transacciones debe ser inferior al valor de la constante MAX_TRANSACTIONS_BYTE_LENGTH.

• La marca de tiempo del batch debe ser mayor o igual que la del último batch secuenciado, pero menor o igual que la marca de tiempo del bloque en el que se ejecuta la transacción L1 secuenciada. Todos los batch deben estar ordenados por hora.

Si un batch no es válido, la transacción revierte, descartando toda la secuencia. En caso contrario, si todos los batch a secuenciar son válidos, el proceso de secuenciación continuará.

Como contador de batch se utiliza una variable de almacenamiento denominada lastBatchSequenced, que se incrementa cada vez que se secuencia un batch. Da un número de índice específico a cada batch que se utilizará como valor de posición en la cadena de batches.

El mismo mecanismo hash utilizado en las cadenas de bloques para enlazar un bloque con el siguiente se utiliza en los batches para garantizar la integridad criptográfica de la cadena de batches. Es decir, se incluye el resumen del batch anterior entre los datos utilizados para calcular el resumen del batch siguiente.

Como resultado, el resumen de un batch determinado es un hash acumulado de todos los batches secuenciados previamente, de ahí el nombre de hash acumulado de un batch, denotado por oldAccInputHash para el antiguo y newAccInputHash para el nuevo.

Un hash acumulado de un batch específico tiene la siguiente estructura:

keccak256 ( 
    abi.encodePacked (
        bytes32 oldAccInputHash, 
        keccak256(bytes transactions), 
        bytes32 globalExitRoot ,
        uint64 timestamp ,
        address seqAddress
    )
)

• oldAccInputHashes el hash acumulado del batch secuenciado anterior.

• keccack256(transactions)es el resumen de Keccak de la matriz de bytes de transacciones.

• globalExitRootes la raíz del árbol Merkle de salida global del puente.

• timestampes la marca de tiempo del batch.

• seqAddresses la dirección del Secuenciador de batches.

Como se muestra en el diagrama anterior, cada hash de entrada acumulado garantiza la integridad de los datos del batch actual (i.e., transactions, timestamp, y globalExitRoot, así como el orden en que fueron secuenciados).

Es importante tener en cuenta que cualquier cambio en la cadena de batches hace que todos los hash de entrada acumulados futuros sean incorrectos, lo que demuestra una falta de integridad en el estado L2 resultante.

Almacenamiento mínimo de BatchData

Dado que las operaciones de almacenamiento en L1 son muy caras en términos de consumo de gas, es fundamental usarlo lo menos posible. Para lograr esto, las ranuras de almacenamiento (o las entradas de mapeo) se usan únicamente para almacenar un compromiso de secuencia.

Cada entrada de mapeo comete dos índices de batch.

• Ultimo batch de la secuencia anterior como valor de SequencedBatchData estructurar.

• Último batch de la secuencia actual como clave de mapeo.

Junto con el hash acumulado del último batch en la secuencia actual y una marca de tiempo.

Es importante tener en cuenta que solo se guarda el hash acumulado del último batch en la secuencia; todos los demás se calculan sobre la marcha para obtener el último.

Como se indicó anteriormente, el resumen del hash será un compromiso de toda la cadena de batches. Los índices de batch también comprometen información útil como el número de batches en la secuencia y su posición en la cadena de batches. La marca de tiempo ancla la secuencia a un punto específico en el tiempo.

La disponibilidad de datos de las transacciones L2 está garantizada porque los datos de cada batch se pueden recuperar la calldata de la transacción de secuenciación, que no forma parte del almacenamiento del contrato pero es parte del Estado L1. Finalmente un SequenceBatches emitirá el evento.

event SequenceBatches (uint64 indexed numBatch)

Una vez que los batches se secuencian correctamente en L1, todos los nodos zkEVM pueden sincronizar su estado L2 local obteniendo los datos directamente de L1 PolygonZkEVM.sol contrato, sin tener que depender solo del Secuenciador de confianza. Así es como se alcanza el estado virtual L2.

3️⃣🔄 Estado Consolidado

Agregación por Batches

Los Agregadores de Confianza eventualmente debería agregar las secuencias de batches previamente cometidos por los Secuenciadores de Confianza para lograr la etapa final del Estado L2, que es el Estado Consolidado.

Agregar una secuencia significa agregar con éxito la raíz de estado L2 resultante a batchNumToStateRoot mapeo en el contrato L1 PolygonZkEVM.sol. Esta es una estructura de almacenamiento que contiene todas las raíces consolidadas del Estado L2, que están codificadas por el último índice de batch de cada secuencia agregada de batches.

// BatchNum --> state root
mapping (uint64 => bytes32) public batchNumToStateRoot;

Además, la agregación implica la verificación exitosa de la zk Proof de la integridad computacional de la ejecución de batches de transacciones.

SNARK, es el esquema subyacente zk Proof de verificación. Una de sus características clave es la concisión y la velocidad de verificación de la prueba.

Como resultado, la integridad de un cálculo exhaustivo se puede verificar utilizando una fracción de los recursos computacionales requeridos por el cálculo original. Como resultado, al emplear un esquema SNARK, podemos proporcionar seguridad en la cadena a cálculos exhaustivos fuera de la cadena de una manera eficiente con el gas.

Como se muestra en el diagrama anterior, la ejecución fuera de cadena de los batch supondrá una transición de estado L2 y, en consecuencia, un cambio a una nueva raíz de estado L2.

La integridad del cálculo (CI) prueba de la ejecución es generada por el Agregador, y su verificación en cadena garantiza la validez de la raíz de estado L2 resultante.

Agregando una secuencia de Batches

Los Executor y Prover son servicios del nodo Aggregator que ejecutan batch y generan pruebas. Los trataremos aquí como unos intérpretes de EVM que pueden:

• Ejecutar una secuencia de batches de transacciones en el estado L2 actual.

• Calcular la raíz de estado L2 resultante.

• Generar una zk Proof de integridad computacional para la ejecución.

El sistema de verificación y la prueba están diseñados de tal manera que una verificación exitosa de la prueba demuestra criptográficamente que la ejecución de una secuencia dada de batches sobre un Estado L2 específico resulta en un Estado L2 representado por el argumento newStateRoot.

Resumiendo y repasando lo aprendido antes de comenzar las exploraciones, en Polygon zkEVM se divide el estado en tres etapas: Trusted State, Virtual State y Consolidated State. Cada una de estas etapas representa una forma diferente en que los nodos de capa 2 pueden actualizar su estado.

• 1ª Etapa: se basa en información del Secuenciador de confianza antes de que los datos estén disponibles en L1.

• 2ª Etapa: utiliza información de la red L1 después de que los batch hayan sido secuenciados y los datos estén disponibles en L1.

• 3ª Etapa: utiliza zk Proof para actualizar el estado L2.

🔬 Explorando en los Batches

En la tabla inferior se describen las diferencias observadas en los batches de transacciones desde el Estado de Confianza “Trusted State” al Estado Virtual “Virtual State”, donde el batch ya ha sido secuenciado y los datos están disponibles en L1, a falta de la última Validity Proof.

Escogimos aleatoriamente batches, pero profundizaremos más entre los batch 10.680 y 10.683. Si los analizamos, vemos que comparten el mismo exitGlobalRoot, lo que significa que hay varios batches dentro de un mismo batch. Concretamente, se trata de cuatro batches distintos, cada uno con sus propias transacciones. En lugar de agregar un único batch, el Secuenciador agregó los cuatro batches compartiendo la misma raíz.

En los ejemplos que tienen un timestamp de alrededor de 400-510 segundos, suele haber un solo batch agregado y el timestamp que se observa corresponde a este único batch.

Sin embargo, en el caso mencionado anteriormente, el timestamp se va registrando cada vez que se agrega un nuevo batch con la misma exitGlobalRoot, hasta llegar al cuarto batch en el ejemplo 10.683. En este caso, el timestamp total marcado por el exitGlobalRoot en L1 es de 12283 sg entre el principio y el final de la secuencia de batches.

🕵️ Explorador

En el siguiente ejemplo, analizaremos el explorador de Polygon zkEVM y exploraremos la relación entre los batches, las transacciones y los bloques. En términos generales, encontramos una relación 1:1, lo que indica que las transacciones en los batches se corresponden con las totales de los bloques como aprendimos en el documento. Si deseas examinar estos datos, te proporcionaremos guías orientativas a continuación junto con el enlace al zkEVM PolygonScan para poder analizar su explorador.

https://zkevm.polygonscan.com/

Una vez hayas seleccionado una transacción o un batch, se mostrarán una serie de parámetros relevantes para el análisis, los cuales ya hemos revisado en el documento.

En este caso, examinaremos un ejemplo aleatorio del batch "10.681", el cual puedes observar en la tabla adjunta.

1. Global Exit Root: es la raíz del árbol Merkle de salida global del puente, que se sincronizará en el estado L2 al inicio de la ejecución por batches.

2. Acc Input Hash: es la huella digital criptográfica única del último batch en la secuencia.

3. Sequence Tx Hash: es el Hash de la transacción del Secuenciador en la que contendrá los datos del batch secuenciado.

4. Verify Batch Tx Hash: es el Hash de la transacción del Agregador después de verificar con la zk Proof que los datos son los correctos y consolidarlos en L1.

5. State Root: es la raíz del árbol Merkle de estado en L2 después de que se hayan ejecutado las transacciones de un batch sobre el estado anterior de L2. Es decir, es el resultado final de la actualización del estado en L2 después de la ejecución de las transacciones de un batch. Esta información se utiliza para la validación y sincronización de la información en la red.

6. l2Coinbase: la dirección del Secuenciador que envía la recompensa bloqueada para incentivar al Agregador a procesar batches.

7. batches.timestamp: la marca de tiempo en segundos en el momento en que se procesó el batch.

Otros datos de la transacción:

• batches.transactions: una lista de transacciones codificadas en bytes que se procesaron en el batch.

• batches.globalExitRoot: la raíz de Merkle del estado global de la cadena de bloques en el momento en que se procesó el batch. Esto se utiliza para verificar que una salida se ha incluido en la cadena.

• batches.minForcedTimestamp: el tiempo mínimo en segundos para que se fuerce la inclusión del batch.

Si deseas obtener más información sobre el contrato principal del rollup PolygonZkEvm puede revisar: 0x5132...7aB2Implementation (Upgradable)Admin, podrás acceder a las reglas del sistema, incluyendo los parámetros básicos, los actores con permisos y los procedimientos de emergencia. Este contrato es responsable de recibir batches de transacciones, raíces de estado de L2 y pruebas zk, lo que permite revisar prácticamente todos los aspectos del sistema.

También sugerimos explorar nuestra Biblioteca Layer 2 en Español y consultar en L2Beat, donde encontrarás información adicional sobre el estado y los riesgos asociados a Polygon zkEVM.

Actualmente, el principal inconveniente se relaciona con la posible falla del Secuenciador y su incapacidad para enviar batches de transacciones. Si esta función no está disponible, los usuarios no podrán confiar en el mecanismo de forzar batches, como se indica en L2Beat, ya que actualmente está deshabilitado.

Recuerda que siempre es importante consultar fuentes actualizadas para obtener la información más precisa sobre el estado y las características del sistema.

🫂 Agradecimientos

🎉 ¡Gracias por leer hasta el final!🎉 Si está interesado en esta solución de escalabilidad, le recomendamos revisar la primera parte o escuchar el Space para L2 en Español con el equipo de Polygon

https://www.youtube.com/live/O4WiUD7L1KA?feature=share&cbrd=1

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!

Introducción

Scroll es una solución de L2 diseñada para mejorar la escalabilidad y reducir las tarifas en la red Ethereum. Como una L2, Scroll utiliza la blockchain de Ethereum como capa base y proporciona una capa adicional de procesamiento fuera de la cadena (off-chain) para mejorar el rendimiento.

Al utilizar Scroll, los usuarios pueden disfrutar de tiempos de confirmación más rápidos y tarifas más bajas en comparación con las transacciones directamente en la blockchain de Ethereum. Además, Scroll es compatible con smart contracts existentes en Ethereum, lo que facilita la migración de aplicaciones y proyectos a esta solución de L2.

¿Suena genial no?

Pero ahora la pregunta es : ¿Como podemos empezar a interactuar con Scroll?

Primeros pasos en Scroll

1. Configurando redes (Network Setup)

Para interactuar con las aplicaciones descentralizadas, hacer transferencias o usar el bridge en la testnet de Scroll, es necesario contar con una billetera. El equipo de Scroll en su documentación recomienda usar Metamask debido a que el proceso de configuración es mucho mas automatizado y rápido.

Para importar las configuraciones de la red de prueba Alpha en tu billetera MetaMask, necesitas seguir estos pasos:

1. Haz clic en todos los botones "Add to wallet" en la página de inicio de la Alpha testnet. Esto importará el ID de la cadena y las URL de RPC para la Alpha testnet de Scroll. (esta actuara como una L2)

2. La red de prueba Goerli está configurada por defecto en MetaMask. Para mostrarla, haz clic en "Mostrar/ocultar redes de prueba" en el menú desplegable de selección de red de MetaMask. (esta actuara como una L1)

En caso de que quieras interacturar con la Alpha Scroll Testnet con otra billetera tendrás que agregarla manualmente. Aquí te dejamos la información necesaria para configurarla tu mismo.

Alpha Scroll Testnet:

• RPC URL: guide.scroll.io/user-guide/setup

• Chain ID: 534353

• Currency Symbol: ETH

• Block Explorer URL: blockscout.scroll.io

Goerli Testnet:

• RPC URL: endpoints.omniatech.io/v1/eth/goerli/public

• Chain ID: 5

• Currency Symbol: ETH

• Block Explorer URL: goerli.etherscan.io

2. Obteniendo fondos de prueba (Faucet)

Para interactuar con la testnet de Scroll, primero debes recibir ETH de la testnet Goerli. Luego puedes transferir desde la testnet Goerli a la Alpha testnet de Scroll. A continuacion te mostramos las 3 formas de obtener ETH en Goerli.

A) Usando goerlifaucet.com (La que pide mas requisitos)

Para usar esta opción sera necesario que te crees una cuenta en Alchemy (Se puede usar una cuenta de google para esto). Ademas la dirección de Ethereum que vayas a utilizar tendrá que tener un saldo en mainnet de al menos 0.001 ETH, esto con el fin de evitar el abuso y bots.

1. Primero tendrás que ingresar tu dirección de Ethereum Goerli en la casilla.

2. Luego tendrás que completar un Capcha.

3. Finalmente le das al botón “Send me ETH”, autorizas la transacción en tu billetera y listo!

B) Usando goerli-faucet.pk910.de (La que toma mas tiempo)

Esta opción lo único que hay que hacer es:

1. Colocar tu dirección que recibirá los fondos.

2. Completar el Capcha.

3. Darle al botón “Start Mining” y esperar el tiempo indicado (Puede durar varias horas).

Es importante mencionar que no hay que esperar que se “minen” todos los ETH de Goerli (lo cual tarda aproximadamente 12 horas usando los 32 workers), solo es necesario esperar hasta que se recolecte la cantidad mínima requerida para poder hacer claim.

Una vez completado el tiempo solo debes darle a “Stop Mining & Claim Rewards” , autorizar la transacción desde tu billetera y listo!

C) Usando faucet.paradigm.xyz (Para los que tengan mas de 50 Seguidores en Twitter)

Para esta opción lo primero que hay que hacer es logearse (darle a “Sign in with Twitter”) con twitter y autorizar la aplicación.

Una vez que hayas ingresado con tu cuenta de Twitter solo deberás ingresar una dirección en la casilla, darle al botón “Claim” (que aparecerá después de que ingreses la dirección). Luego de un pequeña espera, los tokens apareceran en un billetera.

3. Enviando fondos de L1 a L2 (Scroll Bridge)

Una vez que tengamos los fondos en la testnet Goerli, podremos utilizarlos para cambiarlos de la L1 ( Goerli Testnet) a la L2 ( Scroll Alpha Testnet). Lo primero que hay que hacer es ingresar al portal del bridge.

El portal es bastante intuitivo e idéntico a otros bridges. Sus partes son:

1. Botón “Connect”: para conectar la billetera que sera usada para el proceso.

2. Casilla Superior (o “From”): Es en donde ingresaremos el monto, el activo (o asset) y nos indica la red desde donde se enviaran los fondos.

3. Casilla inferior (o “To”): Indica el activo y la red en donde recibiremos los fondos.

4. Botón de cambio (o “Switch”): Para cambiar la direccion desde donde queremos enviar los fondos. Ej: desde L1 a L2 ó de L2 a L1.

5. Indicador de tarifas(o “fees”): Lugar se indica la cantidad de fees requeridos para la transacción.

Cuando se realiza una transacción en el puente se ve de la siguiente manera:

En donde:

1. Se muestra la billetera que se esta utilizando.

2. Se muestra la red, el activo y el cantidad de importe desde donde se enviaran los fondos.

3. Muestra la red que recibirá el activo.

4. indica la cantidad de tarifas o el costo de la transacción para la red.

5. Botón para iniciar la transferencia entre redes.

De acuerdo a la documentación de Scroll el tiempo que toma pasar los fondos desde Goerli a Scroll Alpha es de 8 a 14 minutos.

4. Ver estado de tus transacciones (Block explorer)

Al igual que cualquier otra red, Scroll te da la oportunidad de ver el progreso y los estados de las transacciones en los exploradores disponibles.

Opción 1: blockscout.scroll.io

Esta opción utiliza la tecnología del proyecto BlockScout como explorador de bloques para el Scroll Alpha Testnet.

Consejos:

• La página de inicio del explorador de bloques muestra las estadísticas generales de la red, los últimos bloques y transacciones.

• Al hacer click en el número de bloque y en el hash de la transacción en la página de inicio, se le redirige a la página Detalles del bloque y Detalles de la transacción.

• Se puede buscar por dirección, hash de transacción o número de bloque en el cuadro de búsqueda de la esquina superior derecha para encontrar información específica.

Opción 2: scrollexplorer.unifra.io

Esta opción fue desarrollada por la Unifra que ha creado Scroll Explorer para una experiencia de exploración de bloques alternativa, que permite a los usuarios explorar aspectos adicionales de Scroll Alpha Testnet.

🤵Agradecimientos

🎉 ¡Gracias por leer hasta el final! Desde L2 en español queremos darle un especial agradecimiento a Ahmed Castro. Por ayudarnos con el contenido e investigación para la creación de este articulo.

Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

https://t.me/l2espaniol

https://twitter.com/Layer2es

Scroll es una solución de escalabilidad Layer 2 para Ethereum que utiliza la tecnología ZK. Funciona como un zkRollup equivalente a la EVM, permitiendo transacciones más rápidas y eficientes mientras mantiene la seguridad de la blockchain de Ethereum.

La pieza central de Scroll es la zkEVM, que se encarga de probar la corrección de la ejecución de EVM en la Layer 2. Este proyecto se ha estado construyendo abiertamente durante casi 2 años en colaboración con el grupo Privacy and Scaling Explorations de la Fundación Ethereum.

Sin embargo, para convertir zkEVM en un zkRollup completo en Ethereum, se necesita construir una arquitectura L2 completa alrededor de él. Este proceso ha requerido una gran cantidad de trabajo y esfuerzo por parte del equipo de desarrollo de Scroll.

Arquitectura de Scroll

En esencia la arquitectura de Scroll está compuesta de 3 piezas fundamentales.

Scroll Node: Construye los bloques L2 a partir de transacciones de usuarios, los consigna en la Layer base de Ethereum y pasa mensajes entre L1 y L2.

Roller Network: Genera las validity proofs (o pruebas de validez) de la zkEVM para demostrar que las transacciones se ejecutan correctamente.

Rollup and Bridge Contracts: Proporciona Data Availability (o disponibilidad de datos) para las transacciones de Scroll, verifica las pruebas de validez de zkEVM y permite a los usuarios mover activos entre Ethereum y Scroll.

Scroll Node

El Scroll Node es el componente principal para que aplicaciones y usuarios interactúen con Scroll. Este nodo esta conformado por tres módulos: Secuenciador, Coordinador y Relayer.

El Sequencer (o Secuenciador) se encarga de proporcionar una interfaz JSON-RPC para recibir transacciones L2. Cada pocos segundos, este módulo recupera un grupo de transacciones del mempool L2, luego las ejecuta para generar un nuevo bloque L2 y una nueva state root. Para lograr esto, se hizo un fork de Go-Ethereum (Geth), una de las implementaciones de nodos Ethereum más populares, lo que permite heredar la seguridad y compatibilidad de Ethereum.

Cuando se genera un nuevo bloque, el Coordinator (o Coordinador) es notificado y recibe un execution trace asociado al nuevo bloque desde el Secuenciador. A continuación, envía este execution trace a un Roller seleccionado aleatoriamente del Roller Network para la generación de pruebas de validez.

Por último, el Relayer se encarga de vigilar los contratos del Bridge y el Rollup desplegados tanto en Ethereum como en Scroll. Sus responsabilidades principales son supervisar el contrato rollup para hacer un seguimiento del estado de los bloques L2, incluyendo su disponibilidad de datos y prueba de validez, así como vigilar los eventos de depósito y retirada de los contratos del bridge desplegados tanto en Ethereum como en Scroll, y retransmitir los mensajes de un lado a otro.

Roller Network

La Roller Network es la responsable de generar las pruebas de validez para el zkRollup de Scroll. Los Roller actúan como provers y se espera que utilicen aceleradores como GPUs, FPGAs y ASICs para reducir el tiempo y el costo de las pruebas. El proceso consta de los siguientes pasos:

1. El Roller convierte el execution trace recibida del Coordinador en testigos (Witness) de circuito.

2. Se generan pruebas de validez para cada circuito zkEVM.

3. Las pruebas de validez de varios circuitos zkEVM se agregan para formar una única prueba de validez del bloque.

Contratos del Rollup y el Bridge

Scroll se conecta a la base Layer de Ethereum mediante el uso de los smart contracts asociados al Rollup y el Bridge. Estos contratos trabajan en conjunto para garantizar la Data Availability en las transacciones L2, al mismo tiempo que permiten a los usuarios transferir activos y mensajes entre L1 y L2.

El contrato Rollup recibe bloques L2 y las state roots del Sequencer. Las state roots se almacenan en el state de Ethereum, mientras que los datos de bloque L2 se guardan como calldata de Ethereum. Esto proporciona disponibilidad de datos para los bloques Scroll y aprovecha la seguridad de Ethereum para garantizar que los indexers, incluido el Scroll Relayer, puedan reconstruir los bloques L2. Una vez que se ha verificado la validez de un bloque L2 a través de una prueba, este se considera finalizado en Scroll.

Por otro lado, los contratos Bridge en Ethereum y Scroll permiten a los usuarios enviar mensajes arbitrarios entre L1 y L2. Además, se ha creado un protocolo bridge Trustless para transferir activos ERC-20 en ambas direcciones. Para enviar un mensaje o fondos de Ethereum a Scroll, los usuarios deben llamar a una transacción sendMessage en el contrato Bridge. El Relayer indexará esta transacción en L1 y la enviará al Sequencer para que se incluya en un bloque L2. El envío de mensajes desde Scroll a Ethereum se realiza de manera similar a través del contrato Bridge L2.

¿Cómo funciona la zkEVM de Scroll?

Luego de todo lo explicado el diagrama de operación de la zkEVM de Scroll funciona siguiendo la secuencia de pasos presentada a continuación:

Paso 1:

El Secuenciador genera una secuencia de bloques. Para el bloque i, el Secuenciador genera una execution trace T y la envía al Coordinador. Mientras tanto, también envía los datos de transacción D como calldata al contrato Rollup en Ethereum para la disponibilidad de datos, las state roots resultantes y los compromisos con los datos de transacción al contrato Rollup como estado.

Paso 2:

El Coordinador selecciona aleatoriamente un Roller para generar una prueba de validez para cada execution trace T de bloque. Para acelerar el proceso de generación de pruebas, las pruebas para diferentes bloques se pueden generar en paralelo en diferentes Rollers.

Paso 3:

Después de generar la prueba de bloque P para el bloque i, el Roller la envía de vuelta al Coordinador. Cada k bloques, el Coordinador despacha todas las pruebas recolectadas a otro Roller aleatorio, el cual agrupa las k pruebas de bloque en una sola prueba agregada A y la envia de vuelta al Coordinador.

Paso 4:

Finalmente, el Coordinador envía la prueba agregada A al contrato Rollup para finalizar los bloques L2 i+1 a i+k verificando la prueba agregada A frente a las state roots y compromisos de datos de transacción previamente enviados al contrato Rollup.

En las imágenes se ilustra que los bloques de Scroll se finalizarán en L1 en un proceso de múltiples pasos. Cada bloque L2 avanzará a través de las siguientes tres etapas hasta que se finalice.

• Pre-committed indica que un bloque ha sido propuesto por un Secuenciador y enviado a los Rollers. Aunque los bloques Precomprometidos aún no son una parte canónica de la cadena L2 de Scroll porque aún no se han publicado en la capa base de Ethereum, los usuarios que confían en el Secuenciador pueden optar por tomar medidas en anticipación.

• Committed indica que los datos de transacción de este bloque se han publicado en el contrato Rollup en Ethereum. Esto garantiza que los datos del bloque estén disponibles, pero no prueba que se hayan ejecutado de manera válida.

• Finalized indica que la ejecución correcta de las transacciones en este bloque se ha demostrado verificando una prueba de validez en la cadena en Ethereum. Los bloques Finalizados se consideran partes canónicas de la cadena L2 de Scroll.

Al poner todo esto junto, Scroll es capaz de ejecutar el bytecode nativo de EVM en L2 mientras hereda fuertes garantías de seguridad de la base layer de Ethereum.

Conclusión

En resumen, Scroll es una solución de escalabilidad Layer 2 para Ethereum que utiliza la tecnología ZK para permitir transacciones más rápidas y eficientes en la red.

La pieza central de Scroll es la zkEVM, que es como un juez de la Layer 2 que se encarga de verificar que todo lo que sucede en la red se está ejecutando de manera correcta, la cual se apoya en una arquitectura criptográfica construida alrededor de la misma.

La arquitectura de Scroll conformada por: el Scroll Node, la Roller Network y los Rollup and Bridge Contracts, que trabajan juntos para garantizar la Data Availability en las transacciones L2, al mismo tiempo que permiten a los usuarios transferir activos y mensajes entre L1 y L2.

El proyecto de Scroll ha sido construido abiertamente durante casi dos años y su potencial es evidente para los amantes de las soluciones Layer 2. Pero, como siempre, solo el tiempo dirá si la zkEVM de Scroll será un jugador importante en el futuro de la escalabilidad de Ethereum una vez que la mainnet este operativa. Lo que es seguro es que el equipo detrás de Scroll ha estado trabajando duro para hacer que la red sea más eficiente y escalable, y eso es algo que siempre es digno de aplaudir.

🤵Agradecimientos

🎉 ¡Gracias por leer hasta el final! Desde L2 en español queremos darle un especial agradecimiento a Ahmed Castro. Por ayudarnos con el contenido e investigación para la creación de este articulo.

Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

https://t.me/l2espaniol

https://twitter.com/Layer2es

En el siguiente artículo vamos a repasar cada aspecto del rollup y explicar qué salvaguardas tiene el usuario respecto de la finalidad de sus transacciones en cada punto.

Información Preliminar

Actualmente, tanto Arbitrum como Optimism, operan un solo secuenciador centralizado que está a cargo de ordenar todas las transacciones que recibe y se asume que este esta operando de manera honesta y ordenando por orden de llegada. Se supone que existen planes para descentralizar el secuenciador usando un whitelist o nodos de L2 aprobados por la comunidad, pero el roadmap sigue sin estar muy claro.

Soft Finality

Primero, el secuenciador recibe una transacción de dos maneras. Normalmente, cuando uno opera dentro de una L2, los usuarios conectan sus wallets a un nodo de L2 y envían de manera directa una transacción firmada offchain al secuenciador. En otras instancias, un usuario puede enviar una transacción al secuenciador al publicar una transacción de L1 en el contract del rollup en Ethereum; esto suele ser el caso para las operaciones realizadas en la L1 que requieran un mensaje en la L2, e.j. depositar un asset con un bridge en el rollup (depositando en la L1 y después minteando en la L2).

Después de recibir una transacción, el secuenciador ordena las transacciones offchain y emite un recibo instantáneo de la transacción al usuario como “soft finality” (finalidad blanda) dentro de 1-2 segundos. Esta transacción en tiempo real no requiere ninguna confirmación adicional onchain y se anuncia en vivo, así que cualquiera lo puede verificar y correr independientemente un State Transition Function (STF), o Función de Transición de Estado, determinista para deducir el resultado de esa transacción de manera inmediata.

Si la transacción fue enviada a la L1, el secuenciador de Arbitrum va a emitir un recibo en la L2 10 minutos antes de que esta llegue al secuenciador para asegurarse que ninguna reorganización de bloques en el corto plazo de la L1 ocurra y revierta la inclusión de las transacciones en el rollup. En Optimism Bedrock, se espera que las transacciones a la L1 se confirmen dentro de 3 minutos.

Además, en los intervalos de los bloques de la L2 en Optimism bedrock van a ser de 2 segundos (antes eran esporádicos). En Arbitrum Nitro, los intervalos de los bloques de la L2 son variables, generados 3-4 veces por segundo.

Trust Assumption

La confianza del usuario en la finalidad depende completamente de la confianza que se le tiene al secuenciador; un secuenciador que censure o esté offline podría diferir entre el orden indicado en este recibo instantáneo y el orden publicado en última instancia en un batch (lote). Lo peor que un secuenciador podría hacer es reordenar o demorar una transacción, ya que es imposible que este falsifique una transaccióndel usuario o proponaga una actualización inválida al estado.

En Arbitrum, para prevenir la censura por el secuenciador, un usuario puede forzar la inclusión de una transacción al sigueinte bloque de la L2, para bypass al secuenciador, en el caso de que este se haya atrasado por más de 24 horas - las transacciones después son incluidos en orden FIFO (first in, first out - primera en entrar, primera en salir).

En Optimism, las transacciones enviadas a la L1, se incluyen automáticamente en un bloque de la L2 lo antes posible; el primer bloque de la L2 en un rollup epoch debe incluir todas las transacciones depositadas en el primer bloque de la L1 (cada bloque de la L1 define un rollup epoch, y pueden haber varios bloques de la L2 por cada epoch).

Riesgo de Reversión

Si la transacción se envió directamente a la L2 y la L1 enfrentó una reorganización antes de que esa transacción se agrupara y finalizara en la L1, entonces las L2 podrían, en teoría, seguir creando bloques y agrupar todas esas transacciones que no lograron pasar la reorganización. Sin embargo, no hay documentación sobre esto para ninguna de las L2.

En el caso de que la transacción se envió a la L1, Arbitrum no tiene nada implementado para lidiar con una reorganización de L1. Esto no es tan grave, ya que desde el merge, hay un retraso de finalidad en la L1 de 12.8 minutos, por lo que este no está muy lejos de los 10 minutos. En Optimism, debido a que la L2 sigue a la L1 más estrechamente dentro de una ventana de 3 minutos, tendrá que manejar las reorganizaciones de L1 mediante la reorganización de L2 si es necesario, pero no se especifica cómo lo hace.

En estos escenarios, los rollups no ofrecen garantías. Las transacciones pueden nunca aparecer en la cadena y el procedimiento para su inclusión después de la reorganización no está bien detallado.

Hard Finality

Luego, el secuenciador comprime y publica las transacciones de la L2 en batches como calldata de Ethereum cada 1-3 minutos en el caso de Arbitrum y cada 30 segundos - 1 minuto en el caso de Optimism. Calldata es la parte no modificable de un smart contract que básicamente funciona como memoria y queda registrado onchain pero no como parte del estado del blockchain, lo que permite que sea más rentable para el almacenamiento de datos onchain.

En Solidity, la palabra calldata se utiliza para pasar argumentos a una función de smart contract específica. En este escenario, el secuenciador utiliza calldata para llamar a la función del contrato de rollup en la L1 y pasar datos de transacción comprimidos como input a la función. La transacción de la L2 ahora tiene la misma finalidad que el bloque L1 que la incluyó en un batch, así logrando un “Hard Finality”.

El estado de L2, que consta de cuentas, balances, contratos, etc., se estructura como un Merkle tree, llamado "árbol de estado" (state tree en inglés). La raíz de este árbol de estado es la raíz de estado de la L2 (state root) y define el estado más reciente del rollup, que se guarda en el contrato de rollup de la L1. Un secuenciador necesita enviar las raíces de estado antiguas (estado antes de las transacciones agrupadas) y nuevas (estado después de que se ejecutan las transacciones agrupadas) al publicar batches, que son necesarios para demostrar que los cambios en el estado son correctos.

Una vez que el secuenciador envía el batch, el contrato verifica que el state root previo coincida con el state root existente. Si las dos coinciden, el contrato descarta el antiguo state root y almacena un nuevo state root propuesto por el secuenciador.

Trust Assumption

El usuario ahora puede usar el estándar de finalidad que desee para las transacciones regulares en la L1 hacia la transacción en la L2 que ahora está incluida en un bloque de la L1. La ejecución en rollups optimistas es completamente determinista; un estado del chain actual y nuevo input data (datos de entrada) son suficientes para calcular el nuevo estado de la cadena a través del STF. En el momento en que este input data está disponible cuando el secuenciador publica un batch, se puede computar el nuevo estado de la L2 y el orden de las transacciones está determinado por la L1; el secuenciador ya no tiene más input. Los datos del batch publicados en la L1 están disponibles y son suficientes para que cualquier nodo reconstruya y valide el estado de la L2.

Cualquier usuario que no esté cómodo con las trust assumptions del secuenciador en la "soft finality" simplemente puede esperar a que el Secuenciador publique su transacción en un batch, ya que ofrece las mismas garantías que la finalidad L1.

Riesgo de Reversión

Los batches pasan por una reestructuración solo si Ethereum también lo hace.Esto se vuelve menos probable a medida que la presentación de los batches es seguida por más confirmaciones. Ya que estos batches se envían como calldata de Ethereum, no hay forma de censurar o modificarlos después de que la transacción se incluye en un bloque que tiene suficientes atestaciones; así es como las L2 heredan las garantías de seguridad de Ethereum. Por lo tanto, las transacciones de Arbitrum y Optimism que experimentan una "hard finality" están protegidas contra grandes reorganizaciones de bloques siempre que el mecanismo de consenso de Ethereum lo esté.

Período de Desafío y Retiro

En Arbitrum, los validadores (actualmente con whitelist) verifican los batches de transacciones de la L1, los procesan uno a la vez utilizando un STF determinista y pueden impugnar el state root de la L2 publicada en el batch. El contrato de rollup en la L1 acepta nuevas raíces de estado inmediatamente después de que se publican, por lo que los state commitments (compromisos de estado) se pueden publicar en Ethereum sin la necesidad de una prueba de que sean correctos (por lo tanto optimistas, ya que se espera que sean correctos, de ahí el nombre de los rollups).

Si un state commitment propuesto no se impugna durante el período de desafío, se considera definitivo, después de lo cual los smart contracts en Ethereum pueden aceptar de manera segura pruebas de retiro sobre el estado de la L2 basado en ese commitment. Si se impugna con éxito un state commitment, el batch que no sea válido y los que sean publicados después de este serán revertidos, restaurando el rollup a su antiguo state root. El protocolo de rollup luego necesitará volver a ejecutar las transacciones y actualizar el estado del rollup.

Cualquier otro validador puede impugnar el state root dentro del período de desafío, el cual es de una semana, que incluye un juego de pruebas de fraude interactivo de varias rondas que finalmente será resuelto por la L1. Siempre que haya al menos un validador honesto, se garantiza que el state root de la L2 correcto se publique en la L1. Las pruebas de fraude utilizadas para impugnar los state commitments actualmente no están implementadas en Optimism.

Después de que el período de desafío ha terminado, finalmente se permiten los retiros. Los retiros son transacciones entre dominios (cross-domain) que se inician en la L2 y se finalizan mediante una transacción ejecutada en la L1, como para transferir tokens de una cuenta en una L2 a una cuenta en la L1. Un usuario simplemente necesita proporcionar una prueba de Merkle (usando calldata) al contrato de rollup que demuestra que su transacción fue incluida en el state root del rollup.

Trust Assumption

Si algún validador intenta desviarse del estado de la L2 válido, un validador honesto podrá impugnar esto. Solo necesitamos un validador honesto para que esto ocurra, por lo que sabemos que el estado válido finalmente prevalecerá. Un solo nodo honesto es todo lo que se necesita para avanzar la chain correctamente, publicando afirmaciones válidas o impugnando afirmaciones inválidas.

Riesgo de Reversión

Un state commitment (el resultado de ejecutar las transacciones) puede ser invalidado a través de una prueba de fraude exitosa y eliminado para finalmente ser reemplazado por otro commitment propuesto. Pero un desafío exitoso no reorganiza la L2 ni afecta la finalidad de la transacción; todavía está incluido en la L1. Solo significa que el cálculo del resultado de esta transacción en el estado de la chain es incorrecto y se volverá a calcular. El orden de las transacciones y el estado de la L2 no se ve afectado por un desafío de prueba de fraude.

Bridging Implication

Hemos desarrollado un marco que los bridges pueden seguir y los tipos de finalidad que ofrecerían garantías suficientes en diferentes casos de uso. Operaremos bajo el supuesto de que los bridges están ejecutando nodos completos en Arbitrum/Optimism y validando todas las transacciones del rollup. De esta manera, el puente no depende de los state commitments o las pruebas de fraude (por lo que no importa mucho que las pruebas de fraude aun no hayan sido implementadas en Optimism). Incluso cuando se implementen las pruebas de fraude, los puentes no necesitarán esperar el período de desafío de una semana, lo que permitirá a los usuarios acceder a sus activos antes. Creemos que usar los datos por batches de "hard finality" es suficiente, y los retiros de tokens se pueden implementar en bridges que se basan en el hard finality (dos épocas) en lugar del período de desafío (una semana).

En ciertos escenarios, los puentes aceleran el proceso aún más al permitir que los protocolos operen en commitment de "soft finality", hasta la especificación del cliente. Todas las transacciones son vistas por cada uno de los validadores para el bridge al conectarse directamente a sus nodos operados de forma independiente. En lugar de validar solo los mensajes que alcanzan la finalidad en la chain original, que en este caso son dos épocas, los bridges brindan flexibilidad, permitiendo a los integradores especificar un mensaje más rápido si así lo desean, desde la entrega inmediata basada en recibos de transacciones instantáneos (publicando la transacción tan pronto como se recibe), hasta el límite original de dos épocas e incluso períodos más largos si es necesario.

En ciertos casos de uso, simplemente observar el registro del secuenciador puede considerarse "suficientemente seguro"; por ejemplo, si los oráculos quisieran emitir desde Ethereum, solo importa la validez de los mensajes, no tanto que los mensajes alcancen el consenso. Siempre que el puente ejecute nodos completos, se garantiza la validez de los mensajes y la mensajería más rápida podría ser una opción viable.

Trust Assumption

Para mensajes regulares, el bridge no tiene que confiar en el secuenciador para la disponibilidad, ya que los usuarios también pueden enviar transacciones directamente a la L1 (aunque a un costo de gas más alto) y no necesitamos confiar en su seguridad, ya que las transacciones se finalizan en la L1.

Para mensajes personalizados y más rápidos, sí tenemos que confiar en el secuenciador, ya que no hay ningún mecanismo que impida que el secuenciador se desvíe de su orden de transacción esperado - por orden de llegada y del orden que realmente publica en la L1. Este riesgo lo asume completamente el remitente que especifica que su mensaje sea retransmitido de inmediato en lugar de esperar la finalidad de la L1. Por lo tanto, un bridge de tokens debe seguir contando con el límite de 2-epochs, mientras que los mensajes order-insensitive (insensibles al orden) pueden ser verificados antes de la finalidad si así se desea.

Conclusión

En esta publicación, exploramos las suposiciones de confianza en cada fase del rollup optimista y el riesgo de reversión asociado con ellas. Luego vinculamos estos diferentes niveles de finalidad a las decisiones de diseño que consideran los protocolos de puente genéricos para que los usuarios y las aplicaciones entre chains tengan confianza en comprender las garantías que especifican para sus transacciones.

¡Hola comunidad! 👋

Hoy les presentamos la primera parte de una serie de dos artículos en los que exploraremos todo lo que necesitan saber sobre Polygon zkEVM. Esta solución de escalabilidad descentralizada de Ethereum Layer 2 utiliza pruebas criptográficas de conocimiento cero (ZK Proof), para acelerar la validación y finalización de las transacciones fuera de la cadena, también conocido como ZK Rollup.

Si están interesados en conocer cómo funciona esta solución de escalabilidad descentralizada y cómo puede mejorar su experiencia en la red Ethereum, ¡no se pierdan esta ni la venidera segunda parte!

🟣 ¿Qué es Polygon zkEVM?

A diferencia de otras soluciones de escalabilidad, Polygon zkEVM no solo es compatible con EVM de Ethereum, sino que también mejora significativamente su equivalencia con la EVM a través de pequeños cambios.

En esta primera parte, abordaremos los componentes de esta nueva arquitectura, el ciclo de vida de las transacciones en Polygon zkEVM, el esquema del puente Polygon zkEVM y otros aspectos importantes, pero primero empecemos viendo como Polygon zkEVM propone mejorar ETH e incorpora tecnologías valiosas como pruebas de validez de conocimiento cero (ZK - Validity Proof).

🧗‍♂️Escalando Ethereum con zkEVM

Como hemos visto en varias ocasiones, la blockchain de Ethereum basada en la tecnología de libro mayor distribuido (DLT), se enfrenta a un desafío conocido como el trilemma de la escalabilidad, la descentralización y la seguridad, lo que significa que no puede escalar más allá de su umbral de transacción sin sacrificar uno o más de estos factores.

Para abordar este problema, Polygon ha desarrollado la zkEVM, una máquina virtual que emula la EVM (máquina virtual Ethereum) y soporta todos los códigos de operación existentes en Ethereum. Esto permite la implementación transparente de Smart Contracts de Ethereum en la capa 2 de la red, lo que aumenta significativamente la escalabilidad y la cantidad de transacciones por segundo (TPS), mientras mantiene la seguridad de la capa principal de Ethereum

La zkEVM es una máquina de estado que procesa las transacciones de capa 2 enviadas por los usuarios a la red, generando pruebas de validez o Validity Proofs. Estas pruebas son rápidas y sencillas de verificar, garantizando la integridad de los cambios de estado realizados.

La red zkEVM de Polygon apunta a ser una red descentralizada, sin permisos, altamente segura y eficiente, diseñada para proporcionar una solución que reduzca la fricción para los usuarios y desarrolladores. Los esfuerzos de desarrollo permiten que cualquier persona que tenga el software zkEVM participe en la red. Además, el algoritmo de consenso brinda a todos la oportunidad de desempeñar el papel de Secuenciador o Agregador (también conocido como provers).

Hemos visto la importancia de la DA en artículos anteriores desde L2 en Español, y como esta disponibilidad de datos es crucial para la descentralización, pero el equipo de zkEVM aún tiene que decidir la mejor configuración para garantizar que no haya censura y que ninguna de las partes pueda controlar la red, por lo que no se puede definir uno establecido.

La seguridad es una consideración clave en la arquitectura de zkEVM, y como solución L2, la mayor parte de la seguridad se hereda de Ethereum. Los contratos inteligentes asegurarán que todos los que ejecutan cambios de estado lo hagan de manera adecuada, creen una prueba que acredite la validez de un cambio de estado y pongan a disposición pruebas de validez en la cadena para su verificación.

🧬 PIL-STARK

La tecnología zkEVM de Polygon tiene como objetivo crear una máquina de estado genérica que funcione como un procesador, con registros y un reloj. Esta máquina recibe instrucciones en forma de programas escritos en ensamblador y realiza transiciones de estado en cada pulso del reloj según estas instrucciones.

Consulte la figura a continuación para ver un ejemplo de una máquina de estado con los registros A y B y un estado que cambia a otro estado en función de dos instrucciones.

Para implementar pruebas ZK en zkEVM de Polygon, se ha desarrollado una implementación especial de STARK llamada PIL-STARK. Esta implementación utiliza el lenguaje de dominio específico PIL (Polynomial Identities Language), para nombrar polinomios y describir las identidades que definen los cálculos realizados por la máquina de estado. Además, se basa en el protocolo FRI para su esquema de Compromiso polinómico.

Si desea obtener más información acerca de las matemáticas y el funcionamiento detrás del lenguaje Polynomial PIL, puede revisar el vídeo que hemos dejado a continuación para tener una mejor comprensión. A continuación, profundicemos en la arquitectura de zkEVM y sus componentes principales.

🏗️ Arquitectura Polygon zkEVM

La arquitectura de Polygon zkEVM se enfoca en manejar las transiciones de estado, que resultan de las ejecuciones de transacciones de la capa 2 enviadas por los usuarios a la red.

Los componentes principales de Polygon zkEVM que permiten su funcionamiento eficiente y seguro son los siguientes:

• Contrato de consenso: PolygonZkEVM.sol

• zkNode

  • Sincronizador

  • Secuenciadores y Agregadores

  • RPC

• zkProver

• Puente zkEVM

Cada uno de estos componentes desempeña un papel importante en el funcionamiento de la máquina virtual zkEVM de Polygon, en la mejora de la escalabilidad y las transacciones por segundo de Ethereum.

🤝 Contrato de Consenso

Como dato curioso, el equipo tras Hermez siempre ha innovado en la descentralización de los rollups. De hecho, la versión anterior, Polygon Hermez 1.0, un ZK Rollup para pagos instantáneos, se basó en el mecanismo de consenso llamado Prueba de Donación (PoD). Esta fue básicamente una subasta descentralizada realizada automáticamente, en la que los participantes (coordinadores) ofrecían un cierto número de tokens para ser elegidos y crear el siguiente bloque.

En el antiguo mecanismo de PoD, se establecieron incentivos económicos para que los validadores fueran altamente eficientes y competitivos, ya que se basaba en un modelo de subasta descentralizado para obtener el derecho de producir bloques en un plazo específico.

El nuevo Contrato de Consenso, PolygonZkEVM.sol, aprovecha la experiencia del mecanismo de PoD de la versión 1.0, pero con la adición del soporte para múltiples coordinadores sin permiso para producir bloques en la capa 2.

Esta última versión del Contrato de Consenso zkEVM (desplegado en la capa 1) se modela después de la Prueba de Eficiencia (Proof of Efficiency). Aprovecha la experiencia del mecanismo PoD existente en la versión 1.0 y agrega soporte para múltiples coordinadores sin permiso para producir bloques en la capa 2.

En la parte dos de esta serie se tratarán otros temas, incluyendo su Modelo de Implementación, tokenomics y estructura de incentivación, si desea aprender más sobre ellos.

🤖🔗 ¿Qué es zkNode?

El zkNode es el software necesario para ejecutar cualquier nodo zkEVM en la red Polygon. Funciona como un cliente que ayuda a implementar la sincronización y a gobernar los roles de los participantes, ya sean Secuenciadores o Agregadores.

Los usuarios de Polygon zkEVM pueden elegir participar en la red como un simple nodo para conocer el estado de la red, o como participante en el proceso de producción por lotes en cualquiera de los dos roles mencionados anteriormente. La arquitectura del zkNode es modular para mayor flexibilidad y eficiencia.

El zkNode se puede utilizar en tres modos diferentes: Secuenciador, Agregador y RPC.

Modo Secuenciador: el nodo zkNode cuenta con una instancia de Estado L2, una API integrada para manejar las interacciones de los usuarios L2 (como solicitudes de transacción y consultas de Estado L2) y gestiona la transmisión por batch a otros nodos de la red L2. También cuentan con una base de datos para almacenar temporalmente las transacciones que aún no han sido ordenadas ni ejecutadas (pool de transacciones pendientes), así como todos los componentes necesarios para interactuar con L1 y mantener su Estado L2 local actualizado

Modo Agregador: el nodo zkNode cuenta con todos los componentes necesarios para ejecutar batch de transacciones, calcular el Estado L2 resultante y generar las pruebas de integridad computacional llamadas Validity Proof. Además, puede obtener batch de transacciones comprometidos en L1 por el Secuenciador de Confianza y verificar públicamente las transiciones de Estado L2 en L1 mediante la llamada a funciones específicas.

Modo RPC: el nodo zkNode tiene una funcionalidad limitada. Principalmente mantiene una instancia actualizada del Estado L2, utilizando los batch transmitidos por el Secuenciador de Confianza y las secuencias de batch obtenidos del Contrato de Consenso. Además, el nodo interactúa con L1 de manera continua para mantener el Estado L2 local actualizado y verificar la sincronización de las raíces de Estado L2. La tasa de sincronización predeterminada del sincronizador es de cada 2 segundos, aunque se puede modificar en la configuración.

🕵️ ¿Cómo funciona zkProver?

Ahora nos centraremos en resumir la descripción general esquelética del zkEVM que emplea tecnología avanzada de ZK para crear Validity Proof. Utiliza un zkProver que se puede ejecutar en cualquier servidor y está diseñado para ser compatible con la mayoría del hardware de consumo. Cada Agregador utilizará este zkProver para validar batch y proporcionar Validity Proof.

El zkProver consta de un Ejecutor de Máquina de Estado Principal, una colección de Máquinas de Estado secundarias (cada una con su propio ejecutor), un generador de pruebas STARK y un generador de pruebas SNARK.

El zkEVM expresa los cambios de estado en forma polinómica. Como resultado, las restricciones que debe cumplir cada batch propuesto son restricciones polinómicas o identidades polinomiales. Para decirlo de otra manera, todos los batch válidos deben satisfacer restricciones polinómicas específicas, aunque veremos más sobre el proceso en la segunda* *parte del artículo.

🔄 Ciclo de vida de las transacciones

Para realizar cualquier transacción en Polygon zkEVM, los usuarios necesitan disponer de fondos en esta capa. Esto se logra mediante la transferencia de una cantidad de éter desde L1 a L2 a través del puente zkEVM de Polygon.

🌉 ¿Qué es el puente zkEVM?

El puente zkEVM de Polygon es un contrato inteligente que permite la transferencia segura de activos entre dos capas (L1 y L2). Este puente es descentralizado y consta de dos contratos inteligentes, uno en L1 y otro en L2. El contrato del puente L1 se encarga de administrar las transferencias de activos entre rollups, mientras que el contrato del puente L2 se responsabiliza de las transferencias de activos entre Mainnet y el Rollup.

El ciclo de vida de las transacciones en L2 comienza con la transferencia de ether desde L1 a L2 a través del puente zkEVM. La interoperabilidad de L2 permite migrar activos entre diferentes redes nativamente, y el puente zkEVM de Polygon se encarga de asegurar la comunicación y migración de activos entre la red Polygon zkEVM y otras redes. Los contratos inteligentes L1 en los rollups L2 garantizan la correcta gestión de las transiciones de estado L2 y la disponibilidad de datos. Ahora, veamos cómo es el esquema del puente.

🔗 Esquema del puente Polygon zkEVM

El esquema del puente Polygon zkEVM implica dos redes (L1 y L2). Para mover un activo entre ambas redes, un usuario debe bloquear el activo en la red de origen (Capa 1). El contrato inteligente del puente crea un activo representativo de valor equivalente en la red de destino L2, que se conoce como Token envuelto.

Una vez acuñado el Token envuelto, el usuario o destinatario en la red de destino L2 puede reclamar el activo. También es posible realizar la operación opuesta; después de quemar el token envuelto, el Bridge SC desbloquea el activo original en la red de origen.

El Bridge SC también puede utilizarse para la mensajería entre cadenas, lo que permite enviar cargas de datos de una red a otra a través de las operaciones Puente y Reclamación.

📄 Características del contrato zkEVM Bridge

El zkEVM Bridge SC se implementa utilizando el diseño del contrato de depósito de Ethereum PoS como base, pero con algunas modificaciones. Por ejemplo, en lugar de utilizar árboles Merkle convencionales, emplea árboles Merkle de agregación especialmente diseñados. A pesar de estas diferencias, la lógica subyacente del contrato zkEVM Bridge es la misma que la del Contrato de Depósito de Ethereum.

Además de las diferencias mencionadas en la implementación del contrato zkEVM Bridge en comparación con el Contrato de Depósito de Ethereum 2.0, hay otras relacionadas con el hash base y los nodos hoja:

1. El Contrato de Depósito utiliza la función hash SHA256, mientras que zkEVM utiliza la función hash Keccak. La razón detrás de esta elección es que, además de ser compatible con EVM, la función hash Keccak tiene un costo de gas más bajo en la red Ethereum.

2. El contrato Bridge genera tokens envueltos la primera vez que se agrega un nuevo token a la red zkEVM. Además, se agregan los metadatos del token ERC20, como el nombre, el número de decimales o el símbolo, a la información contenida en la hoja.

La característica principal del contrato inteligente Polygon zkEVM Bridge es el uso de Árboles de Salida (Exit Trees) y el Árbol de Salida Global (Global Exit Tree), con la raíz del árbol de salida global que sirve como la fuente principal de la verdad del estado.

El uso de dos distintos administradores de Raíz de Salida Global (Global Exit Root) para L1 y L2, así como lógica separada para el contrato Bridge SC y cada uno de estos administradores de raíz de salida global, permite una amplia interoperabilidad de red.

Cualquier nodo de L1 y L2 puede validar todas las transferencias de activos gracias a la DA. El zkEVM Bridge SC desplegado en L1 utiliza la función Claim para finalizar las transferencias y el Agregador recibe una compensación en tokens MATIC por su función. La cantidad de tokens ganados por cada secuencia agregada, llamada batchReward, se determina por el saldo total del contrato MATIC y el número de secuencias agregadas.

Si deseas aprender más sobre el árbol de estado utilizado en zkEVM y sus características, te recomendamos ver el siguiente vídeo

🔌 ¿Equivalencia o compatibilidad?

En el siguiente análisis evaluaremos las propuestas de zkEVM en cuanto a su compatibilidad o equivalencia con EVM. Para obtener más información, te invitamos a revisar nuestro artículo "Comparando las zkEVM en testnet", donde examinamos en detalle las diferentes implementaciones de zkEVM y comparamos su rendimiento y funcionalidad en su red de prueba.

https://mirror.xyz/layer2es.eth/YPGL8m1ve2aA_Ql6496f4yjuxkU1NIUSDM4EH6u10i0

En general, una solución compatible requeriría menos cambios en el código que una solución equivalente. Sin embargo, hay casos en los que incluso una solución compatible puede requerir cambios significativos en el código, especialmente si las dos soluciones son muy diferentes en su diseño o arquitectura.

El objetivo de lograr la equivalencia es tener una solución que sea lo más similar posible a la solución original, lo que minimiza los cambios necesarios en el código y reduce el riesgo de introducir nuevas vulnerabilidades de seguridad. Además, la equivalencia permite que las aplicaciones, herramientas e infraestructura creadas para la solución original sean compatibles de manera más efectiva con la nueva solución.

🔧 Modificaciones de opcodes en zKEVM vs EVM

Los opcodes en zkEVM son las instrucciones básicas que permiten la ejecución de contratos inteligentes en la cadena de bloques. En comparación con EVM, zkEVM ha realizado algunos cambios en los opcodes para mejorar la seguridad y el rendimiento.

La siguiente sección detalla los cambios que se han realizado en los opcodes en zKEVM en comparación con EVM:

• AUTODESTRUCT: Ha sido eliminado y reemplazado por ENVIAR.

• EXTCODEHASH: Devuelve el hash del código de bytes del contrato del árbol de estado zkEVM sin verificar si la cuenta está vacía.

• DIFFICULTY: Devuelve "0" en lugar de un número aleatorio como en el EVM.

• BLOCKHASH: Devuelve todos los hash de bloque anteriores en lugar de solo los últimos 256 bloques. BLOCKHASH es la raíz del estado al final de una transacción procesable y se almacena en el contrato inteligente del sistema.

• NUMBER: Devuelve el número de transacciones procesables.

📦💻 Contratos precompilados en zKEVM

Los contratos precompilados en zkEVM son programas que se ejecutan automáticamente en la cadena de bloques sin la necesidad de ser invocados directamente por un contrato inteligente. En zkEVM, algunos de los contratos precompilados son diferentes a los de EVM:

• eRecover: Permite la recuperación de una clave pública a partir de una firma y un hash de mensaje.

• identity: Proporciona una manera segura de verificar la identidad de un usuario en la cadena de bloques.

Los demás contratos precompilados no tienen efecto en el árbol de estado zkEVM y se tratan como un revert, devolviendo todo el gas al contexto anterior y estableciendo el success bandera a "0".

🧐 Otras diferencias menores en zKEVM

En la implementación de zkEVM, cuando se despliega un contrato en una dirección, el almacenamiento no se limpia (es decir, no se borra). Esto se debe a la manera en que está diseñado el árbol de estado de zkEVM, que no requiere borrar el almacenamiento cuando se despliega un contrato, otras diferencias son:

• El opcode JUMPDEST está permitido en push bytes para evitar el análisis de bytecode en tiempo de ejecución.

• La zkEVM implementa EIP-3541 de la Hardfork de Londres.

• EIP-2718, que define el Typed Transaction Envelope, no es compatible.

• EIP-2930, que define el tipo de transacción Optional Access Lists, no es compatible.

Como hemos podido comprobar la compatibilidad y la equivalencia son objetivos diferentes, y aunque ambas buscan facilitar la integración entre diferentes soluciones, la equivalencia tiene como objetivo lograr una integración más profunda y sin problemas que la compatibilidad. En el caso de Polygon zkEVM, el objetivo es lograr la equivalencia con el EVM de Ethereum, lo que permite una integración profunda y sin problemas entre ambas soluciones.

📊 Eficiencia y estrategia general

Para terminar esta primera parte de la serie repasemos como la eficiencia es clave para el rendimiento de la red. zkEVM aplica varias estrategias de implementación para garantizar la eficiencia. A continuación se enumeran algunas de ellas:

• La primera estrategia: Desplegar un Contrato de Consenso, que incentiva a los Agregadores más eficientes a participar en el proceso de generación de pruebas.

• La segunda estrategia: Llevar a cabo todos los cálculos fuera de la cadena mientras se mantienen solo los datos necesarios y las pruebas ZK en la cadena.

• La tercera estrategia: Forma en que se implementa el contrato inteligente de puente, como la liquidación de cuentas de manera UTXO, utilizando solo las raíces del árbol de salida.

• Estrategias combinadas: Utilización de primitivas criptográficas especializadas dentro del zkProver para acelerar los cálculos y minimizar el tamaño de las pruebas, como se ve en:

  • Ejecución de un lenguaje de ensamblaje ZK (zkASM) para la interpretación de códigos de bytes.

  • Uso de herramientas ZK como zk-STARKs para fines de demostración, estas pruebas son muy rápidas, aunque son más grandes en tamaño.

  • En lugar de publicar las pruebas zk-STARK de gran tamaño como pruebas de validez, se utiliza un zk-SNARK para atestar la corrección de las pruebas zk-STARK. Estos zk-SNARK se publican a su vez como pruebas de validez de los cambios de estado. Esto ayuda a reducir los costos de gas de 5 millones a 350K.

La red zkEVM de Polygon se ha propuesto ofrecer una solución eficiente y de baja fricción para los usuarios y desarrolladores de aplicaciones descentralizadas. Esto ha sido posible gracias a la implementación de estrategias de eficiencia, como las descritas anteriormente. Con esto hemos aprendido cómo Polygon está ofreciendo una solución de cadena de bloques eficiente y de baja fricción a través de su red zkEVM.

Agradecimientos

🎉 ¡Gracias por leer hasta el final! Si está interesado en seguir aprendiendo y colaborando con nosotros, le invitamos a revisar nuestra biblioteca sobre zkEVM Polygon para obtener más detalles y también nuestra Biblioteca de Layer 2 en Español para estar actualizado sobre diversas soluciones.

En la segunda parte, profundizaremos en el funcionamiento de Proof of Efficiency, la gestión de estados del Rollup L2 y proporcionaremos ejemplos visuales del explorador de bloques para una mejor comprensión.

Además, 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!

Uno 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 nueva información es válida en lugar de tener que confiar ciegamente en que los block producers (en español, productores de bloques) son honestos.

De lo dicho anteriormente podemos decir que no es posible validar cálculos si falta algún dato. Y es allí donde la Data Availability entra en escena.

🤷‍♂️¿Qué es la Data Availability (DA)?

En términos de una blockchain, la Data Availability, o “Disponibilidad de datos” en español, se refiere a la capacidad de los nodos de la red para acceder a la información de los blocks almacenados en la blockchain. Esto incluye la capacidad de leer y verificar los datos, así como la capacidad de escribir y reproducir de nuevo los mismos datos para su verificación.

Asegurar la Data Availability es crucial para el funcionamiento de una blockchain, ya que permite a los nodos participar en el proceso de consenso y garantiza que la blockchain pueda continuar funcionando incluso si algunos nodos fallan o se desconectan.

Podemos decir entonces que la Data Availability depende de la información que contienen los blocks. Por su parte los blocks están conformados por 2 partes:

• Block Head: este contiene información (metadata) sobre el block. Esto incluye el número del block, el hash del block, la timestamp, etc.

• Block Body: El cuerpo de block consiste en todos los datos de transacciones procesados como parte del block en cuestión.

🤔¿Cómo funciona la verificación de un block?

En primer lugar, el block producer:

1. Toma transacciones de la mempool.

   (La mempool es un mecanismo que actúa como una “sala de espera” para las transacciones que aún no han sido incluidas en un block)

2. Produce un nuevo block con esas transacciones con un orden específico.

3. Transmite el nuevo block a la red P2P de validadores para que sea agregado a la chain.

   (En una red de “Proof of work” se llama al block producer "miner", mientras que en una red de “Proof of stake” se llama "validator".)

A continuación, los nodos validadores (también conocidos como nodos completos o Full nodes en inglés):

1. Descargan la data de las transacciones del block recién propuesto.

2. Reejecutan las transacciones para confirmar su cumplimiento con las reglas de consenso.

3. Agregan el block a la cabeza de la chain una vez que la red determina que el block es válido.

   La siguiente ilustración se encuentra un como ejemplo de una block verification:

👊Los desafíos de la Data Availability

Como se mencionó previamente, la Data Availability es esencial para la mayoría de las blockchains. Sin embargo, mantener esta disponibilidad puede ser complicado y está sujeto a problemas. ¿Cuáles son los desafíos comunes asociados a la disponibilidad de datos? Pues tenemos dos grandes desafíos que deben abordarse:

1. Requerir que los nodos de la blockchain descarguen y verifiquen los datos puede reducir el rendimiento, o sea, la escalabilidad.

2. El uso de almacenamiento on-chain para una cantidad cada vez mayor de datos limita intrínsecamente el número de entidades que pueden ejecutar nodos.

Las redes blockchain monolíticas (ejemplo: Bitcoin, Solana o Ethereum hoy) garantizan la Data Availability almacenandola en varios nodos para que los participantes de la red que necesiten esta información puedan solicitarla a otro peer (“par” en español) o nodo de la red. Por desgracia, esta implementación de la disponibilidad de datos incluye numerosos problemas.

Requerir que un gran número de nodos descarguen, almacenen y verifiquen los mismos datos reduce significativamente el rendimiento de las blockchains. Esta es la razón por la que la velocidad de procesamiento de las redes blockchain como Ethereum y Bitcoin es relativamente baja.

Por otro lado, el almacenamiento de datos en la chain también conlleva un aumento significativo del tamaño de la blockchain, lo que resulta en un aumento exponencial de los requisitos de hardware para los llamados nodos completos, que necesitan acumular mayores cantidades de states. Además, el aumento de los costes de hardware reduce el número de individuos o entidades con recursos suficientes para correr nodos, lo que contribuye al riesgo de centralización.

🎭Diferencia entre Storage, Data Availability (DA) y Data Availability Committee (DAC)

El término "Storage" se refiere al proceso de almacenamiento de datos en una red. En el contexto de las criptomonedas, se utiliza para hacer referencia al almacenamiento de información de las transacciones en la blockchain. La blockchain es una base de datos distribuida que almacena todos los registros de las transacciones realizadas en la red. El proceso de "Storage" garantiza que los datos se almacenen de manera segura y permanente, lo que asegura la integridad y transparencia de las transacciones en la red.

Por otro lado, "Data Availability" hace referencia a la disponibilidad de los datos en la red. Su objetivo es asegurar que los datos almacenados en la blockchain estén disponibles para los nodos de la red en todo momento. Esto es esencial para el correcto funcionamiento de la red, ya que cualquier interrupción o pérdida de datos podría generar graves problemas.

Finalmente, el "Data Availability Committee" es un grupo de personas o entidades que manejan nodos en conjunto para garantizar la disponibilidad de los datos en la red. Este comité está conformado por diferentes nodos y su objetivo principal es asegurar que los datos estén disponibles en todo momento. Los miembros del comité supervisan la disponibilidad de los datos y toman medidas inmediatas en caso de que se produzca alguna interrupción.

En conclusión, en la industria cripto, el proceso de "Storage" se encarga del almacenamiento de datos en la blockchain, la "Data Availability" garantiza la disponibilidad de los datos en la red y el "Data Availability Committee" son un grupo de nodos que se encargan de supervisar y garantizar que los datos estén siempre disponibles. Estos tres conceptos son fundamentales para asegurar la seguridad y el correcto funcionamiento de la red en la industria cripto.

📊Tipos de sistemas de Data Availability en blockchain

⛓On-chain Data Availability

La solución convencional para abordar la Data Availability consiste en exigir a los block producer que publiquen todas las transacciones on-chain y que los nodos de validación las descarguen. Esta On-chain Data Availability es una característica de las "blockchains monolíticas", las cuales se encargan de la Data Availability, la ejecución de transacciones y el consenso en una sola layer. Ethereum, por ejemplo, almacena datos de estado de manera redundante en toda la red para garantizar que los nodos tengan acceso a los datos necesarios para reproducir transacciones, verificar actualizaciones de estado y señalar transiciones de estado no válidas.

No obstante, esta On-chain Data Availability puede representar un obstáculo para la escalabilidad. Las blockchains monolíticas suelen tener velocidades de procesamiento lentas debido a que los nodos deben descargar cada block y reproducir las mismas transacciones. Además, requiere que todos los nodos almacenen cantidades cada vez mayores de estado, lo que puede afectar la descentralización. Si el estado de Ethereum aumenta, los validadores deberán invertir en máquinas más grandes, lo que probablemente reduciría el número de personas dispuestas a ejecutar un nodo validador.

💾Off-chain Data Availability

La Off-chain Data Availability  se refiere a sistemas que trasladan el almacenamiento de datos de la blockchain a otra layer, lo que permite obtener escalabilidad sin aumentar los requisitos de nodos. Este tipo de DA es la utilizada por las blockchains modulares, la chain gestiona algunas tareas como la ejecución de transacciones y el consenso, mientras que otras, como la Data Availability, se descargan en otra layer.

Por ejemplo, las soluciones de escalado como validiums y plasma utilizan el almacenamiento off-chain para separar la Data Availability del consenso y la ejecución. Aunque esta técnica mejora la eficiencia, también tiene implicaciones negativas para la descentralización, la seguridad y la confianza, ya que los participantes deben confiar en los block producers para que no incluyan transacciones no válidas en los blocks propuestos.

Para evitar estos problemas, algunas soluciones de escalado, como los Optimistic Rollups y los ZK Rollups, almacenan los datos de las transacciones en la blockchain matriz, como Ethereum, utilizando esta mainnet como layer de Data Availability. De esta manera, se evita la necesidad de confiar en terceros, garantizando una mayor seguridad y descentralización.

📝Soluciones para los problemas de la Data Availability

Los problemas de Data Availability están asociados a la capacidad de verificar si los datos de una transacción están disponibles para un block recién propuesto. Para resolver este problema, se necesitan mecanismos que garanticen la Data Availability de las transacciones. A continuación, se presentan 4 posibles soluciones:

🧩Data Availability Sampling (DAS)

Es un mecanismo criptográfico que permite a los nodos de la blockchain verificar que los datos están disponibles sin tener que descargar la totalidad de un block. En este sistema, los nodos toman pequeñas muestras aleatorias de diferentes partes del block simultáneamente para verificar la disponibilidad de los datos. Debido a que muchos nodos toman muestras de diferentes partes del bloque, la disponibilidad se puede verificar con gran certeza estadística.

📜Data Availability Proofs

Aunque el mecanismo DAS garantiza estadísticamente la disponibilidad de los datos de un block, los nodos maliciosos pueden ocultar datos. Por lo tanto, para resolver este problema, se puede combinar el DAS con la "codificación de borrado" para crear Data Availability Proofs. La codificación de borrado es un método que permite a las redes duplicar conjuntos de datos añadiendo piezas redundantes conocidas como "códigos de borrado". Si se pierden los datos originales, es posible utilizar códigos de borrado para reconstruir la información original.

👨‍👩‍👧‍👦Data Availability Committees (DAC)

Son grupos de entidades autorizadas encargadas de mantener copias de los datos off-chain de la blockchain. Un DAC está formado por miembros de confianza designados para esta función específica. Los productores de blocks deben enviar los datos de las transacciones a los miembros del DAC cuando realizan transiciones de estado. Aunque este método logra poner la información a disposición de los usuarios, tiene un efecto negativo en la descentralización, ya que se depende de los miembros del comité para disponer de la data.

💰Data Availability Committees basados en Proof of Stake

Si bien los Data Availability Committees son mejores para asegurar la data, aún quedan huecos en la confianza. ¿Qué sucede si el DAC se asocia con el block producer para retener los datos de transacción? Los DAC suelen ser pequeños, lo que aumenta el riesgo de que sean sobornados y la posibilidad de que un actor externo comprometa al grupo.

Algunos validiums reemplazan los DAC con un sistema validador basado en proof of stake (PoS). Aquí, cualquiera puede convertirse en validador y almacenar datos off-chain. Sin embargo, deben proporcionar un "garantía o bond", que se deposita en un smart contract. En caso de comportamiento malintencionado, como la retención de datos por parte del validador, está garantía será tomada como castigo.

Los Data Availability Committees basados en Proof of Stake son considerablemente más seguros que los DAC regulares. No solo son permisivos y trustless, sino que también tienen incentivos bien diseñados para fomentar un comportamiento honesto.

🌌¿Cómo funciona la Data Availability Layer con los rollups?

Los rollups otorgan escalabilidad a  Ethereum moviendo la computación y el almacenamiento del estado fuera del entorno de ejecución de Ethereum: la Máquina Virtual Ethereum (EVM). La EVM solo acepta resultados de la computación off-chain y los aplica a su estado sin tener que volver a ejecutar transacciones, mejorando así la velocidad de procesamiento y reduciendo costos.

Lo que hace que los rollups sean más seguros que otras soluciones de escalado de Ethereum, incluyendo las sidechains o Plasma, es su dependencia de Ethereum para la Data Availability. Además de publicar resultados de transacciones en Ethereum, los Optimistic rollups  y los ZK Rollups también publican datos de transacciones en la Layer 1 como CALLDATA.

Los datos de los blocks publicados desde un rollup a Ethereum están disponibles públicamente, lo que permite a cualquier persona ejecutar transacciones y validar la rollup chain. También promueve la censorship resistance (resistencia a la censura) porque los datos publicados pueden ser utilizados por los futuros productores de blocks para reconstruir el estado de la cadena y comenzar a producir nuevos blocks. Ningún operador de la Layer 2 puede congelar arbitrariamente la chain y censurar a los usuarios en el rollup debido a esta medida.

Con la Data Availability Layer proporcionando seguridad, los rollups pueden optimizar la escalabilidad. Por ejemplo, un rollup puede elegir blocks grandes y tiempos de block más rápidos para acelerar la velocidad de procesamiento. Si bien esto aumenta los requisitos de hardware para los nodos (la mayoría de los rollups tienen algunos "supernodes" que ejecutan transacciones), la Data Availability de estado permite que cualquiera desafíe transiciones de estado inválidas o produzca blocks para evitar la censura.

🗂Ejemplos en el espacio de L2

Los protocolos que utilizan Optimistic Rollups (como Optimism o Arbitrum One) y ZK Rollups (como zkSync Era o Starknet) usan la “Data Availability On-Chain”, ya que todos los datos necesarios para la construcción de Validity proofs y Fraud proofs son publicados en la cadena matriz de Ethereum (L1).

Por otro lado los Validiums como Immutable X, Sorare y rhino.fi , junto a la Optimistic Chain, Arbitrum Nova, usan el esquema de Data Availability Committee, ya que la construcción de validity proofs se basa totalmente en datos que no están publicados on-chain (es decir, Off-chain). Existe un Data Availability Committee (DAC) encargado de proteger y suministrar los datos.

Otro caso es Apex, que almacena sus datos de manera externa, por lo que su Data Availability se encuentra fuera de Ethereum o la red matriz. Por consecuencia la creación de sus validity proofs se basa totalmente en datos que no se publican on-chain.

Por último está Metis, que con la ayuda de uno de sus socios, MemoLabs, es capaz de almacenar y garantizar su Data Availability para operaciones a través del servicio de Storage descentralizado que ofrece MemoLabs. En pocas palabras Metis, utiliza un sistema DAC pero en vez de almacenar su data en su propio Storage, utiliza el de uno de sus partners.

✅Conclusión

La Data Availability en la cripto industria es esencial para entender y mejorar la escalibilidad de las blockchains monolíticas y modulares. La transparencia y la accesibilidad de los datos son clave para tomar decisiones informadas y precisas de cómo mejorar el rendimiento de una blockchain y mantener su seguridad trustless para todos sus usuarios.

Sin embargo, una Data Availability "confiable" sigue siendo un desafío a superar debido a la naturaleza descentralizada y anónima de muchos protocolos o redes que la usan.

A medida que los protocolos y la tecnología blockchain en general vaya madurando, es esencial que los datos estén disponibles para que los developers y/o expertos puedan realizar acciones en pro de crear un mejoramiento continuo de la cripto esfera. Además, es importante que se establezcan estándares claros para la calidad y la veracidad de los datos para garantizar que los inversores tengan acceso a información confiable y precisa. Lo cual podrá contribuir a la adopción masiva de la blockchain que tanto se busca y que quizás ha costado conseguir…

📚Referencias

1️⃣Data Availability in Blockchains - Exploring the Data Availability Layer

2️⃣Data availability | ethereum.org

3️⃣What is the data availability layer?

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y únete a la conversación en nuestra comunidad de Telegram!

https://t.me/l2espaniol

https://twitter.com/Layer2es

En estos días existe una falta de coherencia entre la transparencia existente en las Layer 2 —cripto en general— y el deseo de privacidad que exige el ecosistema al final del día. Los datos públicos y verificables on-chain significan que las transacciones son rastreables y no pueden modificarse. Al mismo tiempo, al interactuar en el mundo real y en el mundo digital, inevitablemente dejamos alguna información, lo que también hace que otros puedan rastrearnos, desde movimientos on-chain hasta relacionar una address con nuestra identidad real.

La falta de protección efectiva de los datos es inaceptable en el mundo que vivmos, porque no solo los individuos quieren proteger su propia información o la de terceros, cualquier empresa u organización también quiere mantener la confidencialidad de sus datos sensibles y valiosos. Por lo tanto, resolver el problema de la privacidad es clave para que, en el caso específico de las Layer 2, logren dar un paso hacia la adopción masiva. Motivados por esto, muchos actores han identificado el problema y han dado forma a las primeras soluciones de privacidad como parte de las soluciones de escalabilidad de Ethereum.

A continuación, presentaremos las soluciones existentes en materia de privacidad dentro del ecosistema Layer 2 y relacionados.

✨Proyectos principales que ofrecen privacidad en L2.

🔷Aztec Network

Aztec es una Layer 2 de privacidad de Ethereum construida con un ZK Rollup que permite transacciones anónimas entre cuentas.

Aztec crea de una manera fácil zero-knowledge proofs, mediante PLONK, y luego usa el modelo Bitcoin UTXO para permitir transacciones de privacidad.

Dado que el modelo UTXO no permite que Aztec use smart contracts complejos, el equipo a desarrollado una solución llamada Aztec Connect, una forma de implementación de contratos en la mainnet de Ethereum que permite a los usuarios hacer uso de DeFi, algo que equivale al "mapping".

Nota: El término mapping en Solidity actúa como una tabla hash o diccionario en cualquier otro lenguaje. Estos se utilizan para almacenar los datos en forma de pares clave-valor. Los mappings se utilizan principalmente para asociar la dirección única de Ethereum con el tipo de valor asociado.

🧾PLONK, el sistema zero-knowledge proof de Aztec

El papel de PLONK es generar zero-knowledge proofs, lo que podríamos referir por ejemplo a "sacar una licencia de conducir". En otras palabras, PLONK es un tipo de tecnología zero-knowledge.

Con PLONK, cuando los comerciantes transfieren dinero de un lado a otro, los nodos y otras personas solo pueden obtener una "una licencia de conducir" y saber que la información en la "licencia" es definitivamente cierta, pero no sabrán exactamente que información tienen la licencia.

🤔¿Por qué necesitamos PLONK?

Aunque la tecnología de las zero-knowledge proofs es relativamente madura, Ethereum no se consideró compatible con la zero-knowledge proof cuando se creó.

Como resultado, lleva mucho tiempo generar una zero-knowledge proof directamente en Ethereum, por lo que los desarrolladores tienen que elegir otras opciones, y PLONK es una de esas "opciones".

PLONK en realidad proporciona un "Template" unificado para crear zero-knowledge proof para que los nodos de Aztec mejoren la eficiencia de la red.

Además, Aztec ha modularizado PLONK. Si un nodo no quiere usar PLONK y quiere usar otras formas de zero-knowledge proofs, como FRI, también es posible.

💰UTXO: una forma de comerciar amigable a zero-knowledge proofs

Después de usar PLONK para generar zero-knowledge proofs, ¿cómo se pasan las "proofs" entre nodos y cuentas? Pues usando UTXO.

UTXO es un método de transferencia de bitcoin que se diferencia de los sistemas de cuentas como Ethereum ya que en un sistema de cuentas como Ethereum los usuarios tienen wallets. Es como, si vas a pagar, sacas el dinero de tu bolsillo y lo das.

En el caso de UTXO, no todos los usuarios tienen wallets. En su lugar, se registra el dinero y el historial de transferencias de este dinero. Y el último destinatario del dinero, es el dueño del mismo.

Entonces, en el sistema de wallets de Ethereum es "nosotros poseemos el dinero" y en el caso de UTXO es "mi nombre está en el dinero".

Ahora bien, lo que hace Aztec es tomar el nombre del comerciante y borrarlo del dinero.

Para evitar que los comerciantes se confabulen entre sí, se genera una zero-knowledge proof antes de la transacción, lo que demuestra su transacción original, y la nueva proof se publica bajo el nuevo dinero.

Los resultados de la transferencia se registran en dos libros separados (Merkle Trees), uno para el Note Tree y el otro para el Nullifier Tree.

Si esta "proof" existe en el Note Tree, pero no en el Nullifier Tree. Esto significa que el saldo es válido.

💳Aztec Connect: UTXO aplicado a DeFi

Lamentablemente UTXO no funciona para implementaciones complejas de smart contracts, y Aztec Connect está diseñado para resolver este problema.

Aztec implementó el smart contract “Aztec Bridge Contract” en la mainnet de Ethereum. Cuando un usuario usa el protocolo DeFi en Aztec, el contrato agrega fondos e interactúa con el protocolo DeFi en mainnet, y luego devuelve los fondos al usuario una vez que se completa la transacción.

Las dApps que quieran implementarse en Aztec, debe conectarse al Connect SDK. Algunos de los proyecto que lo hicieron usando zk.money son:

• Yearn Finance : Para yield farming usando las vaults de Yearn Finance.

• Euler: para hacer lending usando ETH y generar ganancias por hacer yield con weWETH

• AAVE: para hacer lending usando ETH ó DAI y generar ganancias por hacer yield con wa2WETH ó wa2DAI respectivamente.

• Compound: para hacer lending usando DAI y generar ganancias por hacer yield con wcDAI.

• Liquity: Servicio de borrowing con LUSD utilizando ETH como colateral.

• Lido: Para hacer swap de ETH por stETH y realizar staking con stETH en Curve para obtener recompensas diarias.

Recientemente el equipo de Aztec anuncio su desvinculación Aztec Connect, los depositos de front-ends como zk.money y zk.finance serán deshabilitados, y se dará la oportunidad a los usuarios de retirar los fondos hasta el 21 de marzo del 2024. El objetivo de esto sera reducir el trabajo de secuenciador progresivamente, renunciar a los permisos del contrato y cesar el funcionamiento del rollup.

El codigo de Aztec ha sido abierto al público con las actualizaciones de scaling debidas y un nuevo SDK seguro. Con esto, el equipo de Aztec invita a los developers a crear, mejorar y implementar sus propios forks de Aztec Connect, a fin de lograr obtener una nueva versión de Aztec Connect 100% dirigida por la comunidad, en donde se comprometen a financiar las soluciones más prometedoras.

🌚Obscuro

Obscuro es una solución de Ethereum L2 de uso general que prioriza la privacidad que se encuentra entre los Optimistic y ZK Rollups para beneficiarse de lo mejor de ambos mundos.

Obscuro afirma que es capaz de tener el performance y uso general de los Optimistic Rollups combinado con la velocidad de retiro de los ZK Rollups.

A diferencia de las soluciones basadas en zero-knowledge proofs, la privacidad de Obscuro se basa en el uso de TEE, que es un enclave seguro que se encuentra en los procesadores de Intel (SGX), donde puede ejecutar cálculos totalmente confidenciales. Básicamente, cuando un nodo recibe una data encriptada, el procesador la desencripta, la valida y la vuelve a encriptar, sin que los validadores, los nodos completos y hasta el mismo operador del nodo puedan ver la información

El uso de los TEE no es exclusivo de Obscuro también lo usan Secret Network en Cosmos y Phala en Polkadot. Actualmente se encuentra en desarrollo.

🔥Otras soluciones de privacidad en L2.

🙊Zkopru

Zkopru es una Layer 2 basado en UTXO para transacciones privadas que utiliza zk-SNARK y un Optimistic Rollup. Es capaz de admitir transferencias privadas y atomic swaps privados dentro de su L2, es compatible con ETH, ERC20, ERC721 con un bajo costo. Además, con la función de pay-in-advance, los usuarios pueden retirar activos de la L2 antes de la finalización. Zkopru significa zk (de zero-knowledge proof) opru (de Optimistic Rollup).

Es importante destacar que los ZK rollups, utilizan zero-knowledge proofs para verificar el cálculo correcto del siguiente estado cuando se aplican nuevas transacciones, pero Zkopru no es un ZK Rollup. Mientras que los ZK Rollups usan la parte "zk" para crear una validity proof para la transición del estado del rollup, Zkopru usa la parte “zk” para hacer que las transferencias individuales sean privadas.

Este concepto tiene importantes ventajas en términos de consumo de gas. Para las transacciones zk directamente en mainnet, sería necesario utilizar una función hash compatible con SNARK para construir un Merkle tree, lo que es muy costoso. Pero usando un Optimistic Rollup, se puede actualizar el Merkle tree compatible con SNARK a un bajo costo off-chain. Como resultado, este protocolo consume alrededor de 8800 gas por transferencia privada (una transferencia ETH normal en Ethereum cuesta 21000 gas)

El procesos de zkopru son sencillos, para depositar solo es necesario usar la interfaz principal para enviar los fondos desde la L1. Luego para transferencias, cada usuario necesita generar su propia dirección Zkopru a partir de la llave privada que su ethereum wallet (la cual será utilizada para enviar o recibir fondos al igual que en la L1). Para garantizar la seguridad de la plataforma, cada vez que se completa una transferencia se genera una zero-knowledge proof que es enviada al Zkopru coordinator. Después de que el Zkopru coordinator haya sido incluido en la transacción (mediante fees), los fondos se consideran privados.

Para el caso del retiro de fondos de la chain, al igual que el cualquier Optimistic Rollup, se deben esperar 7 días. En donde los detalles de la transacción deberán revelarse para ello, por lo que la dirección y el monto retirado ya no son privados.

❗‼🧨Actualmente Zkopru ha dejado de tener actividad en cuanto a desarrollo, la prueba de ello es que su último post en twitter es de 19 de enero del 2022, es decir más de un año sin novedades.

🌪Tornado Cash

Tornado Cash es un mixer open-source que otorga privacidad a sus usuarios permitiendo ocultar el origen o destino de sus criptomonedas y tokens en la red Ethereum. Sin embargo, a pesar de ser originalmente creado para Ethereum, también se a extendido a las Layer 2 Arbitrum y Optimism (aunque no con tanta repercusión como en la L1).

El código fue diseñado para unir los activos de los usuarios dentro de una misma pool, usando zero-knowledge proofs, por lo tanto es difícil para un observador externo rastrear la procedencia de los fondos.

El rendimiento y las capacidades de Tornado Cash son indudables, y por tal motivo ha sido la herramienta favorita de los hackers para "borrar evidencia” de sus ataques. Debido a esto, el protocolo ha estado bajo la lupa de los reguladores, a través de sanciones de la OFAC e incluso el arresto de su uno de sus co-fundadores (sin importar que desde 2020 el team había renunciado a la propiedad del multisign, dejado a la DAO como único gestor de los fondos).

A pesar de todas estas polémicas, Tornado Cash sigue siendo una de las opciones para obtener privacidad en L2, y al ser open-source, da la posibilidad a los developers de crear variaciones del protocolo con sus propias reglas, tal como Privacy Pools.

🔮Soluciones futuras

🤫Privacy Pools

Privacy Pools es un protocolo que es capaz de proporcionar privacidad a las transacciones de Ethereum, originalmente fue pensado para operar en la L1, sin embargo recientemente, el co-fundador de Privacy Pools, @ameensol, anunció la integración con Optimism, por lo tanto los usuarios de la L2 de Optimism podrán disfrutar de las funcionalidades de Privacy Pools.

Privacy Pools puede ser considerado un fork de Tornado Cash, en esencia es igual, es un mixer de criptomonedas con la diferencia que utiliza zero knowledge proofs a través de la cual los usuarios pueden probar que sus retiros no son parte de las transacciones ilícitas. @ameensol publicó un tutorial de como utilizar la solución.

Es importante mencionar que actualmente de acuerdo a su documentación, el código de Privacy Pools aún se encuentra en fase alpha, aún no ha sido auditado, todavía no ha tenido su trusted setup y se han encontrado bugs en lo que se está trabajando.

Esta solución aún tiene mucho camino por recorrer y mejorar, solo el tiempo dirá si trasciende o se la lleva un “tornado”.

⭐Starknet L3s

Como se sabe, Starknet utiliza una L2 pública para mostrar y validar sus transacciones que luego son verificadas en la L1. Sin embargo debido a la reciente demanda de escalabilidad, interoperabilidad y privacidad, Starknet tiene planeado la creación de varias subredes (L3), con el fin de mejorar el rendimiento, reducir los fees exponencialmente e implementar privacidad. De acuerdo a lo expuesto en este tuit, con la creación de un fractal destinado a la privacidad, Starknet será capaz de probar un statement y entregar una proof hacia una Layer debajo de ella, sin revelar ningún detalle.

De esta forma la L3 puede incluir áreas privadas para computar datos que nunca llegarán a L2 pública. ¡Lo que se dice en L3 se queda en L3!

Esta tecnología sigue en desarrollo pero será la base para que futuras soluciones de privacidad en Starknet salgan a la luz.

🌊Sin7Y - Ola

Fue fundada en 2021 e impulsada por blockchain developers de primer nivel, Sin7Y es una incubadora de proyectos y un equipo de investigación de tecnología de blockchain que explora las tecnologías más importantes y de vanguardia, incluidas EVM, Layer2, Crosschain, Privacy Computing, etc. Actualmente están construyendo Ola, una plataforma integral que refuerza el ecosistema Ethereum con privacidad programable, escalabilidad programable y facil de usar por developers.

El equipo de Ola se planteó el reto de crear una programmable privacy. Para conseguir esto el equipo de Ola debe abordar 2 elementos clave: La parte "Programable" lo cual se refiere a usar una ZKVM (zero-knowledge virtual machine) para generar proofs válidas para cualquier uso. Y la parte de "privacidad" esto significa que se necesita un sistema de encriptación complejo y un nuevo tipo de dato para lograrlo.

Actualmente el equipo de desarrollo de Ola se encuentra explorando opciones de que tipo de encriptación va a utilizar, por lo que habrá que esperar a futuros avances para saber cómo pretenden ofrecer privacidad, una buena pista de ello es el lanzamiento de su testnet destinada para el Q4 del 2023 según el roadmap que se muestra en su website.

🌀Intmax

Es un zk Rollup stateless que poseen una serie de características únicas que permiten a los usuarios obtener “customizable privacy” (Privacidad personalizada en español).

La principal característica de Inxmax reside no usa datos históricos de transacciones. Esta eliminación de casi todos los datos on-chain de zkRollup, proporciona una gran ventaja. Por ejemplo, los datos resultantes de las transacciones se comprimen en gran medida, lo que reduce el costo del gas. Además, los datos de los usuarios se separan de los datos compartidos comúnmente, lo que permite la privacidad por defecto.

Otra característica importante es que no utiliza zkp verification, ya que Intmax usa un mecanismo llamado “Pre-consensus” en donde es posible enviar datos de zkp sin ejecutar verificaciones zkp on-chain, creando al mismo tiempo un compromiso optimista sin posibilidad de actividades maliciosas. Esto permite acortar de manera segura el período de espera de 7 días que requieren los Optimistic rollups a solo unas pocas horas.

Actualmente es posible usar la testnet de Intmax y se espera que su mainnet sea lanzada en el Q2 de 2023.

🐱‍👤Ethereum Stealth Addresses

En Ethereum, las transacciones son públicas de forma predeterminada, lo que puede plantear un problema de privacidad. Hay formas de lograr la privacidad transaccional en la red, como usar mixers de criptomonedas. Sin embargo, tales métodos pueden plantear problemas regulatorios. Esto se vió con Tornado Cash, que fue sancionado por la Oficina de Control de Activos Extranjeros (OFAC) del Departamento del Tesoro de EE. UU. por actividades potencialmente ilícitas.

De acuerdo a las palabras de Vitalik:

“La privacidad es uno de los mayores desafíos que quedan en el ecosistema Ethereum".

Por ello, el 20 de enero del 2023 Vitalik Buterin, publicó una propuesta en donde se presenta la idea de agregar privacidad a Ethereum mediante la implementación de las Stealth Addresses (en español dirección oculta o secreta).

El sistema de las Stealth Addresses se basa en un mecanismo que permitiría que cualquier wallet de Ethereum genere direcciones públicas ofuscadas criptográficamente llamadas "Stealth Addresses" para recibir fondos de manera privada y acceder a ellos usando un código especial llamado "spending key" (clave de gasto en español).

Buterin describió que las Stealth Addresses brindan las mismas propiedades de privacidad de alguien que genera una dirección nueva para cada transacción. Estas Stealth Addresses propuestas son una forma de aumentar la privacidad en Ethereum al crear direcciones únicas y anónimas para cada transacción.

Cada vez que alguien realiza una transacción, puede generar una nueva Stealth Address para que sea difícil rastrear las transacciones o determinar quién envía y recibe activos.

Esto significa que el historial de transacciones de cada usuario puede permanecer privado. De igual forma, Buterin también sugirió usar zk-SNARK (zero-knowledge proofs), para aumentar la privacidad del sistema y dificultar la vinculación de las Stealth Addresses.

Básicamente esta propuesta es para ser operada en la L1 de Ethereum, pero una vez que sea lanzada, es muy probable que sea aprovechada para agregar privacidad indirectamente a las L2.

Conclusión

Es natural que cuando vemos que las transacciones y saldos de nuestra billetera son publicadas en la blockchain nos sintamos observados e intimidados. Muchos usuarios y proyectos han sufrido ataques luego de meses de persecución por parte de exploiters. Por lo que la búsqueda de la privacidad siempre tendrá demanda.

Si realmente se quiere que la tecnología blockchain iguale o supere a las finanzas del mundo real, es importante que se la privacidad sea un objetivo o al menos una opción a implementar. Algunos proyectos, como los que se mencionaron en este artículo, emplean o emplearán buenas ideas de privacidad para reducir esta brecha entre DeFi y TradFi, en donde solo el tiempo dirá si lo logran o no.

En esta industria siempre existirán aquellos que se aprovecharan para lucrarse o dañar, lo cual da argumentos a reguladores de interceder en la misma. Pero aun así, la privacidad siempre sera necesaria.

Si no tienes nada que ocultar, no tienes nada que temer…

Pero cuando no hay dónde esconderse, debes tener mucho miedo.

📌Por último, no olvides leer nuestro últimos trabajos de investigación hechos por @Nadai02010, Una serie de 3 artículos en donde se explica el cual es la arquitectura, el futuro y como desarrollar usando zkSync Era.

https://mirror.xyz/layer2es.eth/oGUMSs0Szc7RmVbiVlxYoaAphKvLJ0k3iS_Frx8OxKc

https://mirror.xyz/layer2es.eth/bEVsgKYQu0l4pNUfgX4sUunf8d8stqAK3-r7mUmGMKc

https://mirror.xyz/layer2es.eth/f-k_yYoN0lQCebtCjuRsMOkFm6FJORjB9ldOkOgL55w

Dale un vistazo! No arrepentirás!

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y únete a la conversación en nuestra comunidad de Telegram!

https://t.me/l2espaniol

https://twitter.com/Layer2es

Hola comunidad 👋

¡Bienvenidos a la tercera parte de nuestra serie sobre zkSync! En la primera parte, exploramos su arquitectura, en la segunda hablamos sobre su futuro y escalabilidad, y en esta última edición, cubriremos conceptos muy poderosos, como la abstracción de cuentas (AA) y cómo se puede utilizar en zkSync.

También presentamos la Dapp de mensajería en L2 en español, donde podrás interactuar y dejar tus mensajes “Sólo ETH para testnet”. Aunque explicaremos cómo se ha desarrollado en los documentos y cómo se “podría” configurar mediante AA y un Paymaster. El Paymaster permitiría al usuario pagar con otro token ERC20, y luego el Paymaster se encargaría de pagar la transacción en ETH.

Esperamos que esta serie de artículos haya sido de gran ayuda e interés para ustedes y haya abordado temas importantes. Ahora, nos centraremos en aprender sobre el gran concepto de la abstracción de cuentas (AA).

✍️🔒 Account abstraction

Las cuentas en zkSync Era pueden iniciar transacciones, como una EOA, pero también pueden tener lógica arbitraria implementada en ellas, como un contrato inteligente, esta característica se denomina "abstracción de cuenta"

Repasemos algunas definiciones muy claras para entender AA:

Definición 1: AA es cuando un contrato inteligente puede pagar sus propias transacciones (Martin Triay, Devcon 6). En otras palabras, los contratos abstractos (o contratos inteligentes de cuentas) pueden pagar las transacciones. Tenga en cuenta que no es lo mismo que cuentas de propiedad externa o billeteras inteligentes.

Definición 2: AA es abstracción de validación. En L1 solo hay una forma de validar transacciones (recuperar una dirección de una firma, mirar esa dirección en el estado, determinar si el nonce está bien para la transacción que se envió y si la cuenta tiene saldo suficiente para realizar la transacción) . Con AA, abstrae el proceso de validación: utiliza diferentes tipos de firmas, primitivas criptográficas, procesos de ejecución, etc

Nota: En computación, el término abstracción se usa para generalizar algo. En este caso, estamos generalizando los contratos inteligentes de la existencia de Externally Owned Contracts (EOA) y Contract Accounts (CA), a simplemente contratos inteligentes.

La implementación de billeteras de contratos inteligentes mejoran la experiencia del usuario de almacenamiento que da pie a propiedades interesantes tales como la recuperación de claves privadas (por ejemplo, a través de recuperación social, multigrado).

También cabe destacar entre sus características que:

• Tienen la capacidad de pagar tarifas de gas de forma nativa en tokens que no sean ETH.

• Tienen la capacidad de cambiar tanto sus claves públicas como privadas.

• La adición de modificaciones no criptográficas permite a los usuarios solicitar características adicionales en las transacciones, como tiempos de vencimiento y confirmaciones fuera de servicio.

• Diversidad en los sistemas de verificación de firmas de la ECDSA actual, incluidos los algoritmos de firma segura poscuántica (p. ej., Lamport, Winternitz).

🧑‍💻 Equipo de Pruebas Nadai L2-Español

En L2 en Español, hemos explorado diversas opciones de desarrollo en los tutoriales de zkSync. A pesar de los desafíos encontrados, el resultado final fue muy satisfactorio al evidenciar el gran potencial de esta zkEVM.

💰 Paymaster

Uno de los casos de uso más interesantes de zkSync son los Paymasters “pagadores”. Imagínese poder pagar tarifas para los usuarios de su protocolo. Los paymasters son cuentas que pueden compensar las transacciones de otras cuentas. Además, también pueden facilitar el pago de tarifas en tokens ERC-20. Aunque ETH es el token de tarifa formal en zkSync, los pagadores pueden brindar la capacidad de intercambiar tokens ERC-20 a ETH sobre la marcha.

Si los usuarios desean interactuar con un paymaster, deben proporcionar la dirección del paymaster distinta de cero en su transacción EIP-712 , "Un procedimiento para el hash y la firma de datos estructurados tipeados en lugar de solo cadenas de bytes.". Los datos de entrada al paymaster se proporcionan en el campo paymasterInput.

Para garantizar que los usuarios experimenten con paymasters en testnet y puedan seguir pagando tarifas en tokens ERC-20, el equipo de Matter Labs proporciona el paymaster de testnet. Este permite pagar tarifas en token ERC-20 a una tasa de cambio de 1:1 con ETH (es decir, una unidad de este token es igual a 1 wei de ETH).

En nuestra investigación sobre Paymaster, hemos utilizado la validación de Account Abstraction para crear una nueva wallet derivada de nuestra propia wallet, la cual manejará nuestros nuevos tokens. Esta wallet utilizará un token creado por L2 Español y será gestionada mediante un smart contract de Paymaster que hemos creado y definido, para manejar la tasa de cambio del token utilizado en el pago.

Con el uso de Paymaster, se logra una forma segura y eficiente de realizar transacciones en el token elegido sin comprometer la seguridad del usuario. Este servicio se encarga de efectuar el pago correspondiente en el token seleccionado, permitiéndonos controlar y administrar nuestro gasto sin tener que realizar ninguna operación adicional. De esta manera, se evita exponer información sensible y se asegura la correcta ejecución de las transacciones.

Para añadir nuevos tokens, como zL2Es, podemos configurar el Paymaster para que cree una nueva wallet que comience desde la transacción 0 y mintea nuestro nuevo token. De esta forma, el Paymaster puede controlar con qué token se paga y realizar el cambio necesario para pagar la tarifa en ETH. Como usuarios, solo necesitamos escoger el token y pagar la tarifa en el token escogido. Si es ETH, podemos realizar la transacción directamente, de lo contrario, solo tendremos que firmar la transacción y el Paymaster se encargará del resto.

El Paymaster puede ser limitado si se detecta que el usuario está intentando realizar una operación malintencionada o que no cumple con los requisitos previos necesarios para la transacción.

Por lo tanto, es importante verificar que el usuario ha cumplido con todos los requisitos previos antes de realizar cualquier lógica en el Paymaster. En el contexto del tutorial, esto significa verificar que el usuario ha proporcionado suficiente asignación de token antes de realizar la transferencia.

El método getOverrides devuelve un objeto vacío cuando los usuarios deciden pagar con ether, pero cuando los usuarios seleccionan la opción ERC20, debe devolver la dirección del paymaster y toda la información requerida por ella. Esto ha sido una parte muy importante para último tutorial.

En resumen, la validación de AA nos permite controlar el sistema de pago de una manera segura y eficiente sin tener que preocuparnos por la gestión de tokens y transacciones complejas, podríamos haber personalizado un límite de gasto diario o configurar una multisig gracias al soporte de abstracción de cuenta o en zkSync.

• Wallet de Prueba: 0x789D5ce54F8F96369ee01751C5CA8C9fDAB14650

• Token L2 Español: 0x6a8D8FF10580cEF67c419caf6B7179cfbB536C2d

• Cuenta creada con AA para gestionar Paymaster: 0x3bf5bF4071308A20b35c5B7d64e49cB51bF04EA4

• Smart Paymaster con L2 token personalizado: 0x5De6f84AC1C693426CCBE47FAc92C96b78Ef159e

👥💭 Dapp Mensajes

En esta guía, le presentamos nuestra Dapp "Mensajería L2 en Español" diseñada para mejorar su experiencia de interacción. Aunque ether es el único token con el que puede pagar tarifas, la función de extracción de cuenta le permite integrar pagadores, hemos incorporado una parte activa pero solo el propietario de Paymaster puede configurarlo, podrá ver cómo se cargan sus saldos en ERC-20 desde Paymaster y cómo puede dejar su Saludo con ETH testnet.

Además, hemos creado un contrato inteligente que almacena mensajes de saludos y una Dapp para recuperar y actualizar esos mensajes. Tenga en cuenta que aunque la opción de firma estará disponible y los saldos sean correctos de los ERC-20 configurados para el Paymaster, puede experimentar errores al intentar firmar con los ERC-20, así que sólo dejamos configurado ETH para la actualización de su mensaje.

Para comenzar, deberá seguir los mismos pasos que en la parte 1 para agregar la red y tener fondos. Una vez que haya hecho esto, podrá conectar su wallet de testnet a nuestra dapp.

Para pagar las tarifas, deberá seleccionar el token que desee utilizar, aunque si selecciona un token configurado que no sea "ETH", podrá ver su saldo e intentar pagar, pero el Paymaster dará un error. Por lo tanto, podrá testear su poder pero deberá elegir "ETH" para escribir su mensaje y pagar la transacción. Una vez hecho esto, podrá dejar su mensaje escrito en nuestra Dapp e interactuar de una forma más cómoda, incluso agregando emojis si lo desea.

Es importante tener en cuenta que el botón Refresh debe usarse para recalcular la tarifa, ya que esta puede depender de la longitud del mensaje que queremos almacenar como saludo.

Esperamos que a través de la Dapp "Mensajería L2 en Español", pueda tener una mejor perspectiva visual del poder de la configuración de Paymaster en testnet y cómo podría pagar con otros tokens ERC20 mediante la abstracción de cuenta, permitiendo realizar las transacciones utilizando solo una validación de firma.

🫂 Agradecimientos

¡Y así concluimos la serie de zkSync! En esta última parte, profundizamos en cómo desarrollar y aprovechar el poder de zkEVM. Recordemos que en la primera parte de la serie, analizamos la arquitectura de esta solución y en la segunda edición, exploramos el futuro de la escalabilidad con zkSync Era. Esperamos que esta serie les haya sido útil y les invitamos a estar atento/as a futuras actualizaciones.

Terminamos la tercera parte y final de la serie de zkSync, en esta parte analizamos como desarrollar y el poder que tenemos en su zkEVM. En la primera parte fue la arquitectura de esta solución y en la segunda edición, hablamos sobre el futuro de la escalabilidad con zkSync Era.

También pueden consultar nuestra Biblioteca de Layer 2 en Español para tener una información más detallada o ir directamente en este caso a zkSync Era.

https://twitter.com/Layer2es/status/1638575210772287490?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1638575210772287490%7Ctwgr%5Edd5dc06b99d744b494c911eb28b982bb73632698%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fmirror.xyz%2Flayer2es.eth%2FbEVsgKYQu0l4pNUfgX4sUunf8d8stqAK3-r7mUmGMKc

🎉 ¡Gracias por leer hasta el final! Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

Hola comunidad 👋

Desde L2 Español, hemos decidido profundizar en zkSync en una serie de tres partes. En la primera parte, analizamos su arquitectura, mientras que en esta segunda parte, abordaremos otros temas relevantes de zkSync, como la escalabilidad, la seguridad en los puentes y el almacenamiento de datos (DA), entre otros aspectos en zkSync. Aunque muchas de estas nuevas tecnologías se presentarán en zkSync 3.0, es importante discutir su potencial y su impacto en la cadena de bloques.

Esperamos que esta serie de artículos sea de gran ayuda para comprender mejor zkSync y cómo se puede utilizar para mejorar la experiencia de los usuarios y desarrolladores en la cadena de bloques.

🚀️ Hyperscaling

El trilema de blockchain es un concepto fundamental de esta tecnología que se refiere a los tres objetivos claves que cualquier sistema de este tipo debe satisfacer: seguridad, escalabilidad y descentralización. Según este principio, un sistema blockchain de base no puede lograr los tres objetivos de manera simultánea, ya que cualquier mejora en uno de estos aspectos conlleva un compromiso en los otros dos.

Los sistemas Blockchain buscan garantizar la equidad mediante el principio fundamental de "no confíes, verifica". No obstante, para preservar la descentralización, es necesario que los nodos verificadores requieran bajos recursos para su ejecución. La interconexión de estas dos ideas ha dado lugar a la definición ampliamente aceptada de escalabilidad:

• Escalabilidad = procesamiento de un mayor número de transacciones sin comprometer la seguridad ni la descentralización.

Existen diversas formas de mejorar la escalabilidad, como aumentar la eficiencia del verificador o introducir suposiciones de confianza probabilísticas (como se hace en los resúmenes optimistas). Si bien la mayoría de estos enfoques ofrecen un impulso de escalabilidad lineal, un método sobresale por encima del resto: las pruebas sucintas de conocimiento cero (ZKP). Estas pruebas incurren siempre en costos de verificación de aproximadamente O(1), independientemente del número de transacciones procesadas. Gracias a esto, el escalado basado en ZKP, es decir, validiums y (bajo ciertas condiciones) ZK Rollups, puede ser considerado hiperescalable:

• Hiperescalabilidad = procesamiento de un número infinito de transacciones sin comprometer la seguridad ni la descentralización.

Los ZKP ofrecen una solución eficaz para construir una cadena de bloques heterogénea altamente escalable, este enfoque se conoce como "escalado fractal". En este modelo, varias cadenas ZKP diferentes (también llamadas hipercadenas en zkSync) se ejecutan simultáneamente y sus bloques de prueba se agregan en un solo bloque final que se liquida en la capa principal L1. Cada hipercadena se parece a todo el sistema, lo que significa que puede haber un número infinito de hipercadenas adicionales encima (como L3, L4, etc.).

Aunque la escala fractal es necesaria para lograr una mayor escalabilidad, se requiere un componente adicional para alcanzar una hiperescala.

• Hiperpuentes = puentes nativos que permiten transferencias entre dos hipercadenas sin consumir recursos en una tercera.

El escalado fractal siempre puede tener puentes nativos que conectan cadenas a través de capas subyacentes, pero en este caso, la cadena base eventualmente se convertirá en una encrucijada para la mayoría de las transferencias, y se convertirá en el cuello de botella central de la escalabilidad, derrotando la idea misma de la hiperescalabilidad paralela. Como resultado, no será posible garantizar transferencias directas baratas entre usuarios en dos cadenas dadas.

Para lograr una sobrecarga de costo cero en las cadenas subyacentes, cada hipercadena debe implementar hiperpuentes nativos que realmente puedan grabar y acuñar tokens reales y no solo su representación virtual (a diferencia de los puentes convencionales), almacenando compromisos de reclamos de acuñación en el estado Hyperchain. Además, deben confiar en las implementaciones de hiperpuentes en todas las demás hipercadenas, porque si un solo hiperpuente se ve comprometido, la cadena maliciosa podría interferir con el suministro de tokens (por lo tanto, todas las hipercadenas deben implementar exactamente los mismos circuitos).

Se pueden transferir activos de una Hyperchain a otra mediante hiperpuentes con el mismo costo que una transferencia normal. Esto funciona de manera similar a los hipervínculos en las páginas web, que permiten acceder a otras páginas con un solo clic, sin necesidad de navegar a través de múltiples capas.

Además, los contratos inteligentes pueden aprovechar las hipercadenas para enviar activos y mensajes a cualquier hipercadena con garantía de entrega, siempre y cuando la hipercadena de destino esté activa.

📄️ Contratos del sistema

Para mantener los circuitos ZK tan simples como sea posible y permitir extensiones sencillas, una gran parte de la lógica de zkSync se trasladó a los llamados "contratos del sistema" . Un conjunto de contratos que tienen privilegios especiales y sirven a propósitos especiales, por ejemplo, el despliegue de los contratos, asegurándose de que el usuario paga sólo una vez por la publicación de los datos de llamada de los contratos, etc.

El código de los contratos del sistema no se hará público hasta que se haya sometido a pruebas exhaustivas.

🌀️🌉️ ZK Rollups y puentes actuales

Antes de seguir con zkSync y la HyperScaling deberemos profundar sobre los puentes y los mecanismos comunes, puede revisar Slush, una propuesta de escalado Fractal.

El sector de los puentes con algún grado de confianza está saturado de empresas como Hop, Celer, deBridge o Connext. Primero clasificaremos a grandes rasgos los mecanismos de estos proyectos y descubriremos que existe un trilemma.

La primera opción de puenteo consistiría en encaminar los fondos desde el rollup de origen hasta el L1 y luego hasta el rollup de destino. Esta opción no es fiable, pero si todo el mundo la utilizara sobrecargaría L1, por lo que siempre será cara. Sin embargo, los costes pueden aliviarse si reúnes fondos con otras personas, si vas al mismo destino. Esto es el enrutamiento compartido, así es como la red Hop hace de puente. Cuando se va desde L3 o a mayor profundidad, los distintos fondos pueden agruparse aún más en L2, sin embargo, esta agrupación sólo puede utilizarse para aplicaciones que tengan una gran base de usuarios tanto en el rollup emisor como en el receptor.

Otra posibilidad es pasar directamente de una capa a otra (por ejemplo, Connext). Aunque son sustancialmente más rápidos y baratos que pasar por L1, estos sistemas sólo intercambian los fondos de una cadena por los de otra, lo que significa que tiene que haber algún otro mecanismo que compense el movimiento neto de fondos entre las capas. Esto conlleva costes adicionales, pero lo más importante es que este método depende en realidad de otras soluciones (como el enrutamiento agrupado).

Hay otra forma de pasar directamente de una capa a otra, una autoridad que quema y acuña los tokens puenteados en cada capa (como Wormhole). Esta autoridad normalmente toma la forma de una cadena de bloques más pequeña, y existen riesgos de seguridad al tener que confiar en estas cadenas de bloques pequeñas. Los inconvenientes de estos sistemas son obvios.

Tenemos un trilema: los sistemas no satisfacen las tres propiedades requeridas:

• No requerir de confianza.

• No tocar L1.

• Tener transferencias reales, no solo intercambio.

La razón de esto es que si tenemos transferencias reales y no intercambios, entonces los fondos deben quemarse en una capa y acuñarse en otra. Esta acuñación solo puede ocurrir si la quema ya ha ocurrido. La confirmación de que se produjo la quema requiere confianza en alguna autoridad o un mensaje transmitido desde L1, ya que las dos capas solo están conectadas a través de L1 sin confianza. Esto hace que sea difícil satisfacer simultáneamente los tres requisitos de un sistema de puente de confianza, aquí entra en juego la propuesta de escalado fractal y zkSync con las Hyperchain.

🔗️ Hyperchain

Las hipercadenas son instancias similares a fractales de zkEVM que se ejecutan en paralelo y con el acuerdo común en la red principal de L1.

Cualquier persona puede desarrollar e implementar hipercadenas sin permiso. Sin embargo, para seguir siendo confiable y totalmente interoperable, cada Hyperchain debe funcionar exactamente con el mismo motor zkEVM que la instancia principal de zkSync L2. Todos los circuitos ZKP seguirán siendo 100 % idénticos, lo que permitirá que las hipercadenas hereden por completo su seguridad de L1, sin importar quién los implemente. Esto garantiza cero suposiciones de confianza/seguridad adicionales.

🔧 Las hipercadenas se implementarán siguiendo el enfoque modular

Proporcionarán un marco SDK de hipercadenas similar a los de Cosmos o Substrate, donde los desarrolladores pueden elegir individualmente diferentes componentes de sus cadenas de bloques o implementar los suyos propios (excepto el núcleo zkEVM).

La Basechain es la principal instancia de Hyperchain de zkSync Era (la instancia L2). Sirve como capa de cálculo predeterminada para contratos inteligentes genéricos y como capa de liquidación para todas las demás hipercadenas (L3 y superiores).

Basechain no es especial de ninguna manera en particular, excepto que asienta sus bloques directamente en L1.

🔌️ Interoperabilidad L1/L2

Si bien la mayor parte de la ejecución ocurrirá en L2, algunos casos de uso requieren interoperabilidad con la cadena L1. Los principales casos de uso son la construcción de puentes complejos, el mantenimiento de contratos inteligentes de gobernanza en una cadena que rigen los contratos en otras cadenas, etc.

Además, la resistencia a la censura L2 se deriva de la cadena subyacente, por lo que la capacidad de enviar mensajes desde Ethereum a zkSync es una parte importante del mecanismo de resistencia a la censura llamado cola de prioridad .

El envío de transacciones de Ethereum a zkSync se realiza a través del contrato inteligente de zkSync, permite al remitente solicitar transacciones directamente desde L1. Permitiendo así el paso sin permiso de cualquier dato de Ethereum a zkSync.

• Cola de prioridad: el objetivo de la cola de prioridad es proporcionar una forma resistente a la censura de interactuar con zkSync en caso de que el operador se vuelva malicioso o no esté disponible.

• Proceso de despliegue: el proceso de la lógica de cuenta es muy similar al de despliegue de un contrato inteligente. Para proteger los contratos inteligentes que no quieren ser tratados como una cuenta, se debe utilizar un método diferente del contrato del sistema de despliegue para hacerlo. En lugar de utilizar create/create2, se deben utilizar los métodos createAccount/create2Account del contrato del sistema deployer.

Para proteger el sistema de posibles ataques de denegación de servicio (DoS), es necesario establecer ciertas limitaciones en el proceso de verificación. Estas limitaciones incluyen que la lógica de la cuenta solo pueda acceder a las ranuras que pertenecen a esa cuenta, lo cual se extiende más allá de los espacios ubicados en la dirección del usuario. Además, la lógica de la cuenta no puede usar variables de contexto como "block.number". Otra restricción importante es que la cuenta debe incrementar su "nonce" en 1, lo cual se hace para preservar la resistencia a la colisión de hash de transacciones. Es importante mencionar que esta limitación podría eliminarse en el futuro para permitir casos de uso más genéricos, como por ejemplo, en protocolos de privacidad.

📊️ Data Availability

A continuación presentamos un ejemplo de cómo cada Hyperchain puede administrar su política de disponibilidad de datos (DA) mediante una interfaz de contrato inteligente. Los usuarios pueden elegir entre varias opciones o incluso aplicar lógicas más complejas. Por ejemplo, una combinación de zkPorter y Validium puede requerir tanto un quórum de firmas de los tutores como un número de firmas del comité de disponibilidad de datos. En la imagen que mostramos a continuación, se puede observar cómo se estructura la DA y cómo se integra en el ecosistema zkSync.

🌀️ ZK Rollup

Los valores de cada ranura de almacenamiento modificada al final del bloque deben publicarse como datos de llamada en L1. Tenga en cuenta que los cambios repetidos (o cambios de ida y vuelta que dan como resultado una diferencia neta) no se publican. Significa que si un bloque contiene 100 intercambios ETH/DAI en el mismo DEX, los costos de publicación de datos se amortizarán parcialmente en todos esos intercambios. Una Hyperchain que funciona en este modo hereda estrictamente las propiedades de seguridad total y resistencia a la censura de Ethereum. La implementación de zkRollup en modo de salida estará disponible desde el día 1. Para propagar los datos de llamadas a L1, se agregarán a la cadena base. Tenga en cuenta que si la prueba ZK de Hyperchain es potencialmente grande en tamaño y/o computacionalmente pesada para verificar, solo incurre en costos L2 y no en costos de publicación.

• ZK Rollup (solo entradas): esta política requerirá la publicación de entradas de transacciones completas en lugar de actualizaciones de almacenamiento finales. La reconstrucción del estado sin confianza y los costos de DA en este caso serán 100% idénticos a los paquetes acumulativos optimistas (pero con todos los beneficios de un ZK Rollup, por supuesto, incluida una mejor seguridad y salidas más rápidas). La implementación de esta opción se deriva fácilmente de la implementación del ZK Rollup normal. Se puede explorar mediante cadenas específicas de la aplicación donde las entradas de tx son cortas pero pueden generar muchos cambios en los datos (por ejemplo, realizar simulaciones financieras).

• ZK Rollup (autohospedado): en este modo, los usuarios alojan ellos mismos los datos de todas las cuentas que poseen. Para hacer cumplir esto, se requieren firmas de confirmación del usuario para realizar cualquier cambio, lo que significa que no puede enviar fondos directamente a otro usuario. En su lugar, quemará los fondos y creará una prueba de esta quema, que puede proporcionar a su destinatario a través de un canal fuera de la cadena. El destinatario luego los canjeará en su cuenta. Esto puede parecer complicado, pero es fácil construir una interfaz de usuario agradable que abstraiga la UX, haciéndola prácticamente indistinguible del envío y la recepción de fondos en Ethereum (canjeará automáticamente todos los activos recibidos en el momento en que el usuario intente gastar los fondos, sin necesidad de clics adicionales). Pero aquí viene un milagro: un ZK Rollup autohospedado puede estar satisfecho con tan solo 5 bytes por interacción de usuario, que incluye un lote de muchas transacciones arbitrarias. Esto hace que el Ethereum fragmentado sea infinitamente escalable para cualquier propósito práctico en el modo zkRollup (es decir, 100 % seguro y resistente a la censura). Esta es una forma de incorporar a cada persona en la Tierra a Ethereum sin comprometer la seguridad. Una gran ventaja de este enfoque es que es totalmente compatible con nuestra implementación zkEVM, pero aún así puede ofrecer privacidad a los usuarios. La implementación no es trivial, por lo que esperamos que sea la última entre todas las demás opciones.

🛡️ zkPorter

Ya tienen una red de prueba de zkPorter guardian en funcionamiento. Esperan que zkPorter sea popular entre los usuarios dispuestos a asumir mayores riesgos de seguridad a cambio de transacciones realmente económicas, hasta que se implemente Danksharding. Los desarrolladores de Hyperchain podrán aprovechar el DA desde la implementación principal de zkPorter de zkSync o iniciar su propia red de guardianes (lo que podría ser interesante para las grandes comunidades en línea existentes, como Reddit o Twitter).

🕵️‍♂️ Validium

Hay casos de uso en los que el uso de validium está totalmente justificado, por ejemplo, cadenas empresariales que requieren auditabilidad y privacidad (dado que la disponibilidad de datos en tales casos está controlada por una parte central, es trivial mantener la privacidad de una Hipercadena de este tipo simplemente reteniendo datos). Dado que validium es esencialmente un caso más simple de zkPorter, los desarrolladores pueden implementar fácilmente Hyperchains en función de esta política.

🌳 Particiones lógicas de estado

Cada Hyperchain tiene la capacidad de crear una o varias particiones lógicas que, aunque forman parte del mismo estado, se ubican en diferentes subárboles y aplican políticas de disponibilidad de datos distintas. Desde la perspectiva del usuario, estas particiones se perciben como instancias separadas de Hyperchain, con su propio ID de cadena, conexión de billetera, explorador de bloques, etc. No obstante, estas particiones pueden interoperar de forma sincrónica, lo que permite realizar transacciones atómicas entre ellas y desbloquea múltiples casos de uso como:

• Leer el estado de otra partición de forma transparente.

• Utilizar préstamos flash entre particiones.

Un ejemplo destacado de esta interoperabilidad se logra mediante una combinación de zkRollup + zkPorter, que será parte de la Basechain de zkSync.

🔒 Privacidad

Existen varias maneras en que las hipercadenas pueden mejorar la privacidad y la confidencialidad de los datos.

• Validium: para una Hyperchain que se ejecuta en el modo validium, la privacidad del mundo exterior se logra de forma inmediata siempre que el operador mantenga en secreto los datos del bloque. Esta podría ser una opción interesante para usuarios empresariales.

• Protocolos de privacidad: para implementar la privacidad a nivel de usuario, se requiere un protocolo L3 especializado. Los proyectos como Aztec o Tornado se pueden implementar directamente en la cadena base (aprovechando la abstracción de cuentas y la verificación recursiva ZKP económica en zkSync), o pueden optar por Hyperchains independientes de propósito especial para una mayor flexibilidad.

🫂 Agradecimientos

Hemos llegado al final de la segunda parte de nuestra serie sobre zkSync, donde exploramos el futuro de la escalabilidad de esta solución. En la tercera y última edición, nos enfocaremos en el desarrollo con zkSync Era y nos gustaría invitarte a participar en una Dapp muy especial que hemos preparado para todos. Esperamos que “nos escribas tus mensajes”... Mantente atento para más información en breve.

También pueden consultar nuestra Biblioteca de Layer 2 en Español para tener una información más detallada o ir directamente en este caso a zkSync Era.

https://twitter.com/Layer2es/status/1638575210772287490

🎉 ¡Gracias por leer hasta el final! Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

Hola comunidad 👋

Desde L2 Español, nos hemos propuesto analizar en profundidad la arquitectura de zkSync, así como explorar sus principios y su utilidad tanto para usuarios como para desarrolladores. En esta serie de tres partes, examinaremos distintos aspectos de esta tecnología, comenzando por la definición de zkSync y su funcionamiento en el sistema de transacciones.

En esta misma parte, también trataremos otros temas relevantes de zkSync que permitirán a los lectores tener una visión más completa de esta solución, sus características y beneficios en relación a la escalabilidad de blockchain. Esperamos que esta serie de artículos sea de gran ayuda para comprender mejor zkSync y cómo se puede utilizar para mejorar la experiencia de los usuarios y desarrolladores en la cadena de bloques.

Además, hemos creado una parte interactiva con un tutorial de “Crosschain Governance” para que todos puedan incrementar un contador desde L2, así los usuarios podrán tener una experiencia práctica y ver en acción cómo funciona zkSync.

Estamos emocionados de presentar esta serie y esperamos que sea de gran interés y utilidad para todos.

💻 Introducción a zkSync

zkSync es un protocolo de capa 2 de Ethereum, que fue lanzado en 2020 con el objetivo de proporcionar transacciones escalables y de bajo costo en la cadena de bloques de Ethereum. Fue desarrollado por Matter Labs, una empresa de investigación y desarrollo en tecnología blockchain, y se basa en la tecnología de "rollups" para lograr este objetivo.

En el caso de zkSync, los rollups se combinan con la tecnología de pruebas de conocimiento cero (ZK).

zkSync es operado centralmente por el equipo de Matter Labs, pero se espera que se traslade a un modelo descentralizado en el futuro cercano. Con su enfoque en la escalabilidad, la privacidad y la accesibilidad, zkSync es una tecnología emocionante que podría desempeñar un papel importante en el futuro de Ethereum y la tecnología blockchain en general. A continuación, presentamos los datos de la actividad que ha tenido zkSync en un período de aproximadamente 3 meses.

🚀 Fair Onboarding Alpha

Como ya adelantamos en nuestra Newsletter #3, Fair Onboarding Alpha marca un hito emocionante en la adopción de la criptografía para la soberanía personal. El primer zkEVM en Mainnet de Ethereum, finalmente abrió sus puertas para permitir que los proyectos registrados se implementen en la red principal. Este evento representa una gran oportunidad para miles de desarrolladores y millones de personas que quieren utilizar la criptografía para escalar Ethereum y preservar sus valiosas propiedades.

Para llegar a este punto, zkSync ha contado con el apoyo inquebrantable de su comunidad, la empresa se enorgullece de haber contado con su apoyo en cada paso del camino, como resultado, zkSync ha prometido ser completamente de código abierto, y ha cumplido su promesa al hacer que “zkSync 2.0 sea zkSync Era” y “zkSync 1.0 sea zkSync Lite”. La nueva marca, Era, representa una nueva fase en la adopción de la criptografía y habla de la visión de zkSync para una nueva era de Ethereum.

El nombre “ERA” ha sido elegido bajo el siguiente razonamiento:

• Es simple y universalmente entendido

• Tiene un amplio atractivo y amplia aplicabilidad

• Habla de la visión de zkSync para una nueva era de Ethereum.

Como parte de este nuevo hito, zkSync también lanzó una distinción clara entre las dos versiones de su solución de escalabilidad de Ethereum. zkSync 1.0, ahora zkSync Lite, es una versión reducida del protocolo, que ha sido simplificada y optimizada para dApps más simples. zkSync Era, por otro lado, es una versión más completa que cuenta con un zkEVM completamente funcional y una amplia gama de herramientas y funcionalidades para los desarrolladores.

Durante el período de Fair Onboarding Alpha, zkSync permitirá que solo los proyectos registrados puedan implementar y probar sus dApps en la red principal de zkSync. Para ello, es necesario que los proyectos se registren aquí.

Es importante tener en cuenta que, durante Fair Onboarding Alpha, Mainnet permanecerá cerrado para los usuarios finales. Esto se debe a que los equipos pueden implementar y probar sus aplicaciones en un entorno cerrado antes de que el sistema se abra a usuarios externos. A pesar de que la seguridad sigue siendo una prioridad máxima para zkSync, no se recomienda bifurcar el código todavía hasta el Full Launch Alpha.

🌅 Nueva Era y su zkEVM

La zkEVM es una arquitectura que permite la generación de pruebas de conocimiento cero (ZKP), para la ejecución de contratos inteligentes escritos originalmente para EVM.

La arquitectura de zkSync Era y su zkEVM se basa en los siguientes componentes:

• zkVM: una máquina virtual similar a RISC, completa en Turing y optimizada para pruebas en un circuito ZKP. Tiene varias implementaciones: Executor (ejecución nativa rápida en CPU), generador de testigo (executor nativo para generar un testigo ZKP), y probador (implementación real del circuito ZKP).

• Copilador basado en LLVM con frontend de Solidity: (más precisamente, frontend de Yul) y Vyper, y backend zkVM.

• Circuitos de propósito especial: (que dependen en gran medida de las compuertas y tablas de búsqueda personalizadas de PLONK) como "precompilaciones" para operaciones computacionalmente intensivas, como hashes no algebraicos (Keccak, SHA256, Blake2), acceso al almacenamiento (caminos de Merkle), emparejamiento de curvas elípticas y circuitos de agregación recursiva (combina las pruebas de las partes mencionadas anteriormente).

Podemos resumir la zkEVM como una arquitectura que permite generar pruebas de conocimiento cero para contratos inteligentes, con componentes clave como zkVM, un compilador basado en LLVM y circuitos de propósito especial. zkVM hereda estrictamente el modelo de programación EVM y sus invariantes, incluidas las convenciones de llamadas ABI, y admite reversiones y transacciones reversibles para garantizar la protección mutua.

Los desarrolladores pueden confiar en la resistencia a la censura proporcionada por L1 sin cambios relacionados con el mecanismo de escotilla de escape, lo que significa que los activos en una cuenta zkRollup en zkSync tienen las mismas garantías de seguridad que en L1.

🆕🆙 Mejoras en la EVM

La zkEVM mejora la adopción y beneficia los proyectos de ecosistema al mantener la máxima compatibilidad con el EVM y agregar mejoras significativas.

Una de ellas es el compilador basado en LLVM, este aumenta la eficiencia del código y permite integrar bases de código de otros lenguajes de programación. Además, el zkEVM incluye la abstracción de cuenta (AA), una función esperada por la comunidad de desarrolladores de Ethereum, que mejora la experiencia del usuario al ofrecer soporte nativo para billeteras de contratos inteligentes, mejor UX para multisigs (dirección que está asociada con más de una clave privada), la posibilidad de pagar tarifas de transacción en cualquier token y permitir que los protocolos puedan subsidiar el gas para los usuarios de sus contratos inteligentes.

También permite confirmar lotes de transacciones con un solo clic, lo que mejora la UX en Ethereum.

🌐 Transacciones

Las transacciones en Ethereum son instrucciones firmadas criptográficamente por una cuenta externa (una cuenta propiedad de un usuario y no de un código). Estas instrucciones se almacenan en la blockchain y se añaden a un bloque. El estado de la máquina virtual de Ethereum (EVM) cambia cuando se inicia una transacción. Una transacción puede ser cualquier cosa, desde enviar ether a otra cuenta hasta invocar las funciones de un contrato inteligente.

¿Cómo funcionan las transacciones?

Cuando un usuario inicia una transacción en Ethereum, se crean algunos datos específicos:

• Receptor: el receptor es la dirección de la cuenta para recibir la transacción, este receptor puede ser una cuenta de contrato o una cuenta externa. Cada transacción va dirigida a un destinatario concreto.

• Nonce: este campo muestra la transacción más reciente basada en el contador de la cuenta, que mantiene un registro de cuántas transacciones realiza. La red utiliza el nonce de la transacción para garantizar que las transacciones se completan en la secuencia correcta.

• Precio del gas: la mayoría de las transacciones requieren el pago de una tasa al autor de la transacción, este coste se calcula por unidad de gas. La unidad es wei, una unidad de éter más pequeña.

• Límite de gas: el autor de la transacción especifica el número de unidades de gas utilizadas para la transacción y es la cantidad total de gas que se puede consumir.

• Valor: la cantidad de wei o Éter que la cuenta remitente desea transmitir al destinatario está representada por el valor.

• Datos: si el receptor de la transacción es un contrato inteligente, los datos contienen información para que se ejecuten las funciones del contrato. Se compone de datos de longitud variable.

• Firma: la firma indica quién ha enviado la comunicación, la firma se crea cuando una cuenta externa confirma y firma la transacción con su clave privada.

🔄 Tipos de transacciones

Las transferencias de activos tales como ETH, tokens o interacciones con contratos son funcionalidades básicas en Ethereum para entre cuentas. Este tipo de transferencias son comunes en las operaciones diarias de la red y son necesarias para llevar a cabo cualquier tipo de transacción en Ethereum. Por otro lado, las transacciones de despliegue de contratos son aquellas en las que se crea un nuevo contrato inteligente en la red de Ethereum.

El despliegue de contratos en zkSync es bastante diferente al de Ethereum:

• Ethereum: el despliegue de contratos se produce cuando un usuario envía una transacción a la dirección cero (0x000...000) con el campo de datos de la transacción igual al bytecode del contrato concatenado con los parámetros del constructor.

• zkSync: para desplegar un contrato en zkSync, un usuario llama a la función create del ContractDeployer y proporciona el hash del contrato a publicar, así como los argumentos del constructor. El propio bytecode del contrato se suministra en el campo factory_deps de las transacciones EIP-712. Si el contrato es una fábrica (es decir, puede desplegar otros contratos), los bytecodes de estos contratos deben incluirse también en factory_deps.

zkSync soporta los tipos de transacción "antiguos" (pre EIP-2718) de Ethereum, el tipo de transacción EIP-1559 y sus transacciones EIP-712. Las transacciones de este tipo se pueden utilizar para acceder a características específicas de zkSync como la abstracción de cuentas. Además, los contratos inteligentes sólo pueden desplegarse con este tipo de transacción.

¿Cuándo se considera que una transacción es final?

La finalidad de una transacción se refiere a la promesa de que las transacciones no pueden ser revertidas, alteradas o mutadas en el contexto de una red blockchain.

Bajo prueba de participación, las transacciones de Ethereum finalizan en 2,5 épocas (16 minutos) de media en condiciones normales: revertir esa transacción costaría 1/3 del suministro total de Ethereum.

Una vez que un bloque se ha llenado y sellado en ZK Rollups, su estado se registra en la cadena principal de Ethereum. A continuación, se inicia la etapa de comprobación y se construye una prueba de validez SNARK para cada transacción de bloque. Una vez completada, la SNARK se envía para su verificación en el contrato inteligente L1, y el estado de la transacción se convierte en definitivo tras la verificación.

Desde el punto de vista de zkSync, la finalidad se produce cuando la transacción (la verificación SNARK) es ejecutada por L1. En este punto, las garantías son las mismas que cualquier otra transacción L1 dentro del mismo bloque L1, cuantos más bloques L1 se emitan después de que se procese el bloque inicial, menos probable será que esta transacción se anule.

Cuando un usuario transmite una transacción, zkSync espera actualmente a que se llene todo el bloque, lo que significa que el tiempo de finalidad puede ser mayor dependiendo del volumen de transacciones enviadas a través de zkSync. El tiempo de finalización se reducirá a medida que aumente el rendimiento.

👩🏼‍💻 Los Operadores o Secuenciadores

Los operadores son los actores que llevan a cabo las funciones esenciales de zkRollup. Son responsables de producir bloques, empaquetar transacciones, realizar cálculos y enviar datos a la cadena principal de Ethereum para su verificación.

🟪 Bloques en la era zkSync

En zkSync existen dos nociones de bloques, los bloques a nivel de L2 y los bloques entendidos como lotes o “batches” para el rollup en L1.

• Bloques en L2: son simplemente los bloques creados en L2, es decir, en la red zkSync y no se incluyen en la cadena Ethereum. Un bloque L1 rollup, que le dan el nombre de "lote", es un conjunto de bloques (L2) consecutivos, contiene todas las transacciones, y en el mismo orden, desde el primer bloque del lote hasta el último bloque del lote.

• Lotes para L1: como su nombre indica se envían a Ethereum. La razón principal para tener estas nociones diferentes es que un bloque puede contener un número mínimo de transacciones, y así ser procesado rápidamente, mientras que en un lote pueden incluir muchas transacciones, para hacer que el coste de la interacción con L1 se reparta entre muchas transacciones.

⏳ Tiempo de procesamiento de los bloques

El operador procesa inmediatamente las transacciones y las añade a los bloques, que se generan inmediatamente. Una vez que zkSync esté totalmente descentralizado, el tiempo de bloque tardará un par de segundos, ya que las entidades implicadas necesitan alcanzar un consenso.

En general, un lote (rollup) se sellará cuando:

• Se alcanza la "capacidad" del lote.

• La capacidad incluye el gas L1 utilizado, el gas L2 consumido y otros parámetros.

• Ha transcurrido el tiempo de espera del lote.

Cada lote L1 (que comprende varios bloques L2) se ejecuta en una única instancia de VM. La VM ejecuta las transacciones una a una y luego ejecuta algún código que no tiene nada que ver con la última transacción, sino con todo el lote. Actualmente, el ETH recaudado de las comisiones se transfiere desde la dirección formal del bootloader a la dirección del minero de bloques. La cuestión es que esta transferencia emite un evento (como cualquier otra transferencia), de ahí que hayan incluido este evento en un bloque L2 para que sea accesible vía API.

Es posible añadir eventos en el último bloque L2 del lote L1, pero debemos considerar ciertos escenarios. Por ejemplo, si un bloque L2 ya se ha cerrado, pero su lote L1 aún no, y no se han recibido nuevas transacciones en un tiempo, entonces el lote L1 debe cerrarse para evitar tiempos de espera. Si añadimos el evento al último bloque cerrado, se modificará el bloque y se generará una reorganización en la cadena de bloques.

Para evitar esta situación, se construye un bloque puramente ficticio que sólo contiene el evento. De esta manera, se evita modificar el último bloque cerrado y se mantiene la integridad de la cadena de bloques.

#️⃣ Hashes

Los hashes de bloque en zkSync son deterministas, la razón de tener un hash de bloque determinista es que estos hashes no son demostrables (recuerde que los bloques L2 no se envían a L1). Se recomienda a los proyectos que no utilicen el hash de bloque L2 como fuente de aleatoriedad.

📜 Propiedades de los Bloques en L2

En este texto se presentan las principales propiedades de los bloques en L2 de zkSync, además, se destaca que zkSync no tiene consenso de prueba de trabajo.

• Marca de tiempo: la hora de creación del bloque actual en segundos que devuelve la marca de tiempo del lote L1.

• Número de bloque: el número secuencial único de este bloque.

• Límite de gas: el límite de gas del bloque actual, siempre devuelve 2^32-1.

• Coinbase: la dirección del minero del bloque actual, devuelve la dirección del bootloader.

• Dificultad: la dificultad del bloque actual, devuelve 2500000000000000 (zkSync no tiene consenso de prueba de trabajo).

🕵️‍♂️ La etapa de validación

Durante el paso de validación, la cuenta debe decidir si acepta la transacción y, en caso afirmativo, pagar las comisiones correspondientes. Si falla alguna parte de la validación, no se cobra comisión a la cuenta, y dicha transacción no puede incluirse en un bloque.

• Paso 1. El sistema comprueba que el nonce de la transacción no se haya utilizado antes.

• Paso 2. El sistema llama al método validateTransaction de la cuenta. Si no revierte, procede al siguiente paso.

• Paso 3. El sistema comprueba que el nonce de la transacción se ha marcado como utilizado.

• Paso 4 (sin pagador). El sistema llama al método payForTransaction de la cuenta. Si no revierte, pasa al siguiente paso.

• Paso 4 (pagador). El sistema llama al método prePaymaster del remitente. Si esta llamada no revierte, se llama al método validateAndPayForPaymasterTransaction del pagador. Si tampoco revierte, se procede al siguiente paso.

• Paso 5. El sistema verifica que el gestor de arranque ha recibido al menos tx.gasPrice * tx.gasLimit ETH al gestor de arranque. Si es así, la verificación se considera completa y podemos proceder al siguiente paso.

🔐 La etapa de ejecución

El paso de ejecución se considera responsable de la ejecución real de la transacción y del envío de los reembolsos de cualquier gas no utilizado al usuario. Si se produce alguna devolución en este paso, la transacción sigue considerándose válida y se incluirá en el bloque.

• Paso 6. El sistema llama al método executeTransaction de la cuenta.

• Paso 7. (sólo en caso de que la transacción tenga un pagador) Se llama al método postOp del pagador. Este paso debería utilizarse normalmente para reembolsar al remitente el gas no utilizado en caso de que el pagador se haya utilizado para facilitar el pago de comisiones en tokens ERC-20.

💸 Fees o Tasas de transacciones en zkSync

En zkSync, su objetivo es ser compatible con Ethereum, lo que significa que su objetivo es compartir similitudes y minimizar las grandes diferencias, una de esas similitudes es el modelo de tarifa de gas de zkSync.

La versión de zkSync de gas representa no solo los costos de los cálculos, sino también el costo de publicar datos en la cadena y afectar el almacenamiento.

Dado que los costos de publicar los datos de llamada en L1 son muy volátiles, la cantidad de gas necesaria para cambiar una ranura de almacenamiento no es constante. Para cada bloque, el operador define los siguientes parámetros dinámicos:

• gas_price: la tabla para el precio base actual en cada ficha. El valor de este parámetro se usa para determinar los costos de ejecución de VM en cada token.

• gas_per_pubdata: el precio gas por publicar un byte de datos en Ethereum.

Tenga en cuenta que los datos públicos se postean solo para diferencias de estado. Si la misma ranura de almacenamiento se actualiza 10 veces en el mismo bloque acumulativo, solo se publicará la actualización final en Ethereum, por lo que solo se cobrará una vez por los datos públicos.

📊 Comparación del modelo de tarifas entre zkSync y Ethereum

En zkSync, a diferencia de Ethereum, los códigos de operación tienen precios de gas similares debido a que el costo de los mismos es diferente. Por lo general, la propia ejecución de operaciones aritméticas es económica, aunque como en Ethereum, la mayor parte del costo se incurre en actualizaciones de almacenamiento.

A pesar de estas diferencias, el modelo de tarifas en zkSync es similar al de Ethereum, donde la operación más costosa sigue siendo el cambio de almacenamiento. Una ventaja de los ZR Rollup sobre los optimistic rollup, es que, en lugar de publicar todos los datos de transacciones, los ZR Rollup pueden publicar solo las diferencias de estado, lo que minimiza los cambios de almacenamiento.

🤖 Pruebas L2 Español

🗳️ Crosschain Governance

En este tutorial se mostrará cómo se puede utilizar la interoperabilidad entre L1 y L2 para crear un sistema de gobernanza controlado desde L1 y su wallet. Para lograr esto, se crearán dos contratos, uno en L1 y otro en L2.

El contrato en L2 será un simple contrato de "contador" que almacenará un número que puede ser incrementado llamando al método "increment". Este contrato será accesible para todos los usuarios de L2.

El contrato de gobernanza en L1 tendrá la función de incrementar el contador en L2 y será controlado únicamente por el administrador. Además, este contrato permitirá votar y ajustar otros contratos en L2.

El creador del contrato será establecido como el único gobernador y se incluirá una función que permitirá solicitar transacciones en L2 a través del contrato inteligente zkSync.

Para votar desde L2, los usuarios podrán llamar al método "increment" en el contrato de contador en L2, pero para realizar ajustes desde L1, el administrador tendrá que llamar al método correspondiente en el contrato de gobernanza en L1, que a su vez llamará al contrato correspondiente en L2.

En conclusión, la interoperabilidad entre L1 y L2 permite crear sistemas de gobernanza que pueden ser controlados desde L1, pero accesibles para todos los usuarios en L2. Esta funcionalidad puede ser utilizada para votar, realizar ajustes y controlar otros contratos en L2 desde L1, y todo ello de forma segura.

🧪 Añadir red Testnet zkSync ERA

Si desea interactuar con zkSync, puede agregar la red Testnet zkSync Era a su Metamask a través del enlace oficial proporcionado, o puede hacerlo directamente agregando una nueva red y utilizando la información de conexión específica de zkSync Era que se detalla a continuación.

Información de la red de la red de prueba

• Nombre de red: zkSync Era Testnet

• Nueva URL de RPC: https://zksync2-testnet.zksync.dev

• Identificación de la cadena: 280

• Símbolo de moneda: ETH

• URL del explorador de bloques: https://goerli.explorer.zksync.io/

• URL de WebSocket: wss://zksync2-testnet.zksync.dev/ws

Para comenzar a utilizar zkSync, primero debe obtener faucet ETH en la red principal (L1) y transferirlos a la red zkSync Era a través del Portal Bridge. Puede obtener estos tokens ETH desde varios enlaces disponibles en la red L1, o utilizar el Portal Faucet zkSync Era para recibir una combinación de varios tokens ERC20 de forma gratuita.

Además, puede revisar la sección de zkEVM en nuestro artículo para obtener más información sobre el funcionamiento de zkSync en la red Ethereum.

https://twitter.com/Layer2es/status/1618323379010023424

Incrementar Counter

Primero, desplegamos el contrato de Governance en L1, como se mencionó anteriormente, para que sea responsable de controlar las configuraciones e incluso aumentar el contador desde L1.

Una vez que tenga ETH, puede acceder al contrato que hemos implementado y verificado para que el usuario pueda revisarlo y actuar sobre él. Como puede observar, ya se ha definido el contrato de gobernanza en L1 que hemos creado.

Interactuar con Counter

Si deseas interactuar con el contrato de gobernanza en zkSync, haz clic aquí y se mostrará una imagen con el contrato “Counter” de L2 y su explorador, donde deberá conectar su billetera, agregar la red de pruebas zkSync ERA y tener fondos en ella. Luego podrá hacer clic en "write" en “increment” y deberá pagar la tarifa correspondiente a la transacción.

Puede observar como hemos aumentado el contador a 1, siéntase libre de probar y aumentar el contador de L2 utilizando una wallet de Testnet en zkSync. Hemos configurado el contrato de gobernanza para que los ajustes del contador en L2 estén abiertos a todos los usuarios.

Sin embargo, es importante destacar que el control del contrato de gobernanza en L1 está limitado al propietario.

Así de fácil se realiza el voto en Cross Chain utilizando zkSync Era, con un desarrollo sencillo y seguro.

• Wallet de prueba: 0x789D5ce54F8F96369ee01751C5CA8C9fDAB14650

• Governance L1: 0xe65abe89399b988c6e358fb788f116d2d1b17316

• Counter L2 modificado: 0x664991DAD4F2805024ad5090B88EBF509aF53C94

🫂 Agradecimientos

Terminamos la primera parte de la serie de zkSync, en esta parte analizamos la arquitectura de esta solución de escalabilidad blockchain. En la segunda edición, hablaremos sobre el futuro de la escalabilidad con zkSync Era y sus nuevas implementaciones, abordaremos temas muy importantes antes de llegar a la tercera parte, en la que estamos preparando una sección “Extra” interactiva, en la que esperamos que disfrutes participando en actividades relacionadas con zkSync y el ecosistema blockchain.

🎉 ¡Gracias por leer hasta el final! Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

Introducción

Los zkEVM se han convertido en un tema muy popular en los últimos 2 años. Podría decirse que se han convertido en la tecnología de oro estándar para escalar Ethereum, no solo a través de la layer 2, sino también directamente a través de la layer 1, "snark Ethereum itself for the end game". Hemos estado impulsando este ambicioso sueño junto con el equipo de Privacy and Scaling Exploration desde el principio, y nos hemos comprometido a seguir construyéndolo en conjunto en el futuro.

En este artículo, quiero compartir algunas de las lecciones que aprendimos mientras construíamos zkEVM, y cómo hemos estado pensando en diferentes trade-offs a lo largo del camino. Estamos adoptando un enfoque diferente al de otros proyectos en el ecosistema, y ​​esto nos coloca en una posición única.

Desarrollo basado en la comunidad

Scroll es fundamentalmente posible gracias al open-source. Estamos utilizando proving stack de Zcash y hemos estado construyendo zkEVM circuits junto con el equipo de PSE desde el primer día. Agradecemos el esfuerzo de la comunidad y todas las herramientas que se están construyendo. Con ese espíritu, una mentalidad importante que tenemos es devolver todo lo que podamos y continuar construyendo con la comunidad de una manera más abierta y colaborativa. Esto distingue nuestro ethos de otros proyectos. Más específicamente, hemos hecho lo siguiente para que el desarrollo de Scroll esté orientado a la comunidad:

• Educación pública para un público amplio. Para ayudar a las personas a comprender nuestra arquitectura, hemos dado múltiples charlas y organizado eventos a nivel mundial. Puede encontrarnos en Devconnect, SBC, Devcon, etc. Para los estudiantes que desean aprender más, hemos dado conferencias en 0xPARC sobre nuestro proving stack, así como presentaciones en Stanford y Berkeley sobre nuestra investigación. Para los auditores, hemos organizado sesiones especiales de auditores sobre nuestro código base. También creamos con frecuencia recursos educativos para las comunidades generales de zk y Ethereum: organizamos una serie semanal de investigación aplicada de zk y compartimos publicaciones técnicas sobre zk tech y Ethereum.

• Desarrollar con la comunidad. Nuestro zkEVM se ha desarrollado a través de un enfoque totalmente impulsado por la comunidad desde el primer día. Además de nuestro equipo y el equipo de PSE, hay varios miembros de la comunidad que contribuyen a diferentes partes de zkEVM (por ejemplo, muchos opcode circuit han sido implementados en paralelo por diferentes miembros de la comunidad, y se han realizado optimizaciones sorprendentes tanto en el keccak circuit como en el snark -verifier). También dirigimos una community call quincenal para mejorar el proving stack subyacente . Ya se ha logrado un progreso asombroso; por ejemplo, Goldilocks y FRI ahora son compatibles con Halo2. ¡Una base sólida gracias al esfuerzo de la comunidad permite la seguridad y la auditoría compartida!

Los beneficios de construir a través de un enfoque impulsado por la comunidad son claros. Podemos intercambiar ideas con un grupo grande y obtener ideas más creativas. Podría decirse que también es más seguro, ya que cada pull request recibe más reviews de otros miembros de la comunidad. Algunas partes comunes incluso se pueden compartir entre proyectos; por ejemplo, Axiom ha implementado un pairing circuit, que es una de las precompilaciones de zkEVM más difíciles.

Sin embargo, hay ciertos trade-offs que vienen con la construcción abierta. Es más difícil coordinarse en un grupo grande (no solo en términos de comunicación, sino también de prioridades). Puede ralentizar el desarrollo, ya que muchos pull requests requieren reviews y el estándar para el merging es de un nivel de exigencia alto.

Algo exclusivo de nuestro zkEVM es que también mantenemos un python spec, similar a lo que ha estado haciendo Ethereum para su consensus-spec y execution-spec. Mantener esta especificación permite a las personas que no están familiarizadas con Rust y Halo2 de low-level comprender el circuit logic. Hasta donde yo sé, ninguna otra implementación de zkEVM se toma el tiempo para hacer esto, de modo que puedan enviar más rápido y acercarse a mainnet de manera más agresiva.

En Scroll, estamos adoptando este enfoque impulsado por la comunidad para desarrollar todo el zkEVM. Creemos que el camino correcto a seguir es construir con la comunidad desde el principio. Tenga en cuenta que el "desarrollo impulsado por la comunidad" significa mucho más que ser solo open-source. No significa construir en privado y luego, de repente, abrir todo el código algún día. Debe medirse por cuántos external contributors hay y cómo se desarrolló el proyecto a lo largo del tiempo. Aceptamos el trade-off de ser más lentos en las primeras etapas, pero creemos en el poder del desarrollo impulsado por la comunidad en las etapas posteriores a medida que nuestra comunidad continúa creciendo.

Ethereum ha adoptado una estrategia similar para lograr su visión y valores llamada "sustracción". La idea es bastante simple: en lugar de construir todo por su cuenta, apoyan a la comunidad tanto como pueden. Les ayuda a buscar el equilibrio adecuado y centrarse en las cosas que son realmente importantes para ellos. Estamos haciendo exactamente lo mismo. Nos preguntamos: "¿Qué tipo de apoyo podemos brindar a la comunidad para ayudarlos a construir?" Creemos que nuestro enfoque de base y orientado a la comunidad nos llevará a una posición única en el espacio.

Esta mentalidad nos diferencia de otros competidores que tienen un gran ejército de personas que crean múltiples soluciones internas y que comercializan locamente en todas las direcciones. Solo nos enfocamos en enviar la pieza más importante y liderar en la dirección correcta.

Tenga en cuenta la seguridad y garantice un lanzamiento constante

La seguridad es la principal razón por la que la gente cree en la layer 2 en comparación con la layer 1 alternativa: puede heredar la seguridad de Ethereum sin confiar en los operadores de la layer 2. Pero todos los proyectos de layer 2 existentes todavía están lejos de ese estándar, con diferentes training wheels en su lugar. Por ejemplo, para los optimistic rollups, incluso si muchos ya se han lanzado en mainnet, aún necesitan upgradable keys y no admiten permissionless fraud proofs.

Para los zkEVM, también es un gran problema: cada player está en una carrera larga y necesita múltiples iteraciones, independientemente de cuán agresivo sea su approach de acercarse a mainnet. Todavía hay problemas fundamentales relacionados con zkEVM que no se han resuelto. Por ejemplo, el costo del prover será diferente del execution cost, y esto influirá en el gas pricing de la layer 2 o introducirá vulnerabilidades de seguridad.

Hemos reflexionado sobre los problemas de seguridad y hemos tratado de tomar las mejores decisiones. Enumero algunas de esas decisiones a continuación:

• Adopte un enfoque EVM-equivalent. Una razón importante para adoptar este enfoque es que conduce a una mejor developer experience, pero otra razón más profunda es heredar la seguridad del modelo EVM, que ya ha sido probado en batalla. También estamos reutilizando infraestructura como Geth para minimizar nuestra diferencia con Ethereum. Esto garantiza que nuestro secuencer de layer 2 se comporte exactamente igual que un nodo de layer 1, lo que maximiza la seguridad.

• Enfoque orientado a la comunidad. Como mencioné anteriormente, obtener reviews de reviews de la comunidad externa brinda una garantía más sólida para la seguridad del código. El tooling y el proving stack también se comparten entre proyectos, por lo que prestamos más atención al código base actual. Una buena medida debería ser "¿Cuántas personas están familiarizadas con su código base?", "¿Cuántas personas lo están usando seriamente?"

• Auditoría, auditoría y auditoría. Test, test y test. Hemos organizado sesiones de auditores para enseñarles a los auditores sobre nuestro development stack y hemos contratado a los mejores auditores de la industria para nuestros zkEVM circuits, pero las auditorías externas no son suficientes. Internamente, hemos integrado los test vectors EVM estándar y hemos realizado numerosas simulaciones para probar los bloques de la red principal. Además de eso, también otorgamos grants para respaldar exploraciones como verificación formal y fuzzing para nuestro zkEVM.

• Investigación sobre training wheels. Internamente, hemos estado investigando varias soluciones para eliminar las training wheels y cómo garantizar 2FA o 3FA para nuestro zkEVM. Creemos que esto es lo más importante que hay que hacer, aunque tiene menos ruido de marketing que tener nuevas funciones más sofisticadas. Como siempre, compartiremos nuestros hallazgos y discutiremos con la comunidad a medida que avancemos.

**Para mantener un alto nivel de seguridad, optamos por hacer que cada versión sea más estable y repetir la versión existente para seguir mejorando la solidez y la performance. **Haremos que todo sea aún más transparente en nuestros hilos de actualizaciones semanales .

Nuestra mentalidad de seguridad primero es la influencia más fuerte con respecto a nuestro roadmap. Nos ayuda a decidir qué camino debemos tomar al mismo tiempo que responde preguntas como:

• "¿Deberíamos apuntar a la EVM-equivalence o la Ethereum-equivalence en este momento?"

• "¿Deberíamos descentralizar el prover o secuencer primero?"

• "¿Deberíamos seguir agregando nuevas funciones o centrarnos en eliminar las training wheels?"

Iré desgranando cada una de esas preguntas en los siguientes posts.

La descentralización es importante en todas las capas

Piense en la historia de Ethereum y por qué la gente piensa que es creíblemente neutral . No es solo por la tecnología superior, sino también por el camino que tomó para llegar a donde está hoy. Ethereum está descentralizado en cada layer (transparencia en la toma de decisiones, consenso social, etc.). Del mismo modo, definimos la descentralización a través de múltiples layers diferentes y establecemos un estándar extremadamente alto para nosotros mismos:

• prover descentralizado. Somos los primeros en proponer la idea de una proving network descentralizada. Es el primer paso técnico que daremos para lograr la descentralización total y garantizar una alta confiabilidad. Un objetivo de optimización es reducir el proving cost, lo que permitirá que más personas ejecuten un prover, descentralizando aún más el sistema. Estamos trabajando conscientemente para evitar el dilema de que "el prover más rápido siempre gana", de modo que las personas no tengan que depender de costosos hardware personalizados para participar en nuestra red.

• secuencer descentralizado. Descentralizar el secuencer es otro paso importante que puede ayudar con la censorship-resistance y estamos comprometidos a trabajar en ello. Tenemos múltiples propuestas internas sobre cómo lograr esto, y pronto haremos públicas estas ideas para una discusión más amplia. Hay muchas razones por las que queremos descentralizar primero el prover (p. ej., preocupaciones sobre bug-free zkEVM y una interacción e incentivos más complicados entre el prover y el secuencer). Estamos pensando a muy largo plazo en cómo alinearnos con Ethereum a nivel de protocolo con respecto a los secuencers.

• desarrollo y gobernabilidad. El desarrollo de zkEVM se ha realizado de forma descentralizada con una comunidad de open-source contributors. Nos coordinamos con ellos a través de community calls zkEVM y prover. A medida que avancemos, haremos que el desarrollo y la gobernanza sean cada vez más transparentes (incluido el proceso de toma de decisiones de desarrollo, similar a las calls ACD de Ethereum).

• ecosistema y comunidad. Siguiendo la visión de Ethereum de "the infinite garden", queremos apoyar el crecimiento orgánico de nuestro ecosistema y comunidad. Por lo tanto, minimizaremos los "partnerships" con proyectos individuales específicos y, en cambio, nos mantendremos en una posición más neutral para apoyar todos los esfuerzos de base. No estamos pensando en términos de marketing, sino en términos de mensajería y comunicación. Nos preguntamos, “¿Cómo podemos ser más transparentes con nuestra comunidad?” Creemos que este enfoque es la mejor manera de crear un ecosistema más descentralizado y fomentar la creatividad.

• diversidad social y cultural. Además de la tecnología y el ecosistema, apuntamos a otro nivel de descentralización a nivel social y cultural. Nuestro equipo está distribuido en varios continentes (Asia, Europa, América del Norte, América del Sur, Australia). Puede encontrar un miembro del equipo de Scroll en casi cualquier parte del mundo, y esto nos permite desarrollar una comunidad distribuida a nivel local. Estamos creciendo con la diversidad cultural para un nivel más profundo de consenso social.

No construye sólo para Scroll, sino también para Ethereum

Nos mantenemos altamente alineados con Ethereum mientras desarrollamos nuestra scaling solution. Ethereum tiene un objetivo final ambicioso de "todo zk-SNARK": construir un Ethereum-equivalent zkEVM que se pueda usar para probar bloques de red principal. Imagine que un día, los validadores no necesitan volver a ejecutar un bloque de layer1, sino que solo verifican un succinct zk proof. Imagina que un día puedes probar toda la historia de Ethereum a través de una sola proof. ¿No es súper emocionante?

¡Este es exactamente el objetivo del equipo de PSE! Como el co-constructor más grande que desarrolla sobre la misma base de código durante aproximadamente 2 años, estamos avanzando directamente hacia este ambicioso objetivo.

Se ha propuesto algún estándar para categorizar diferentes tipos de zkEVM. Sin embargo, es más una especificación de alto nivel que describe lo que se debe hacer como resultado final. Como una de las principales fuerzas que impulsan Ethereum-equivalent zkEVM, queremos proponer algo diferente para distinguir el objetivo y el camino práctico para llegar allí. Este es el camino que queremos tomar para snark Ethereum:

• Implemente un zkEVM compatible con el nivel de bytecode con una sound zk proof

• Trabajar en iniciativas relacionadas para coordinar el desarrollo de la layer 1 y zkEVM

• Alcance un estándar comunitario y proponer EIP para mejorar Ethereum para el end game

En este momento, estamos en la primera fase del lanzamiento de un zkEVM compatible con bytecode listo para ser lanzado y nos hemos comprometido a seguir construyendo el futuro de Ethereum con toda la comunidad. Puede llevar años construir un Ethereum-equivalent zkEVM, lo suficientemente seguro y eficaz, lo que implica proof system upgrades, nuevos  circuit designs, así como innovaciones en la aceleración de software y hardware. Pero lo que es más importante, para adoptarlo en la layer 1, Ethereum tiene que hacer algunos cambios. Todas las actualizaciones importantes de Ethereum deben tener en cuenta zkEVM antes de lograr su objetivo final.

La idea prevaleciente ha sido que la layer 2 adapte los cambios unidireccionales para la layer 1. Sin embargo, a medida que maduran los rollups, creemos que este ya no debería ser el caso. Los rollups deben desempeñar un papel en la conducción de cambios en la layer 1, y los equipos de rollups deben desempeñar un papel más importante con respecto a la infraestructura de la layer 1 (4844, Danksharing, Verkle tree, PBS, Multidimensional fees, etc.). Debemos tener cuidado con las implicaciones de la compatibilidad con versiones anteriores, pero el legado no debe limitar el futuro. Todo el ecosistema debería coordinarse para un mejor Ethereum.

Conclusión

Hemos adoptado un enfoque impulsado por la comunidad para desarrollar zkEVM desde el principio, y nos hemos comprometido a seguir construyendo de una forma más colaborativa y a seguir devolviendo a la comunidad. Damos la máxima importancia a la seguridad y la descentralización, y nos estamos centrando en formas específicas de conseguirlas. Con nuestra mentalidad de seguridad, nos fijamos un alto estándar para ser más seguros y estables con cada versión. Con nuestra mentalidad de descentralización, perseguimos la descentralización en todos los niveles, incluida nuestro stack tech, el proceso de desarrollo, el ecosistema, la comunidad y la diversidad social.

Queremos impulsar al máximo la naturaleza open y censorship-resistant de las blockchains. Hemos elegido un camino que es único desde el principio. Nos hemos posicionado no sólo para construir una layer 2, sino también para impulsar el ambicioso objetivo de gruñir todo Ethereum. Con nuestra mentalidad, estamos operando como Ethereum, ¡y apuntando al mismo futuro the infinite garden!

Muchos  protocolos y en especial aquellos que manejan datos y ZK-SNARKs dependen de trusted setups, también llamadas ceremonias. Estas ceremonias son un procedimiento que se realiza una vez para generar un dato o datos que luego debe usarse cada vez que se ejecuta algún protocolo.

La generación de estos datos requiere cierta información secreta; la "confianza" proviene del hecho de que alguna persona o algún grupo de personas tiene que generar estos secretos, usarlos para generar los datos, luego publicar los datos y olvidar los secretos. Pero una vez que se generan los datos y se olvidan los secretos, no se requiere más participación de los creadores de la ceremonia. Este tipo de eventos fueron diseñados para poner en marcha las funciones de privacidad de la cadena. Sin embargo, también pueden utilizarse para respaldar mecanismos de escalabilidad, como planea hacer Ethereum.

📄KZG Commitments

Las “KZG commitments” (llamada así por sus creadores Kate, Zaverucha y Goldberg) son un esquema matemático (sí, criptografía muy avanzada) que permite generar “pruebas de disponibilidad de datos” tal y como las pruebas de validez en ZK Rollups para verificar que ciertos datos han sido publicados y están disponibles. A partir de esto, los nodos completos pueden comprobar que los datos de la blockchain están disponibles sin tener que ser descargados completamente, solamente satisfasiendose con una porción aleatoria de datos de un determinado bloque más la prueba KZG generada en dicho momento.

✅Importancia de Proto-Danksharding y KZG

Ethereum, en busca de mejorar la escalabilidad de la red, planeó su propia ceremonia, la KZG ceremony, con el objetivo de proporcionar una base para una mejor escalabilidad mediante la implementación del EIP-4844 (también conocido como proto-danksharding).

La principal característica introducida por proto-danksharding es un nuevo tipo de transacción, que llamamos transacción con blob. Una transacción con blob es como una transacción normal, con la diferencia de que también transporta un fragmento adicional de datos llamado blob. Los blobs son extremadamente grandes (~125 kB), y pueden ser mucho más baratos que cantidades similares de calldata. Sin embargo, los datos blob no son accesibles para la ejecución de la EVM; la EVM sólo puede ver un compromiso con el blob. En consecuencia, la escalabilidad de la red aumenta, porque estos datos no compiten con el uso de gas de las transacciones Ethereum existentes.

Entre los demás beneficios que traerá la integración del proto-danksharding se tienen:

• Futuro de los Rollups: Los rollups han demostrado ser la única solución de escalado fiable para Ethereum. Los fees de transacción L1 son un obstáculo importante para los nuevos usuarios y aplicaciones. El proto-danksharding  ayudará a facilitar el paso de todo el ecosistema a los rollups.

• Reducción de fees:  El proto-danksharding  puede reducir los fees de los rollups en magnitud y permitir que Ethereum siga siendo competitivo sin sacrificar la descentralización.

• Compatibilidad futura: Los blobs se comprometen con KZG: un esquema de compromiso vectorial eficiente. Estos compromisos se utilizan en el mismo andamiaje que la propuesta completa de "danksharding".

• Beacon Node: Los blobs se mantienen en los Beacon Nodes, no en la execution layer (por ejemplo, en prysm, no en geth). Para futuros trabajos de sharding sólo requiere cambios en el Beacon Node, permitiendo a la execution layer trabajar en otras iniciativas en paralelo.

• Uso manejable del disco: Los blobs son 4096 elementos de 32 bytes cada uno, con un máximo a largo plazo de 16 blobs por bloque. 4096 * 32 bytes * 16 por bloque = 2 MiB por bloque como máximo. El tope de blobs por bloque puede empezar siendo bajo y crecer a lo largo de varias actualizaciones de la red.

• Vida corta: Los blobs se eliminan después de ~2 semanas. Disponibles el tiempo suficiente para que todos los actores de una L2 puedan recuperarlos, pero lo suficientemente cortos como para que el uso del disco sea manejable. Esto permite que los blobs tengan un precio más barato que los CALLDATA, que se almacenan en el historial para siempre.

🔴¿En qué consiste la ceremonia KZG?

La ceremonia KZG es un ritual público coordinado que proporciona la base criptográfica para las mejoras de escalabilidad de Ethereum, como por ejemplo, el proto-danksharding. En esencia el objetivo de este evento es la creación de la estructura principal  que será utilizada para las implementaciones futuras.

💡¿Cómo participar en la ceremonia KZG?

El primer paso es ingresar al link oficial de la ceremonia: https://ceremony.ethereum.org/

para poder observar el siguiente interfaz. Para iniciar la contribución a la ceremonia solo es necesario dar click en empezar.

1. Estado actual del Secuenciador.

2. Número total de direcciones que han contribuido a la ceremonia y número total de usuarios en espera para participar.

3. Lista de lenguajes disponibles para el portal.

4. Tiempo restante para participar en la ceremonia.

5. Botón de inicio para la participación.

6. Interfaz IPFS: Diseñada para aquellos usuarios que desean usar sus builds personalizadas.

7. Otros clientes: son scripts escritos en diferentes lenguajes tales como rust, go, python, etc; para aquellos usuarios que buscan usar otra web.

8. ¡Escriba su propio!: Ethereum foundation organizó un concurso para que los participantes construyan y sugieran su propio método de recolectar la entropía. Las reglas y criterios para participar los puedes entrar aquí. (Válido hasta el 15 de Marzo)

   El paso siguiente consiste en la ingresar la entropía, el cual es un conjunto de datos aleatorios que se utilizaran para generar la contribución que será implementada por el secuenciador.

En este paso es importante tener en cuenta que además de ingresar un “secreto” (cualquier texto) y una “muestra” (generada por el navegador de forma aleatoria), es necesario ingresar un “símbolo”, el cual será tomado del movimiento del cursor en la interfaz. A medida que se mueva el cursor, la  barra de color verde en forma de serpiente empezará a crecer hasta dar toda la vuelta. Una vez hecho esto podremos avanzar al siguiente paso.

Luego de ingresar los datos, se requerirá que el usuario desbloquee con una wallet de ethereum o Github para continuar.

Nota: Con el fin de evitar sybil attacks, Ethereum Foundation puso la condición de que sólo direcciones de Ethereum que haya enviado al menos 4 transacciones antes del 13 de enero de 2023 son elegibles para participar en la ceremonia.

Una vez hecho esto, la página solicitará que el usuario firme con la wallet o Github. (en este caso se usará una wallet de ethereum).

A continuación el portal nos redireccionará a una nueva página, con el objetivo de volver a firmar. Esto se hace así con el objetivo de minimizar el spam y prevenir la presencia de bots.

En esta nueva página tendremos la posibilidad de usar cualquiera de las wallets que se muestran. Cabe destacar que se debe usar una wallet que tenga la misma dirección de ethereum que en la firma anterior.

Una vez seleccionada la wallet a usar, la wallet pedirá autorización para conectarse al portal.

Luego de esto, es tan simple como darle a “firmar” para continuar.

Una vez completado este paso, el portal nos redireccionará a la interfaz del principio. y nos mostrará el mensaje, “ ESPERANDO PARA SER ENVIADO”. En ese momento nuestra contribución está en el lobby para ser tomada por el secuenciador.

Ahora bien, el secuenciador toma una contribución que está en el lobby de forma aleatoria y la procesa, esto sucede cada hora, por lo que es necesario tener un poco de paciencia (y quizás algo de suerte) para ser seleccionado. El tiempo de espera para esto puede variar en gran medida debido a la aleatoriedad, sin embargo el promedio de tiempo por usuario es de aproximadamente 4 a 7 días.

Una vez seleccionado será procesada tu contribución y LISTO!

La interfaz te dará la oportunidad de compartir tu experiencia en Twitter y Lenster.

De igual forma también podremos ver y descargar los detalles de la contribución tales como las firmas, el ID del participante, etc. Al darle en “Ver su contribución”.

Este archivo descargable es el receipt lo cual certifica que participó en la ceremonia.

¡Es la prueba irrefutable de que estas formado parte de la historia de Ethereum!

¡Que no se te olvide guardarlo bien!

Nota: Las firmas BLS son aquellas es un esquema de firma criptográfica que permite al usuario verificar que un firmante es auténtico . Por otro lado, la firma ECDSA, es un algoritmo de cifrado de clave pública que, como ya sabemos, se utiliza para generar una firma digital única y verificar la autenticidad de un mensaje o transacción en línea.

Otra forma de validar que participamos es ingresando nuestra dirección usada en la ceremonia en el siguiente link: https://ceremony.ethereum.org/#/record

y listo! tu contribución a la ceremonia KZG ha sido completada!

💥Problemas comunes

❌Dirección no elegible

La ceremonia sólo admite a aquellas direcciones con un mínimo de 4 transacciones completadas antes del 13 de Enero del 2023, con el fin de evitar sybil attacks. Al usar una dirección que viole dicha regla aparecerá lo siguiente:

👨🏻‍🤝‍👨🏻Participación doble

Una vez que una dirección contribuya a la ceremonia no es posible usarla para participar de nuevo, sin importar que el secreto o otra entropía sea diferente, al intentarlo saldrá el siguiente mensaje:

Una vez que se acabe el tiempo del contador, todas las direcciones que participaron recibirán un POAP conmemorativo probando así, que son parte de la historia de Ethereum para siempre!

💯Agradecemos profundamente a Nico, por su guía y conocimiento para la elaboración de este artículo.

Que curioso que la descentralización sea capaz de unir a tanta gente bonita.

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unete a la conversación en nuestra comunidad de Telegram!

https://t.me/l2espaniol

https://twitter.com/Layer2es

🌐 #1 - Starknet Prover será Open Source

Hola comunidad 👋

Hoy queremos presentarles StarkWare, una compañía innovadora en el mundo de Ethereum. StarkWare es el desarrollador de soluciones de escalado de capa 2 populares como StarkEx y StarkNet, y ha anunciado recientemente que el software STARK Prover será de código abierto para la comunidad. Estos y otros avances recientes están transformando el panorama de las soluciones de escalado de capa 2, en este documento, analizaremos estos cambios y también discutiremos si la definición actual de estas soluciones se queda corta.

https://twitter.com/StarkWareLtd/status/1622197933025251328

La tecnología ZK-Rollup de StarkWare es una solución de escalado de capa 2 que ayuda a la plataforma Ethereum a lograr transacciones más rápidas y económicas. Al agrupar cientos de miles de transacciones fuera de la cadena y verificarlas en la cadena por solo una fracción del costo, StarkWare está impulsando el crecimiento y la adopción de Ethereum.

Además, con el cambio de nombre de STARK Prover a Starknet Prover y su colocación bajo una licencia Apache 2.0, StarkWare está aumentando su compromiso con la comunidad de desarrolladores de Web3. Al permitir que los desarrolladores copien, modifiquen y distribuyan comercialmente el código fuente, la compañía está fomentando la colaboración y la innovación en el sector de la tecnología blockchain. Este movimiento es un paso importante para lograr una participación más amplia y significativa de la comunidad en el desarrollo del ecosistema.

"Este es un momento histórico para escalar Ethereum y, en un sentido más amplio, para la criptografía”

"Esto pondrá a la tecnología STARK en el lugar que le corresponde, como un bien público que se utilizará para beneficiar a todos”

Esto fue lo que comentó el presidente de StarkWare y cofundador de Eli Ben-Sasson durante un evento en Tel Aviv "StarkWare Session 2023", en el que se hablaron de temas importantes que profundizaremos en este artículo y haremos que vuestra visión vaya mas lejos, intentando acercarnos a la de su cofundador con StarWare y STARK.

Así que acompáñanos en este viaje para conocer mejor el ecosistema de StarkWare y que está haciendo que sus STARK o Validity Proof estén mejorando la escalabilidad de Ethereum, aprendamos que es StarkEx y cómo funciona.

⚙️ #2 - El motor StarkEx

StarkWare ha desarrollado StarkEx, un revolucionario motor de escalabilidad de capa 2 para la cadena de bloques Ethereum, este motor ha sido diseñado con el objetivo de mejorar de manera significativa la escalabilidad de la cadena de bloques Ethereum. Con StarkEx, se pueden realizar transacciones ultrarrápidas con tarifas de gas extremadamente bajas, sin sacrificar la seguridad, privacidad ni la autocustodia de los fondos.

Para lograr esta combinación única, StarkEx se basa en un sistema criptográfico avanzado llamado Validity Proof. Este sistema permite verificar la validez de las transacciones en tiempo real, ofreciendo una solución escalable y segura para las transacciones en la cadena de bloques Ethereum.

La validez prueba las transacciones por lotes fuera de la cadena, mientras valida la legitimidad de las transacciones a través de un contrato inteligente en Ethereum Mainnet. Además de aumentar el rendimiento, la tarifa de gas se divide entre todas las transacciones en el mismo lote, lo que da como resultado tarifas de gas más bajas para todas las aplicaciones que utilizan StarkEx.

La esencia de StarkEx radica en su división eficiente del trabajo entre dos componentes clave: el probador STARK fuera de la cadena y el verificador en la cadena. Este proceso se divide en cuatro etapas simples:

1. Procesamiento por lotes: todas las transacciones se procesan juntas en lotes.

2. Validación y actualización: las transacciones se validan y se actualizan el estado de la cadena de bloques.

3. Generación de una prueba: se genera una prueba que verifica la integridad de las transacciones.

4. Verificación en cadena: la prueba se verifica dentro de la cadena para garantizar la integridad de las transacciones.

Además, StarkEx ofrece privacidad y seguridad para las transacciones gracias a su criptografía segura poscuántica. Esto significa que la integridad de las transacciones en StarkEx está protegida contra posibles ataques de computadoras cuánticas, que en el futuro podrían tener la capacidad de vulnerar algoritmos criptográficos tradicionales.

La flexibilidad de StarkEx también será un punto a su favor, con la implementación e integración listas para usar de StarkEx a través de una API REST simple, las aplicaciones listas para producción se pueden lanzar en Mainnet en solo unas pocas semanas y gracias a Cairo, el expresivo lenguaje de programación ZKP de Starkware, hay más flexibilidad para agregar características adicionales a la lógica específica de StarkEx.

La última versión lanzada de StarkEx, la v4.5.1, incluye la compatibilidad con los tokens ERC-1155, estos tokens pueden ser almacenados de manera segura y eficiente tanto en bóvedas L1 como L2. StarkEx permite a los usuarios almacenar datos de acuerdo con una variedad de necesidades y aplicaciones, proporcionando flexibilidad y eficiencia.

• ZK-Rollup: los datos se publican en la cadena.

• Validium: los datos se almacenan fuera de la cadena.

• Volition es un modo de disponibilidad de datos híbrido, en el que el usuario puede elegir si colocar los datos dentro o fuera de la cadena.

🔩 #3 - StarkEx en algunas soluciones

Exploraremos cuatro soluciones diferentes que son evaluadas por L2Beat y utilizan el motor StarkEx:

• InmutableX: es una solución de escalado de capa 2 para NFT en la cadena de bloques de Ethereum. En su misión de potenciar la próxima generación de juegos Web3, Immutable aprovecha StarkEx para brindar a los usuarios una jugabilidad fluida, velocidades de transacción ultrarrápidas y acuñación y comercio de NFT sin gas y totalmente neutral en carbono.

  StarEx ha impulsado más de $361 millones en volumen de operaciones de NFT desde en volumen de negociación de NFT de 155 millones de transacciones en todo el ecosistema ImmutableX, incluidos los juegos y mercados Web3 como Gods Unchained, Guild of Guardians y GameStop Marketplace.

• Sorare: es un juego de deportes de fantasía basado en la cadena de bloques Ethereum que permite a los jugadores recolectar, intercambiar y administrar un equipo virtual de tarjetas de jugador digitales NFT.

  Según el arquitecto de cadena de bloques de Sorare, Pierre Duperrin, la integración de Sorare con StarkEx finalmente permitió a Sorare irrumpir en la corriente principal, al tiempo que le ahorró a la empresa cerca de $ 1 millón por semana. Desde su lanzamiento en julio de 2021, StarkEx ha impulsado un volumen de negociación de más de $790 millones en casi 16 millones de transacciones en la plataforma Sorare.

• dYdX: es un intercambio de finanzas descentralizadas (DeFi) sin custodia que ofrece opciones de comercio perpetuas para más de 35 criptomonedas principales. Decidido a brindar la mejor experiencia comercial posible, dYdX implementó StarkEx para brindar a los usuarios tarifas comerciales más bajas y tamaños mínimos comerciales, operaciones con márgenes cruzados, liquidación comercial instantánea y, lo que es más importante, autocustodia de todos los activos.

  “Las transacciones se envían en cadena en ZK-Rollup, lo que reduce la cantidad de gas requerida por transacción. Podemos transferir esos ahorros a los comerciantes en forma de tarifas comerciales reducidas en todos los ámbitos”, dijo el fundador y director ejecutivo de dYdX, Antonio Juliano.

• ApeX Pro: es una plataforma de operaciones sin custodia que ofrece operaciones ilimitadas de contratos perpetuos con márgenes cruzados. ApeX Pro tiene la intención de resolver los puntos débiles de (1) acceso global limitado, (2) desempeño comercial insatisfactorio y (3) seguridad y protección de privacidad insuficientes, con una solución simple pero dinámica, "comercio social impulsado por una red descentralizada y sin permisos."

  "La sincronización del motor de escalabilidad de capa 2 de StarkWare, StarkEx con ApeX Pro, permite realizar transacciones de contratos perpetuos aceleradas y más baratas, al mismo tiempo que ofrece liquidez comprobada, profundidad de mercado y transparencia a los comerciantes”.

ApeX Pro está aprovechando las pruebas criptográficas de StarkEx y Validium para validar de forma segura los lotes de transacciones. La disponibilidad e integridad de los datos en cadena se puede garantizar con las pruebas STARK de StarkWare, que ayudará a salvaguardar un protocolo totalmente sin custodia. Construida sobre la red Ethereum, esta arquitectura de capa 2 publica pruebas ZK directamente en los contratos inteligentes de Ethereum para su verificación. Las transacciones también se empaquetan de manera única para publicar en la cadena para los comerciantes preocupados por la privacidad de los datos, ya que solo se harán visibles los cargos por saldo.

📝 #4 - Fases de Starknet y Cairo 1.0

Ahora que hemos explorado el funcionamiento del motor de StarkEx y adquirido un mayor conocimiento de Starknet, es hora de analizar el poderoso lenguaje de programación, su nuevo Cairo 1.0-Alpha.2.

https://twitter.com/Starknet/status/1618896699430256645

Cairo se introdujo por primera vez en 2020 como un lenguaje de programación completo de Turing para escribir de manera eficiente programas demostrables con STARK. Cairo 1.0 es un lenguaje de alto nivel similar a Rust, al igual que Rust, está destinado a permitir que los desarrolladores escriban fácilmente código que sea eficiente y seguro.

Uno de los cambios más significativos en Cairo 1.0 es la sintaxis, se han inspirado en Rust para crear un lenguaje más amigable para los desarrolladores que sea más fácil de leer y escribir, la nueva versión de Cairo permite escribir código más seguro, además de ser más expresivo.

Cairo 1.0 también presenta Sierra, una nueva representación intermedia que garantiza que todas las ejecuciones de Cairo puedan probarse, esto hace que Cairo 1.0 sea especialmente adecuado para su uso en una red sin permisos como StarkNet, donde puede proporcionar una sólida protección DoS y resistencia a la censura.

La próxima versión testnet de StarkNet, la Alpha V0.11.0, prevista para el primer trimestre de 2023, presentará la capacidad de implementar y ejecutar contratos utilizando el nuevo lenguaje de programación Cairo 1.0. La actualización marcará el comienzo del período de transición hacia un sistema que ejecuta solo contratos de Cairo 1.0, este Período de Transición terminará con la Regénesis, que se espera unos meses más tarde.

El objetivo de StarkNet es escalar exponencialmente Ethereum utilizando la integridad matemática de STARK, y el objetivo de Cairo es hacer que esta escala exponencial sea accesible para los desarrolladores. Accesibilidad significa un lenguaje de programación que sea eficiente, fácil de leer y escribir y seguro de usar.

Ahora que StarkNet ha alcanzado un alto nivel de usabilidad, es importante examinar sus principales prioridades y comprender las fases en las que se ha basado su desarrollo:

• 1ª FASE: funcionalidad y usabilidad

• 2ª FASE: escalabilidad y rendimiento

• 3ª FASE: descentralización

🌍 #5 - Descentralización con Papyrus

El lanzamiento de Starknet Prover y su disponibilidad de código abierto representan un hito importante en el avance de Starknet hacia su tercera fase de desarrollo. Como parte integral de la descentralización, también es necesario destacar a Papyrus, un nodo completo de Starknet disponible de manera abierta. Juntos, estos lanzamientos marcan un progreso significativo hacia un futuro más descentralizado para Starknet.

https://twitter.com/StarkWareLtd/status/1613154088866160641

Papyrus será un componente clave de la infraestructura descentralizada de StarkNet, proporcionará las bases para el nuevo StarkNet Sequencer, que mejorará drásticamente el rendimiento de StarkNet, ayudará a mejorar el rendimiento y la descentralización. Papyrus se une a otros nodos completos de StarkNet como Pathfinder y Juno, que son responsables de sincronizar y mantener el estado de StarkNet.

En línea con el movimiento continuo hacia el código abierto de la pila StarkNet, Papyrus es de código abierto bajo la licencia Apache 2.0. StarkNet ha logrado una excelente usabilidad, y ahora el rendimiento del sistema es la principal prioridad, con la descentralización cobrando fuerza.

La mejora del rendimiento del sistema se está abordando mejorando el rendimiento del secuenciador, que es responsable de la producción de bloques de StarkNet, el secuenciador es la "máquina" que ordena y ejecuta transacciones después de que se envían.

Papyrus proporcionará al StarkNet Sequencer una capa de almacenamiento eficiente, lo que ayudará a mejorar el rendimiento. En primer lugar, esto significa que el secuenciador mantendrá una base de datos local en lugar de una base de datos basada en la nube, además, Papyrus almacenará un almacenamiento de clave/valor plano, lo que significa que interactuará directamente con el estado, en lugar de llegar a él a través de las rutas de Merkle Patricia.

Actualmente, hay dos equipos que están desarrollando un nodo completo de StarkNet:

• Pathfinder de Equilibrium: implementado en Rust.b

• Juno de Nethermind: están trabajando en la primera versión oficial de su implementación de Golang.

Papyrus se une a esta combinación saludable y fomenta la descentralización y la redundancia, agregar otro nodo completo y hacerlo de código abierto ayuda a proporcionar la variedad de implementaciones del cliente, lo cual es un indicador importante de la fortaleza de una red descentralizada, fijémonos en la arquitectura de Starknet y como el acople de Papyrus con Juno y Pathfinder refuerza la tercera fase.

📓 #6 - Herodotus

Es importante tener en cuenta cómo las nuevas tecnologías subyacentes de StarkNet están surgiendo para facilitar la comunicación entre diferentes capas con STARK. Un ejemplo de esto es Herodotus, que utiliza pruebas de almacenamiento para demostrar que el nonce de una cuenta no ha sido modificado durante un período de tiempo determinado. Esta información puede ser utilizada como un desencadenante para permitir que los familiares accedan y administren la cuenta

https://twitter.com/HerodotusDev/status/1614172762108751874

Herodotus se enfoca en brindar contratos inteligentes con acceso en tiempo real a datos en la cadena que provienen de otras capas de Ethereum. Para lograr esto, combina pruebas de almacenamiento con zk STARK, lo que permite acceder a datos transversales entre las capas de Ethereum y hacer que los contratos se implementen de manera autoconsciente.

La tecnología Herodotus ofrece una solución innovadora que permite a los desarrolladores crear contratos que pueden leer el estado L1 en L2, el estado L2 en L1 y el estado L2 en L2 de manera totalmente sincrónica, lo que elimina la necesidad de enviar mensajes asíncronos de un lado a otro.

Herodotus aprovecha el hecho de que las cadenas de bloques con estado como Ethereum o Starknet confirman y almacenan su estado de forma criptográfica, mediante el uso de estructuras de datos dedicadas como son:

• Merkle Patricia Trees

• Merkle Trees

• Verkle Trees

La propiedad común de estos es la capacidad de probar la inclusión de cualquier dato guardado en la estructura de datos, estos datos pueden ser, por ejemplo: almacenamiento de contratos inteligentes, saldos de cuentas, nonces de cuenta, registros de transacciones...

Probar cualquiera de ellos es posible dada la raíz de un árbol, Herodotus se asegura de que dichas raíces estén disponibles en cada red compatible con su infraestructura, puede aprovechar acumuladores criptográficos como Merkle Mountain Ranges y pruebas zk recursivas para comprimir datos de blockchain.

🤖 #7 - zkEVM Polygon y zkEVM Kakarot

Ahora que vemos como este tipo de pruebas pueden aportar la verificación de una forma matemática efectiva, nos enfocaremos como estas pruebas también se incorporan en algunas zkEVM, en este caso en Kakarot, una máquina virtual de Ethereum escrita en Cairo que se puede implementar en StarkNet y ejecutar cualquier programa de código de bytes EVM, por lo tanto, Kakarot se puede usar para ejecutar contratos inteligentes de Ethereum en StarkNet. Kakarot con Cairo 1.0 se convertirá en un Super Saiyajin, más potente, más rápido, más fuerte y más seguro.

https://twitter.com/KakarotZkEvm/status/1620513080131338245

Kakarot es un competidor de la tecnología zkEVM de Polygon, que emplea un enfoque de prueba de transacciones fuera de la cadena combinando STARK y SNARK como generadores de pruebas. El zkProver está compuesto por máquinas de estado (Principal y Secundario) y constructores de pruebas zk.

• Máquina de estado principal: maneja la ejecución del bytecode EVM que son interpretados por el lenguaje zkASM. También establece las restricciones polinómicas que deben cumplirse para que las transacciones por lotes sean consideradas válidas.

• Máquina de estado secundaria: no es un subcomponente, es una colección de varios ejecutores para una máquina de estado secundaria individual.

• Generador de pruebas STARK: se utiliza para demostrar que los lotes satisfacen las restricciones polinómicas.

• Creador de pruebas SNARK: se utiliza para probar la corrección de las pruebas STARK y para publicar las pruebas de validez.

❄️#8 - Winterfell

Exploremos Winterfell, una herramienta de verificación y generación de pruebas de STARK de "propósito general" escrita en Rust. Al ser de propósito general, Winterfell es capaz de generar pruebas de CI para cualquier cálculo que se pueda describir con un lenguaje completo de Turing, permitiendo la verificación de una amplia variedad de programas. La foto de la repo inferior de Facebook "META" muestra hasta dónde han llegado estas pruebas matemáticas de validez de STARK.

Winterfell utiliza STARK que a diferencia de muchos otros sistemas de prueba, los STARK son totalmente transparentes, esto significa que no necesitan realizar complicadas ceremonias de configuración confiables para comenzar a usar STARK. Las configuraciones confiables son una debilidad de seguridad potencial en otros protocolos de conocimiento cero, porque una configuración confiable comprometida permite a los atacantes generar pruebas de CI falsas. "Los STARK son inmunes a esto".

En comparación con otros sistemas, la generación de pruebas STARK es extremadamente rápida cuando se trata de cálculos uniformes o cálculos con estructuras regulares. Afortunadamente, la gran mayoría de los programas que la gente escribe poseen tales estructuras regulares, además, casi todos los pasos del proceso de generación de prueba STARK son masivamente paralelizables. Por lo tanto, con frecuencia podemos acelerar la generación de pruebas distribuyéndolas entre más y más núcleos de CPU.

https://twitter.com/0xPolygon/status/1460609725477703693

Ninguna de las propiedades individuales nombradas anteriormente son exclusiva de STARK, sin embargo, ningún otro sistema de prueba combina criptografía ajustada, transparencia y rendimiento en la medida en que lo hacen los STARK. Winterfell aprovecha al máximo estos beneficios mientras abstrae la mayor parte de la complejidad. Por ejemplo, la generación de pruebas se puede distribuir en varios núcleos de CPU para reducir drásticamente el tiempo de generación de pruebas. Además, cuentan con planes para permitir la generación de pruebas totalmente distribuidas en varias máquinas.

♾️ #9 - Polygon Miden con STARK

Tanto Distaff VM como Winterfell son piezas fundamentales de Polygon Miden, si, el Winterfell nombrado de Facebook unos párrafos más arriba. Polygon Miden es un ZK-Rollup de propósito general basado en STARK, pero antes un poco de historia.

En 2019 se desarrolló GenSTARK, un probador basado en STARK que podía generar pruebas para cualquier tipo de cálculo, el problema con esta herramienta era que no era muy compatible con los desarrolladores, por lo que querían encontrar una forma de solucionarlo.

Empezaron a pensar más en una máquina virtual basada en STARK y en cómo sería posible hacer algo como esto, esto culminó con la edición de un artículo llamado: "Un boceto para una VM basada en STARK", en febrero de 2020, y solo un par de años después, decidieran construir su propia VM STARK utilizando las ideas de este artículo, esto condujo al desarrollo de Distaff VM en abril de 2020, que terminó siendo una pieza fundamental para el proyecto actual de Miden.

Distaff VM es una máquina virtual de conocimiento cero.

Cada vez que se ejecuta un programa dentro de un zk-VM, se genera una prueba de ejecución de zk para verificar que el programa se ejecutó correctamente, sin tener que ejecutarlo realmente. Hay dos métodos en los que se puede probar el conocimiento aquí, ya sea usando una prueba SNARK o una prueba STARK, aunque Distaff es una máquina virtual basada en STARK.

Según su página de github:

“Para cualquier programa ejecutado en Distaff VM, se genera automáticamente una prueba de ejecución basada en STARK. Esta prueba puede ser utilizada por cualquier persona para verificar que un programa se ejecutó correctamente sin necesidad de volver a ejecutar el programa o incluso saber cuál era el programa”.

Lo que hace Miden VM es tomar esta Distaff VM y agregarle un sistema de prueba más eficiente, Winterfell. Un año después de liderar el desarrollo de Winterfell, Bobbin ayudo al desarrollo de Polygon Miden.

"Winterfell es un probador y verificador STARK de subprocesos múltiples y completamente funcional para cálculos arbitrarios". - esencialmente una versión mucho más eficaz y actualizada de GenSTARK.

El equipo de Polygon Miden analizó sus pruebas con la ayuda de RISC Zero y DelendumV. Medir el rendimiento en diferentes sistemas ZKP es muy difícil, el propósito del proyecto de evaluación es producir una colección de evaluaciones comparativas estándar para comparar el rendimiento de diferentes bibliotecas de prueba de conocimiento cero, midiendo el tiempo de prueba en varios entornos de hardware estándar, lo que permite que cada sistema de prueba muestre su comportamiento en el mundo real cuando se ejecuta en sistemas comúnmente disponibles.

https://twitter.com/0xPolygonMiden/status/1613635088746696705

🔲 #10 - RISC Zero

Podemos ver cómo este tipo de pruebas en arquitecturas se está expandiendo más allá de Starknet y Cairo. RISC Zero es una plataforma informática general verificable de conocimiento cero que utiliza zk STARK y la microarquitectura RISC-V, que es una arquitectura de CPU basada en un Conjunto de Instrucciones Reducido con una licencia de código abierto.

https://twitter.com/RiscZero/status/1542970508651614209

Como hemos aprendido una prueba de conocimiento cero permite que una parte (el probador) convenza a otra parte (el verificador) de que algo es cierto sin revelar todos los detalles. En el caso de RISC Zero, el probador puede mostrar que ejecutó correctamente algún código (conocido por ambas partes), mientras que solo revela al verificador la salida del código, no cualquiera de sus entradas o cualquier estado durante la ejecución.

El zkVM de RISC Zero es una máquina virtual especial que emula una pequeña computadora RISC-V. Esta máquina virtual permitirá a los desarrolladores generar ZKP de alto rendimiento para una amplia variedad de aplicaciones escritas en lenguajes como Rust, C++, Solidity, Go y más.

⛓️🔒#11 - ZeroSync

Por último, pero no menos importante, vemos cómo StarkWare y STARK llegan aún mas lejos, este tipo de pruebas se pueden añadir en otro tipo de plataformas o capas muy diferentes y, también pueden servir para verificar el estado de la cadena de Bitcoin en un instante, como es el caso de ZeroSync. No es necesario descargar cientos de gigabytes de bloques, una prueba criptográfica compacta es suficiente para validar todo el historial de transacciones y los saldos actuales de todos. ¡No confíes Verifica!

https://twitter.com/lucidLuckylee/status/1611855016465207299

La primera versión en pruebas es la aplicación Zerosync de Bitcoin Core en modo podado, la visión a largo plazo de ZeroSync es convertirse en una caja de herramientas para pruebas personalizadas de Bitcoin. Las pruebas de STARK le permiten transformar los datos de la cadena de bloques, mejorarlos, filtrarlos, indexarlos para consultas eficientes y optimizarlos para su caso de uso individual.

Al implementar las reglas en Cairo, podemos crear un programa que valide un solo bloque y pueda generar una prueba para él si, y solo si, la validación fue exitosa, hacen uso de un probador de código abierto para Cairo llamado Giza para probar el programa generado y su seguimiento de ejecución. Debido al protocolo STARK subyacente, es inviable falsificar una prueba de ejecución que certifique la validación correcta del encabezado del bloque, una prueba correcta tiene un tamaño de unos pocos cientos de kilobytes y se puede verificar en otras cadenas de bloques, fuera de la cadena (por ejemplo, para la sincronización de nodos) o incluso en otra prueba STARK.

Para generar una prueba para múltiples encabezados de bloque sucesivos, podemos agrupar su validación en un solo programa Cairo, siempre que la máquina probadora subyacente tenga suficiente poder de procesamiento. Se puede crear una prueba para toda la cadena de Bitcoin mediante la verificación de varias pruebas de validación por lotes en una nueva prueba STARK, haciendo uso de las llamadas pruebas recursivas.

Puede usar el verificador Giza STARK en WebAssembly para verificar una prueba de la cadena Bitcoin en su navegador. Hasta ahora, han generado pruebas solo para los primeros miles de bloques, en pruebas, valida solo un bloque y falsifica la validación de la cadena anterior. Todavía están trabajando en la recursividad de prueba para el probador de Giza, la recursividad se trata de validar un STARK en un STARK, esto les permitiría ampliar gradualmente la prueba de cadena anterior con una siguiente prueba de bloque.

Es posible verificar la cadena de bloques de Bitcoin en su navegador utilizando el verificador Giza STARK en WebAssembly. Aunque actualmente solo se han generado pruebas para los primeros miles de bloques, estas pruebas permiten validar un solo bloque mientras falsifican la validación de la cadena anterior. Sin embargo, el equipo de desarrollo está trabajando en implementar la recursividad de prueba en el probador de Giza, lo que permitirá validar un STARK dentro de otro STARK y, de esta manera, ampliar gradualmente la prueba de la cadena anterior con cada nuevo bloque validado.

🫂 Agradecimientos

🎉 ¡Gracias por leer hasta el final! Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la 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!

👨‍💻Arbitrum permite que los devs utilicen otros lenguajes de programación a través de la iniciativa Stylus

A menudo, los desarrolladores consideran que la inclusión de nuevos lenguajes de programación es beneficiosa para la industria cripto en la creación de contratos inteligentes. Sin embargo, esto a menudo requiere el uso de nuevas redes con diferentes niveles de seguridad y descentralización. Offchain Labs, la empresa detrás de Arbitrum, la red de capa 2 para Ethereum, está trabajando actualmente para abordar esta limitación.

La empresa que lanzó Arbitrum en 2021, presentó al público Stylus, una iniciativa diseñada para permitir a los desarrolladores desplegar programas escritos en lenguajes de programación populares como C, C++ y Rust, para Arbitrum One y Arbitrum Nova.

A través del poder de los WebAssembly smart contracts, los usuarios podrán implementar programas escritos en sus lenguajes de programación favoritos para ejecutarlos junto con los contratos existentes en la EVM en Arbitrum. Es más de un orden de magnitud más rápido, reduce drásticamente los fees y es totalmente interoperable con la VM de Ethereum.

Entre los beneficios que Stylus introducirá tendremos:

🚀Dapps más veloces con fees más bajos

Las Dapps de Arbitrum escritas en lenguajes como Rust son más de un orden de magnitud más rápidas que sus homólogas de Solidity y Vyper, debido a esto Offchain Labs espera que la velocidad de cómputo mejore x10. Asimismo, Stylus reduce drásticamente los fees, lo que permite una nueva era del high-compute blockchain applications en una amplia gama de campos.

La combinación de estas características con los beneficios de ahorro de costes de datos de Arbitrum Nova resulta en una herramienta poderosa. DeFi, DAOs y otros casos de uso podrán aprovechar las mismas eficiencias en Arbitrum One, ya que Stylus está completamente integrado en ambas cadenas.

🏖Nuevo horizontes

Una computación barata conlleva la libertad de escribir programas potentes y más sofisticados, por lo que la comunidad de Ethereum siempre está trabajando para acelerar la EVM. Esto incluye la adición ocasional de smart contracts especiales, conocidos como precompiles, que realizan de forma eficiente tareas específicas como el cálculo de hashes. Con Stylus, los usuarios podrán crear sus propios precompiles.

Prepárate para la EVM+...

👶Regenesis en la testnet zkSync 2.0

Con el objetivo de preparar el Fair Onboarding Alpha, el equipo de Matter Labs a cargo de zkSync 2.0 realizó una regenesis con el fin de restablecer el historial de transacciones y saldo de tokens, lo cual obligará a los teams a volver a desplegar sus contratos. Esta regenesis sólo tendrá impacto en la zkSync 2.0 testnet y no en zkSync 1.0.

La regenesis planea implementar varios cambios importantes, incluyendo:

• Abstracción de cuentas/paymaster

• SDKs

• Contratos L1

💸Optimism distribuyó su airdrop #2

Optimism ha realizado un airdrop de 11,7 M de OP los cuales fueron distribuidos a más de 300 mil direcciones únicas para recompensar la participación en la gobernanza de suma positiva y a los usuarios activos de la Optimism Mainnet.

El airdrop no necesitó ser claimeado, fue automáticamente distribuido a las direcciones elegibles, de acuerdo al artículo publicado los criterios que se usaron para seleccionar a los recompesandos fueron:

🛠Scroll y Polygon zkEVM revelan mejoras en su infraestructura ZK

Scroll ha anunciado a través de su twitter que ha realizado varias mejoras la arquitectura ZK del protocolo logrando reducir los requisitos de memoria del prover de 870 GB a 275 GB, lo que supone una mejora de casi el 68%. El equipo de Scroll ha expresado que logrando que los requisitos del sistema sean lo más bajos posibles permite democratizar la red descentralizada de provers, un paso clave para que las Layer 2 de este tipo no solo puedan brindar un entorno escalable sino que participar en el mantenimiento de la red sea más accesible en pro del liveness y resiliencia.

https://twitter.com/Scroll_ZKP/status/1621573597566468096

Por otro lado, Polygon zkEVM también ha mostrado resultados interesantes sobre sus mejoras asociadas al tiempo de operación, en donde se consiguió un generar una prueba ZK de un batch de 500 transacciones en 2:30 minutos. Con esto, Polygon zkEVM asegura que su tecnología ZK es “la más rápida” y por ende “la primera zkEVM lista para producción”.

https://twitter.com/eduadiez/status/1623723409115938820

Todas estas noticias han demostrado cómo los equipos tras los ZK Rollups en desarrollo han estado consiguiendo avances significativos para hacer realidad lo que antes parecía un sueño casi imposible de realizar. En el mediano plazo veremos cómo más proyectos optimizarán aún más estas propiedades de costes y performance junto a los diseños de infraestructura y participación, que impactarán positivamente en la experiencia final de los usuarios y la seguridad efectiva de la red.

🐱‍🏍Polygon Labs anuncia el lanzamiento de la mainnet beta Polygon zkEVM el 27 de Marzo

Polygon Labs ha anunciado oficialmente el lanzamiento de la mainnet beta de la zkEVM para el 27 de Marzo.

Esta nueva mainnet viene como resultado de un arduo año de trabajo y pruebas realizadas en la versión testnet, Polygon zkEVM ha sido probado en batalla a través del uso real de testnet y también a través de un proceso exhaustivo de auditoría.

Polygon zkEVM se presenta como el estándar para la equivalencia de la EVM, ya que superó el 100 % de los vectores de prueba de Ethereum que se aplican a un zkEVM. Los developers pueden copiar y pegar el código que funciona en Ethereum y usarlo para construir en Polygon zkEVM sin tener que cambiar nada; todas las herramientas de Ethereum funcionan a la perfección con Polygon zkEVM. En pocas palabras, frictionless scaling.

En términos de rendimiento, Polygon zkEVM no se ve afectada por el bien de la equivalencia de EVM. De hecho, cada vez es más barato y rápido de usar. Los tiempos de prueba para un lote de cientos de transacciones se acercan rápidamente a los dos minutos, y se espera un mayor rendimiento en el futuro cercano. Es importante tener en cuenta que los tiempos de prueba dictan la latencia, no la escalabilidad, porque Polygon zkEVM puede generar pruebas en paralelo, lo que permite un alto rendimiento con transacciones que se establecen en L1 en solo unos minutos.

Los costos de prueba para un lote de transacciones similarmente grande se redujeron a alrededor de $0.06 (menos de $ 0.001 para una transferencia simple), lo que convierte a Polygon zkEVM en una forma transparente, segura y asequible de acceder a todo lo que al que le guste Ethereum.

🥁Taiko prepara el escenario para la testnet alpha 2

El Zk-rollup, Taiko, ha anunciado que su testnet Taiko alpha-1 (también llamada Snæfellsjökull) dejará de funcionar el 15 de febrero aproximadamente a las 14:00 UTC. Después de esta fecha, los proposers no podrán proponer bloques, los developers y usuarios no podrán realizar transacciones en la red.

El equipo de Taiko planea enfocar sus esfuerzos en la testnet alpha-2 tras la desaparición de la testnet actual. La versión alpha-2 presenta componentes y participantes importantes que no estaban presentes en la versión anterior. Según el plan, Taiko planea lanzar la testnet alpha-2 aproximadamente un mes después de eliminar la alpha-1.

📳Discusiones interesantes en Twitter y Alphas

📚Sobre la terminología ZK Rollups vs. Validity Rollups

Hace mucho tiempo se ha discutido sobre cuál es el término correcto para nombrar a los rollups asegurados por pruebas de validez. Recientemente uno de los chicos de Bankless levantó este debate afirmando que “ZK no tiene nada que ver” con este tipo de rollups:

https://twitter.com/TrustlessState/status/1622958806169948161

A lo que enseguida destacó el comentario de arnau.eth, miembro del equipo de desarrolladores de Polygon zkEVM respondió que no era preciso del todo:

https://twitter.com/arnau_eth/status/1622992498770472964

Tal y como lo dice el tweet, es importante aclarar que aunque la mayoría de los rollups asegurados por pruebas de validez no implementan privacidad en sus sistemas (a excepción de Aztec), utilizan la base criptográfica zero-knowledge para otros fines. Aunque la implementación de los protocolos de privacidad y escalabilidad son distintos, comparten ciertos o muchos aspectos matemáticos criptográficos en la categoría de zero-knowledge, lo que no invalida una a la otra.

🌿¿Metis implementando ZK?

En otros tweets, la cuenta de Metis reveló públicamente la intención de uso de ZK para su proyecto:

https://twitter.com/MetisDAO/status/1621149839189753859

Aunque el tweet en sí mismo no provee detalles de ello, desde el chat de DeFi LATAM, Jose Fabregas parte del equipo de Metis especificó que se usaría para recortar la ventana de tiempo de retiros en su solución optimista:

Este tipo de intenciones demuestra el potencial de esta tecnología y cómo una solución optimista puede apalancarse de implementaciones del tipo ZK para mejorar la experiencia de usuario e incluso la seguridad de rollup en sí mismo.

🔗Actualizaciones e integraciones

• @Uniswap anunció la integración de Uniswap V3 en @BobaNetwork. Check!

• @Starknet y Chainlink Labs se asocian para acelerar la adopción de Starknet. Check!

• @POKTnetwork ha añadido soporte para la red @arbitrum.Check!

• @aztecnetwork integra a @LiquityProtocol con el objetivo de ofrecer un mejor servicio de borrowing. Check!

• @Unicrowio se ha desplegado con éxito en la red de @arbitrum. Check!

• @SiloFinance ha sido lanzado en @arbitrum. Check!

• @StarkscanCo se integró junto a @Starknet_id con el fin de realizar mejoras para que Starkscan sea una experiencia fluida. Check!

✨Eventos que no te podés perder

⭐Starware Sessions 2023

👷‍♂️Workshop de Developer DAO con Fuel Labs

📌Por último, no olvides leer nuestro último trabajo de investigación hecho por @0xJoxes titulado “Desmascarando la desinformación: ¿Shibarium es una Layer 2?” , el cual busca determinar la verdadera naturaleza de Shibarium.

https://mirror.xyz/layer2es.eth/noJq2MCXm5eXE89suReVRFtRPURRMK8M4ygxDuAF_Fo

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y unete a la conversación en nuestra comunidad de Telegram!

https://t.me/l2espaniol

https://twitter.com/Layer2es