En esta entrada te contamos qué son los bienes públicos, en el marco del lanzamiento de la ronda de quadratic funding de ETH Latam en BA.

Los bienes públicos son aquellos en los que el disfrute del mismo es libre y por lo general están imposibilitados de ser vendidos o tener modelos de negocio privados. Puntualmente tiene dos características claves:

- No tiene rivalidad: si alguien hace uso de un bien, no imposibilita que otro pueda hacer uso del mismo bien.
- No son excluyentes: todos pueden hacer uso del bien, sin discriminación.

***Ejemplos: carreteras y alumbrado público.***

En el contexto del internet -ante la ausencia de bienes materiales en el mundo digital-, los bienes públicos muchas veces están referidos a todo el software open-source e iniciativas de contenido abierto. 
La libertad de acceso, uso y distribución de todas estas herramientas deben estar dadas para la consideración de un bien público digital.

En la comunidad de Ethereum, los bienes públicos en general poseen las siguientes características:

- Contribuyen al ecosistema Ethereum y alrededores (ejemplo Layer 2) cuyos resultados pueden ser utilizados y disfrutados por el colectivo entero o interesado.
- El equipo detrás no tiene la voluntad de generar ganancias o extraer valor para sí por su uso, porque básicamente lo que construye no se puede vender.
- Abarca iniciativas que por su naturaleza no son de interés para ser fondeadas por mecanismos privados.
- Aportan valor sin discriminación.
- Útiles para toda la comunidad.
- No respaldado por VCs o inversores y no suelen responder a intereses privados.

**¿Qué ejemplos hay de bienes públicos?**

- Clientes open-source de Ethereum.
- Áreas de investigación en favor del protocolo de Ethereum y alrededores como el caso de Layer 2.
- Creación de documentación.
- Construcción de comunidad.
- Hubs de información (ejemplo DeFillama).

**¿Y para vos? ¿Qué son los bienes públicos?**


En esta entrada te contamos qué son los bienes públicos, en el marco del lanzamiento de la ronda de quadratic funding de ETH Latam en BA.

large_Group_10503_1d992391f5.png

medium_Group_10503_1d992391f5.png

small_Group_10503_1d992391f5.png

thumbnail_Group_10503_1d992391f5.png

Group_10503_1d992391f5.png

¿Qué son los bienes públicos?

small_photo_2022-01-11_13-13-21.jpg

thumbnail_photo_2022-01-11_13-13-21.jpg

photo_2022-01-11_13-13-21.jpg

Una traducción para la comunidad sobre el protocolo descentralizado de activos sintéticos on-chain.

large_Post_Twitter_3_cc75858417.png

medium_Post_Twitter_3_cc75858417.png

small_Post_Twitter_3_cc75858417.png

thumbnail_Post_Twitter_3_cc75858417.png

Post_Twitter_3_cc75858417.png

Synthetix Litepaper en español

thumbnail_photo_2022-07-25_13-09-02.jpg

photo_2022-07-25_13-09-02.jpg

Una introducción concreta al ecosistema y el funcionamiento de sus componentes

large_asd.png

medium_asd.png

small_asd.png

thumbnail_asd.png

asd.png

Adentrándonos en el Cosmos

small_photo_2021-12-24_17-24-43.jpg

thumbnail_photo_2021-12-24_17-24-43.jpg

photo_2021-12-24_17-24-43.jpg

Fundamentos, usos, contratos inteligentes y estado actual de todo lo referente a los Validity Rollups.

large_Post Twitter.png

medium_Post Twitter.png

small_Post Twitter.png

thumbnail_Post Twitter.png

Post Twitter.png

Estado de la escalabilidad en Ethereum - ZK Rollups

small_photo_2020-04-07_21-14-22.jpg

thumbnail_photo_2020-04-07_21-14-22.jpg

photo_2020-04-07_21-14-22.jpg

*En este artículo vamos a introducirnos en uno de los tipos de rollups (solución de escalabilidad de Capa 2) que se está desarrollando actualmente en el mercado: zkSync*

*Pero, antes de comenzar a hablar de zkSync vamos a repasar algunos conceptos importantes.*

### Rollups

Los rollups son soluciones de escalabilidad de capa 2 o L2 que realizan operaciones de transacción (ejecución) fuera de la blockchain principal de Ethereum (off-chain), pero aún así, publican los datos de la transacción en la capa 1 o L1 (Ethereum). Teniendo en cuenta que los datos de la transacción están en la L1, los rollups están *protegidos* por la misma seguridad de la capa 1. De hecho, esta es la característica más importante que los rollups ofrecen a los usuarios.

Los rollups son útiles porque reducen el gas fee, aumentan el rendimiento de las transacciones y amplían la participación. En general, un rollup implementa un conjunto de contratos inteligentes en la blockchain subyacente que son responsables de procesar los depósitos y retiros y verificar que las transacciones sean válidas.

Existen 2 tipos de rollups: **Optimistic Rollups y ZK Rollups**

### Optimistic Rollups

Los Optimistic Rollups asumen que las transacciones son válidas de forma predeterminada "optimistas" y solo ejecutan el cálculo a través de una **fraud proof** (prueba de fraude), lo que significa que solo presenta evidencia de que una transición de estado fue incorrecta, en el acto en que alguien decide cuestionar la transacción.\
Se ubican en paralelo a Ethereum Mainnet en la capa 2 y no realizan ningún cálculo (ecuaciones matemáticas) de forma predeterminada. Una vez que se completan las transacciones, envían el nuevo estado a la L1, notarizando la transacción.

Las transacciones optimisticas se escriben en la blockchain de Ethereum, lo que optimiza aún más las transacciones al reducir el costo del gas.

Optimistic Rollup funcionando en producción:

-   [Optimism](https://defillama.com/chain/Optimism) desarrollado por la organización [OP Labs PBC](https://www.optimism.io/)
-   [Arbitrum](https://defillama.com/chain/Arbitrum) desarrollado por la empresa [OFFCHAIN Labs](https://offchainlabs.com/careers/)


![Optimistic Rollups.webp](/uploads/Optimistic_Rollups_f7d1102818.webp)


### ZK Rollups

Los Zero-Knowledge Rollups (ZK Rollups) o rollups de cero conocimiento agrupan cientos de transacciones off-chain y generan una prueba criptográfica. Estas pruebas pueden venir en forma de SNARK (argumento de conocimiento sucinto no interactivo) o STARK (argumento de conocimiento transparente escalable). Los SNARK y STARK se conocen como **validity proofs** (pruebas de validez) y se publican en la L1.

El contrato inteligente ZK Rollup mantiene el estado de todas las transacciones en la L2, y este estado solo se puede actualizar con una prueba de validez. Esto significa que los ZK Rollups solo necesitan la prueba de validez en lugar de todos los datos de la transacción. Con ZK Rollup, validar un bloque es más rápido y económico porque se incluyen menos datos.

ZK Rollups en desarrollo y en producción:

-   [StarkEX](https://starkware.co/starkex/) y [StarkNet](https://l2beat.com/projects/starknet/) desarrollados por la empresa [StarkWare](https://starkware.co/)
-   [zkSync 1.0](https://l2beat.com/projects/zksync/) y [zkSync2.0](https://portal.zksync.io/) (testnet) desarrollado por la organización [MatterLabs](https://matter-labs.io/)

![Zk Rollups.webp](/uploads/Zk_Rollups_dbb2e80a27.webp)


*Estos conceptos sirvieron de repaso, ahora vamos a desarrollar en profundidad en **zkSync**.  ¿Todavía surgen dudas o preguntas sobre las soluciones de escalabilidad L2?  recomendamos este articulo de*  [0xJoxes](https://twitter.com/0xJoxes) ["Preguntas frecuentes sobre L2 de Ethereum, Parte 1"](https://mirror.xyz/joxes.eth/LAoeGglTQSLXMV86iDR9MeyqzO39rAXV7bgy19R5gGo)

Comencemos
----------

### ¿Qué es Matter Labs?

Matter Labs es la organización detrás del desarrollo de zkSync. Pionero en la tecnología de prueba de conocimiento cero (zero-knowledge proof) en Ethereum. La compañía lanzó el primer prototipo de ZK Rollup público a principios de 2019, fue la primera en implementar pruebas ZK recursivas en Ethereum y creó el primer hardware práctico basado en FPGA para la aceleración de ZKP en 2020. Matter Labs lanzó una red de prueba zkEVM, lo que convierte a zkSync en el primer ZK Rollup capaz de ejecutar contratos inteligentes nativos de Ethereum.

zkSync 1.0
----------

zkSync es un protocolo L2 basado en la tecnologia ZK Rollup. ZK rollup es una variante de una familia más amplia de "rollups", explicado anteriormente.

### ¿Cómo funciona?

Los fondos se mantienen mediante un contrato inteligente en la cadena principal, mientras que el cálculo y el almacenamiento se realizan off-chain. La idea principal es que en lugar de verificar cada transacción por separado, las transacciones se "agrupan" o "rolled up" en un solo elemento (bloque rollup), que luego se verifica, aprobándolos todos simultáneamente.

En un nivel alto, funciona de la siguiente manera:

1.  Los usuarios firman transacciones y las envían a los validadores.
2.  Los "sequencers" o secuenciadores (validadores) acumulan miles de transacciones en un solo bloque y envían un submit criptográfico (el root hash) del nuevo estado al contrato inteligente en la red principal junto con una prueba "proof" criptográfica (un SNARK) de que este nuevo estado es efectivamente el resultado de la aplicación de algunas transacciones correctas al estado anterior.
3.  Además de la prueba, el estado (una pequeña cantidad de datos para cada transacción) se publica en la red principal como *"calldata"*. Esto permite que cualquiera pueda reconstruir el estado en cualquier momento.
4.  La prueba y el estado  son verificados por el contrato inteligente, verificando así tanto la validez de todas las transacciones incluidas en el bloque como la disponibilidad de datos del bloque.

La verificación SNARK es mucho más económica que verificar cada transacción individualmente, y almacenar el estado fuera de la cadena es significativamente más económico que almacenarlo en EVM. Por lo tanto, permite un gran impulso de escalabilidad (~100-200x capacidad de la red principal) y ahorros en costos de tx.

La arquitectura zkSync tiene las siguientes ventajas:

-   Los secuenciadores no pueden corromper el estado o robar fondos (a diferencia de las sidechains).
-   Los usuarios siempre pueden recuperar los fondos del contrato inteligente zkSync incluso si los secuenciadores dejan de cooperar, porque los datos están disponibles (a diferencia de Plasma).
-   No es necesario un tercero para monitorear los bloques ZK Rollup con el fin de prevenir el fraude (a diferencia de los sistemas de prueba de fraude, como los Optimistic Rollups).

En otras palabras, zkSync hereda las garantías de seguridad de la L1 subyacente.

### Rendimiento

zkSync puede procesar 2000 TPS, esto es debido al gas limit del bloque en Ethereum (12,5M gwei) ya que zkSync necesita publicar los cambios de estados de cada transacción en Ethereum para garantizar la disponibilidad de datos.

### Tiempo de finalidad de la transacción

Las transacciones en zkSync alcanzan la finalidad en Ethereum una vez que el contrato inteligente genera y acepta la prueba SNARK del bloque zkSync. El tiempo de generación de la prueba es de unos 10 minutos, es decir, 10 minutos después del envío, la transacción zkSync (proof) es tan definitiva como cualquier transacción en L1 incluida en el mismo bloque de Ethereum que la transacción con la prueba. Cuando un usuario envía una transacción, se espera que se llene el bloque, por lo que no genera la prueba de inmediato. Con un mayor rendimiento (volumen de operación) en el sistema zkSync, el tiempo entre bloques disminuirá.

**Confirmaciones Instantáneas**

El tiempo de finalización de 10 minutos, no afecta la usabilidad de la red. Las transacciones enviadas a zkSync se confirman instantáneamente, se muestran a la parte receptora en la interfaz de usuario y la API (aunque se marcan como no confirmadas), y los activos transferidos se pueden usar de inmediato para realizar más transferencias (que incluso podrían terminar en el mismo bloque zkSync).

Las confirmaciones instantáneas son "promesas" de los validadores zkSync para incluir la transacción en el siguiente bloque. Los usuarios que "no confíen" en los validadores deben esperar la finalización completa antes de considerar los activos como recibidos.

A futuro, los validadores agregarán un bono de seguridad "staking" a zkSync. Esto proporcionará garantías instantáneas de finalidad económica. Los secuenciadores corruptos serán slasheados y perderán parte del staking.

### Fees

En zkSync el costo de cada transacción tiene dos componentes:

-   Parte Off-chain (storage + prover) : el costo del almacenamiento del estado y la generación del SNARK (zero-knowledge proof). Esta parte depende del uso de los recursos de hardware. Costo estimado  ~0,001 USD por transacción.
-   Parte On-chain (gas): por cada bloque zkSync, el validador debe pagar gas en Ethereum para verificar el SNARK, además de ~0.4k gas por transacción para publicar el estado. La parte on-chain es una variable que depende del precio actual del gas en la red.

**Las transferencias en zkSync admiten "gasless meta-transaction": los usuarios pagan fees de transacción en los tokens que se transfieren. Por lo tanto, si la transferencia es en DAI, no es necesario ETH. Solo se paga el fee en una fracción de DAI.**

### ¿zkSync es descentralizada?

El validador zkSync no tiene poder sobre los activos de los usuario sin autorización explícita. Los usuarios siempre pueden retirar todos los fondos a la red principal sin la cooperación del validador (incluso si este último está completamente cerrado y no responde).

Sin embargo, por el momento, la operación diaria de la red zkSync depende de la confianza depositada en el proveedor de servicios computacionales que genera *zero-knowledge proofs* para los bloques.

Actualmente, el proveedor para la red zkSync es "Stichting ZK Sync", una fundación holandesa sin fines de lucro.

En un futuro el protocolo se irá descentralizando cada vez más, introduciendo un mecanismo de consenso independiente para la construcción de bloques con dos roles diferentes: Validadores y Guardianes.

Cuando zkSync se descentralice por completo, se utilizará un token para hacer staking para ser validador en la red zkSync.

***Nota:*** *La seguridad de zkSync no se verá afectada por la introducción de un mecanismo de consenso adicional, ya que la verificación final de las pruebas de transición de estado aún se realizará mediante un contrato inteligente en la red principal de Ethereum.*

zkSync 2.0
----------

En zkSync 1.0  es un ZK Rollup disponible para pagos, transferencia de tokens y NFT.\
zkSync 2.0 es un ZK Rollup compatible con la EVM, o sea se pueden implementar contratos inteligentes en un entorno similar a la EVM llamado zkEVM.

Actualmente se encuentra en testnet en la red [Georli](https://portal.zksync.io/).

### ¿Qué es zkEVM?

zkEVM es una máquina virtual que ejecuta contratos inteligentes de una manera compatible con *zero-knowledge-proof*. Es la clave para construir un ZK Rollup compatible con EVM, mantiene la semántica de EVM, pero también es compatible con ZK y adopta arquitecturas de CPU tradicionales.

### zkPorter

En zkSync 2.0, el estado L2 se dividirá en 2: ZK Rollup con Data Availability (disponibilidad de datos) on-chain y zkPorter con disponibilidad de datos off-chain. A través de la combinación de un zk-rollup y un [validium](https://ethereum.org/en/developers/docs/scaling/validium/) (zk-rollup híbrido donde los datos de la transacción se publican off-chain), los *[volition](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb)* son un híbrido que brinda a los usuarios la opción de disponibilidad de datos on-chain o off-chain

Ambas partes serán componibles e interoperables: los contratos y las address del lado de ZK Rollup podrán interactuar sin problemas con las address del lado de zkPorter, y viceversa. La elección se realiza a nivel de transacción individual, donde los datos off-chain representan tarifas más económicas y menor seguridad, mientras que los datos on-chain generan tarifas más altas y más seguridad.

![scalability.webp](/uploads/scalability_621184e0a4.webp)


zkPorter pone la data availability (datos de transacción esenciales necesarios para reconstruir el estado) off-chain en lugar de en Ethereum. En cambio, la disponibilidad de los datos se asegura mediante la prueba de participación (PoS) por parte de los stakers del token zkSync. Esto permite una escalabilidad mucho mayor (decenas de miles de TPS) y, como resultado, tarifas de transacción ultra bajas comparables con otras blockchains (en el rango de unos pocos centavos)**.**

La data availability de las cuentas de zkPorter estará asegurada por los holders del token zkSync, denominados "Guardians" (guardianes). Realizarán un seguimiento del estado en el lado de zkPorter mediante la firma de bloques para confirmar la disponibilidad de datos de las cuentas de zkPorter. Los guardianes participan en proof of stake (PoS) con el token zkSync, por lo que cualquier falla en la disponibilidad de datos hará que se reduzcan drásticamente su participación. Esto da garantías criptoeconómicas sobre la data availability.

![zkSync.webp](/uploads/zk_Sync_ffaf2c3c52.webp)


Es importante tener en cuenta que PoS en zkSync es significativamente más seguro que PoS en cualquier otra sidechain. Esto se debe a que los guardianes de zkSync son esencialmente impotentes: los guardianes no pueden robar fondos. Solo pueden congelar el estado zkPorter o sea congelar su propia participación (stake).

En Resumen
----------

La carrera de desarrollo por escalar Ethereum se está acelerando y zkSync es uno de los principales corredores.

ZkSync permite transaccionar de forma rápida, económica y segura heredada de Ethereum usando ZK Rollups.\
ZkPorter permite aumentar la cantidad TPS con Data Availability off-chain (todavía no disponible, en desarrollo).\
zkEVM el primer ZK Rollup compatible con la EVM de Ethereum va a permitir implementar contratos inteligentes en zkSync, si bien todavía está en testnet, es un gran avance para que se desarrolle todo un ecosistema.

¿Y el token? zkSync anunció que va a lanzar un token propio para staking, pero no hay fecha oficial. Por ahora el equipo está enfocado en la escalabilidad de Ethereum.

Para estar al día con las novedades de zkSync es importante seguir sus redes sociales

[zkSync Discord Server](https://discord.com/invite/px2aR7w)
[Telegram Community zkSync](https://t.me/zksync_community)
[Telegram Support zkSync](https://t.me/zksync_support)
[Twitter @zksync](https://t.co/CyQ3XqZfPw)

Actualidad de diferentes desarrollos de escalabilidad podes unirte a la comunidad de L2 en Español.
Fuentes

    https://docs.zksync.io/userdocs/.
    https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf.
    https://medium.com/starkware/validity-proofs-vs-fraud-proofs-4ef8b4d3d87a.
    https://mirror.xyz/joxes.eth/LAoeGglTQSLXMV86iDR9MeyqzO39rAXV7bgy19R5gG.o.
    https://ethereum.org/en/developers/docs/scaling/zk-rollups/.
    https://www.one37pm.com/nft/what-are-ethereum-rollups.
    https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/.


Los rollups son soluciones de escalabilidad de capa 2 o L2 que realizan operaciones de transacción (ejecución) fuera de la blockchain principal de Ethereum (off-chain), pero aún así, publican los

large_zk rollups.jpg

medium_zk rollups.jpg

small_zk rollups.jpg

thumbnail_zk rollups.jpg

zk rollups.jpg

ZK Rollups: zkSync

thumbnail_L7Qvuyq2_400x400.jpg

L7Qvuyq2_400x400.jpg

La gobernanza de Optimism está empezando a dar sus primeros pasos, y desde DeFi LATAM queremos trabajar con nuestras comunidades para coordinar una representación latinoamericana, abierta y colaborativa.  Invitamos a tomar parte a todos aquellos apasionados por el futuro de la Web3 y la escalabilidad de Ethereum, desde la perspectiva de nuestra región, DeFi LATAM y otras comunidades.

**¿Por qué Optimism?**

El ethos de DeFi LATAM está alineado a los valores que promueve Optimism en "*[The Optimism Vision](https://www.optimism.io/vision)*".

*Lo siguiente es una traducción del comunicado, por [AxlVaz](https://twitter.com/Axlvaz).*

# La Visión de Optimism

Web3 ha abierto la puerta a una nueva potencial realidad: un ciberespacio no solo ocupado sino gobernado por sus ciudadanos. Se nos presenta la oportunidad de reinventar la forma en que nos organizamos en esta era digital.

Es fundamental que aprovechemos la ocasión. El ciberespacio hoy sufre de una falla monumental del mercado porque ha heredado un conjunto de reglas económicas construidas para el mundo físico. Sin embargo, a diferencia del viejo mundo de carne y acero, el ciberespacio se construye sobre información, un sustrato que se puede replicar libremente. Esto significa que los bienes públicos son mucho más importantes para el crecimiento del ciberespacio, pero nuestros mercados están mal equipados para nutrir ese crecimiento. Nos frena la incapacidad para recompensar a los creadores de estos bienes públicos, que generan gran impacto.

**Optimism Collective** es un nuevo modelo de gobernanza democrática digital optimizado para impulsar el crecimiento rápido y sostenible de un ecosistema descentralizado. El Colectivo es un conjunto de comunidades, empresas y ciudadanos unidos por un pacto de beneficio mutuo para adherirse al axioma de impacto = beneficio, con principio de que el impacto positivo para el colectivo debe ser recompensado con beneficio para el individuo. Este axioma sirve como norte, motivando la creación de una economía más productiva y empática.

**Optimism Collective** disipará el mito de que los bienes públicos no deben ser rentables. El Colectivo proporcionará constantemente grandes incentivos [retroactivos](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) para bienes públicos que beneficien a Optimism, Ethereum y al Colectivo en su conjunto. Estos bienes públicos actúan como propulsores del crecimiento de la economía colectiva. Crecimiento que genera ganancias para el Colectivo y ganancias que financian más inversiones en bienes públicos, todo junto produce un círculo virtuoso de expansión impulsada por el impacto.

Esperamos que a medida que crece el Colectivo, el alcance de lo que cae bajo el ala de los bienes públicos colectivos crecerá junto con él. Imaginamos un futuro en el que el Colectivo se expande más allá del ámbito digital y hacia el mundo físico. La idea de que un ecosistema descentralizado podría satisfacer de manera confiable las necesidades humanas básicas a escala puede parecer idealista hoy, pero mañana será un lugar común. Empezamos poco a poco por un sentido de pragmatismo, pero apuntamos a lo grande por un abrumador sentido de optimismo.

Juntos, crearemos el futuro del ciberespacio coordinado y colaborativo.

## En Concreto:

*Está no va a ser la única oportunidad donde la comunidad de DeFi LATAM tenga una participación activa en una gobernanza. DeFi LATAM estará presente en aquellos foros que mantengan e impulsen los valores de la descentralización. Animamos a la comunidad a sumarse activamente en esta y otras futuras iniciativas.*

Si estás interesado en participar y colaborar activamente, como individuo o comunidad para fomentar la representatividad de Latam a una de las gobernanzas más importantes del ecosistema cripto, podes unirte a nuestro canal de Discord:

[comunidad.defilatam.com](comunidad.defilatam.com)

**También te dejamos la presentación en el foro de la gobernanza de Optimism:**

[https://gov.optimism.io/t/delegate-commitments/235/27](https://gov.optimism.io/t/delegate-commitments/235/27)


Para delegar votos a DeFi LATAM aquí:

[https://www.tally.xyz/voter/profile/YLV391](https://www.tally.xyz/voter/profile/YLV391)


***"Somos optimistas. No nos parece muy útil ser otra cosa."***

La comunidad DeFi LATAM apunta a tener un rol participativo en la gobernanza de Optimism.

medium_Diseño sin título (44).png

small_Diseño sin título (44).png

thumbnail_Diseño sin título (44).png

Diseño sin título (44).png

Somos Optimistas

¿Vas a hacer un swap? No sin antes entender qué son y como funcionan los DEX aggregators.

medium_artículo joxes (854 × 480 px).jpg

small_artículo joxes (854 × 480 px).jpg

thumbnail_artículo joxes (854 × 480 px).jpg

artículo joxes (854 × 480 px).jpg

DEX Aggregators: una pieza clave en el ecosistema DeFi

Escrito por [@espejelomar](https://twitter.com/espejelomar). Mándame un DM y aprenderemos juntos ?. Antes de comenzar, te recomiendo que prepares tu equipo para programar en Cairo ❤️ con el [tutorial pasado](https://mirror.xyz/espejel.eth/9YzsiK9R06GeMJjPDZaSAoYMdSi2Kp6Tk3SW1VScE5Q).

? El futuro de Ethereum es hoy y ya está aquí. Vamos a aprender a usar un ecosistema:

-   Sostiene a [dYdX](https://dydx.exchange/), DeFi que ya hizo cuatrocientos billones de trades y representa alrededor de un cuarto del total de las transacciones hechas en ethereum. Funcionan apenas desde hace 18 meses y constantemente [vencen a Coinbase](https://www.coinspeaker.com/dydx-coinbase-trade-volume/) en volumen de trades. Redujeron el precio de las transacciones de 500 a 1,000 veces. Son tan baratas que no necesitan cobrar el gas a los usuarios ?.
-   En la la semana del 7 al 13 de marzo de 2022, por primera vez, logró tener 33% más transacciones que Ethereum ?.

Y apenas es el comienzo. Aprende un poco más sobre el ecosistema de Starkware en [este texto corto](https://mirror.xyz/espejel.eth/PlDDEHJpp3Y0UhWVvGAnkk4JsBbJ8jr1oopGZFaRilI). Únete al [mayor Meetup](https://www.meetup.com/fr-FR/starknet_latam/) de habla hispana sobre StarkNet. Saluda en el el canal `#?-español` en el [Discord](https://discord.gg/uJ9HZTUk2Y) de StarkNet.

___

1\. Sumar dos números
--------------

Para aprender los básicos de Cairo crearemos juntos una función para sumar dos números ?. El código es muy sencillo pero nos ayudará a entender mejor muchos conceptos de Cairo. Nos basaremos fuertemente en la [documentación de Cairo](https://www.cairo-lang.org/docs/). La documentación es excelente al día de hoy no está lista para fungir como un tutorial estructurado para principiantes. Aquí buscamos solucionar esto ?.

Aquí está nuestra código para sumar dos números. Puedes pegarlo directamente en tu editor de código o IDE. En mi caso estoy usando VSCode con la extensión de Cairo.

No te preocupes si no entiendes en este punto todo lo que está sucediendo. Pero [@espejelomar](https://twitter.com/espejelomar) se preocupará si al final del tutorial no comprendes cada línea de este código. Avísame si es así porque mejoraremos ?. Cairo es un lenguaje low-level por lo que será más díficil que aprender Python, por ejemplo. Pero valdrá la pena ?. Ojos en la meta.

Veamos línea por línea y con ejemplos adicionales lo que estamos haciendo.

```
%builtins output

from starkware.cairo.common.serialize import serialize_word

func suma_dos_nums(num1: felt, num2: felt) -> (sum):
    alloc_locals
    local sum = num1+num2
    return(sum)
end

func main{output_ptr: felt*}():
    alloc_locals

    const NUM1 = 1
    const NUM2 = 10

    let (sum) = suma_dos_nums(num1 = NUM1, num2 = NUM2)
    serialize_word(sum)
    return ()
end

```

2\. Los builtins
--------------

Al comienzo de nuestro programa en Cairo escribimos `%builtins output`. Aquí estamos diciendo al compilador de Cairo que usaremos el `builtin` llamado `output`. La definición de `builtin` es bastante técnica y sale del alcance de este primer tutorial ([aquí esta](https://www.cairo-lang.org/docs/how_cairo_works/builtins.html#builtins) en la documentación). Por el momento, nos basta indicar que podemos convocar capacidades especiales de Cairo a través de los builtins. Si sabes C++ seguramente ya encontraste las similitudes.

> El `builtin` `output` es lo que permite que el programa se comunique con el mundo exterior. Puedes considerarlo como el equivalente de `print()` en Python o `std::cout` de C++ ([documentación](https://www.cairo-lang.org/docs/hello_cairo/intro.html#writing-a-main-function) de Cairo).

La interacción entre `builtin` `output` y la función `serialize_word`, que importamos previamente, nos permitirá imprimir a la consola. En este caso con `serialize_word(sum)`. No te preocupes, más adelante lo veremos más de cerca.

3\. Importando
--------------

Cairo está contruido arriba de Python por lo que importar funciones y variables es exactamente igual. La línea `from starkware.cairo.common.serialize import serialize_word` está importando la función `serialize_word` que se encuentra en `starkware.cairo.common.serialize`. Para ver el código fuente de esta función basta con ir al repositorio en Github de `cairo-lang` ([link](https://github.com/starkware-libs/cairo-lang)). Por ejemplo, la función serialize se encuentra [aquí](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/cairo/common/serialize.cairo) dentro del repositorio. Esto te será útil para encontrar errores en el código o comprender más a fondo Cairo.

> Varias funciones de la misma biblioteca se pueden separar con comas. Las funciones de diferentes bibliotecas se importan en diferentes líneas. Cairo busca cada módulo en una ruta de directorio predeterminada y en cualquier ruta adicional especificada en el momento de la compilación ([documentación](https://www.cairo-lang.org/docs/reference/syntax.html#library-imports) de Cairo).

Así se importan varias funciones de una misma biblioteca: `from starkware.cairo.common.math import (assert_not_zero, assert_not_equal)`.

4\. Los field elements (felt)
-----------------------------

> The felt is pretty much the only data type that exists in Cairo, you can even omit it [its explicit statement] sometimes ([StarkNet Bootcamp - Amsterdam - min 1:14:36](https://www.youtube.com/watch?v=O2zntD0muZs&t=3077s)).

En Cairo cuando no se específica el type de una variable o argumento se le asigna automáticamente el tipo `felt`. En la [documentación de Cairo](https://www.cairo-lang.org/docs/hello_cairo/intro.html#the-primitive-type-field-element-felt) se entra en detalles técnicos sobre lo que es un `felt`. Para fines de este tutorial basta con decir que un `felt` funciona como un entero. En las divisiones podemos notar la diferencia entre los `felt` y los enteros. Sin embargo, citando la documentación:

> En la mayor parte de tu código (a menos que tengas la intención de escribir un código muy algebraico), no tendrás que lidiar con el hecho de que los valores en Cairo son felts y podrá tratarlos como si fueran números enteros normales.

5\. Los struct (los diccionarios de Cairo?)
-------------------------------------------

Además de los `felt`, tenemos otras estructuras a nuestra disposición (más detalles en la [documentación](https://www.cairo-lang.org/docs/reference/syntax.html#type-system)).

Podemos crear nuestra propia estructura, estilo diccionario de Python:

```
struct MiStruct:
    member primer_miembro : felt
    member segundo_miembro : felt
end

```

Así definimos un nuevo tipo de datos llamado `MiStruct` con las propiedades `primer_miembro` y `segundo_miembro`. Definimos que el `type` de ambas propiedades sea `felt` pero bien pudimos colocar otros types. Cuando creamos una `struct` es obligatorio agregar el `type`.

Podemos crear una variable de tipo `MiStruct`: `Nombre = (primer_miembro=1, segundo_miembro=4)`. Ahora la variable `Nombre` tiene `type` `MiStruct`.

Con `Nombre.primer_miembro` podemos acceder al valor de este argumento, en este caso es 1.

6\. Las tuplas (tuples, en inglés)
----------------------------------

Las tuplas en Cairo son prácticamente iguales a las tuplas en Python:

> Una tupla es una lista finita, ordenada e inalterable de elementos. Se representa como una lista de elementos separados por comas encerrados entre paréntesis (por ejemplo, `(3, x)`). Sus elementos pueden ser de cualquier combinación de tipos válidos. Una tupla que contiene solo un elemento debe definirse de una de las dos formas siguientes: el elemento es una tupla con nombre o tiene una coma final. Cuando se pasa una tupla como argumento, el tipo de cada elemento se puede especificar por elemento (por ejemplo, `my_tuple : (felt, felt, MyStruct)`). Se puede acceder a los valores de tupla con un índice basado en cero entre paréntesis `[index]`, incluido el acceso a elementos de tupla anidados como se muestra a continuación ([documentación](https://www.cairo-lang.org/docs/reference/syntax.html#tuples) de Cairo).

La documentación de Cairo es muy clara en su definición de las tuplas. Aquí su ejemplo:

```
# Una tupla con tres elementos
local tuple0 : (felt, felt, felt) = (7, 9, 13)
local tuple1 : (felt) = (5,)  # (5) is not a valid tuple.

# Una tupla con nombre no requiere una coma final
local tuple2 : (a : felt) = (a=5)

# Tupla que contiene otra tupla.
local tuple3 : (felt, (felt, felt, felt), felt) = (1, tuple0, 5)
local tuple4 : ((felt, (felt, felt, felt), felt), felt, felt) = (
    tuple3, 2, 11)
let a = tuple0[2]  # let a = 13.
let b = tuple4[0][1][2]  # let b = 13.

```

7\. La estructura de las funciones y comentarios
------------------------------------------------

La definición de una función en Cairo tiene el siguiente formato:

```
func función(arg1: felt, arg2) -> (retornado):
  # Cuerpo de la función
  return(retornado)
end

```

-   Definir el scope de la función (alcance, en español). Comenzamos la función con `func` y la terminamos con `end`. Esto define el scope de nuestra función llamada `función`.
-   Argumentos y nombre. Definimos los argumentos que recibe la función entre paréntesis a un lado del nombre que definimos para nuestra función, `función` en este caso. Los argumentos pueden llevar su type (tipo, en español) definido o no. En este caso `arg1` debe ser de type `felt` y `arg2` puede ser de cualquier type.
-   Retornar. Necesariamente tenemos que agregar `return()`. Aunque la función no esté regresando algo. En este caso estamos retornando una variable llamada `retornado` por lo que colocamos `return(retornado)`. Aún si no retornaramos nada tendríamos que agregar `return()`.
-   Comentarios. En Cairo comentamos con `#`. Este código no será interpretado al correr nuestro programa.

Como con otros lenguajes de programación. Necesitaremos una función `main()` que orqueste el uso de nuestro programa en Cairo. Se define exactamente igual a una función normal solo que con el nombre `main()`. Puede ir antes o después de las demás funciones que creamos en nuestro programa.

8\. Interactuando con pointers (punteros, en español): parte 1
--------------------------------------------------------------

> Se utiliza un pointer para indicar la dirección del primer `felt` de un elemento en la memoria. El pointer se puede utilizar para acceder al elemento de manera eficiente. Por ejemplo, una función puede aceptar un puntero como argumento y luego acceder al elemento en la dirección del puntero ([documentación](https://www.cairo-lang.org/docs/reference/syntax.html#pointers) de Cairo).

Supongamos que tenemos una variable de nombre `var`:

-   `var*` es un pointer a la dirección en memoria del objeto `var`.
-   `[var]` es el valor guardado en la dirección `var*`.
-   `&var` es la dirección al objeto `var`.
-   `&[x]` es `x`. Puedes ver que `x` es una dirección?

9\. Argumentos ímplicitos
-------------------------

Antes de explicar cómo funcionan los argumentos ímplicitos, una regla: Si una función `foo()` llama a una función con un argumento ímplicito, `foo()` también debe obtener y devolver el mismo argumento ímplicito.

Dicho esto, veamos cómo se ve una función con un argumento ímplicito. La función es serialize_word que se encuentra disponible en la biblioteca `starkware.cairo.common.serialize` y la utilizamos en nuestra función inicial para sumar dos números.

```
%builtins output

func serialize_word{output_ptr : felt*}(word : felt):
    assert [output_ptr] = value
    let output_ptr = output_ptr + 1
    # El nuevo valor de output_ptr es implícitamente
    # añadido en return.
    return ()
end

```

Esto será un poco confuso, prepárate. Intentaré de hacer todo muy claro ?. Para que una función reciba argumentos ímplicitos colocamos entre `{}` el argumento. En este y muchos otros casos se recibe `output_ptr` que es un pointer a un type felt. Cuando declaramos que una función recibe un argumento ímplicito, la función automáticamente retornará el valor del argumento ímplicito al terminar la función. Si no movieramos el valor del argumento ímplicito entonces retornaría automáticamente el mismo valor con el que inició. Sin embargo, si durante la función el valor del argumento ímplicito es alterado entonces se retornará automáticamente el nuevo valor.

En el ejemplo con la función `serialize_word` definimos que vamos a recibir un argumento ímplicito llamado `output_ptr`. Además, también recibimos un argumento explícito llamado `value`. Al finalizar la función vamos a retornar el valor que tenga `output_ptr` en ese momento. Durante la función vemos que `output_ptr` aumenta en 1: `let output_ptr = output_ptr + 1`. Entonces la función retornará implícitamente el nuevo valor de `output_ptr`.

Siguiendo la regla definida al comienzo, cualquier función que llame a `serialize_word` tendrá que también recibir el argumento ímplicito `output_ptr`. Por ejemplo, una parte de nuestra función para sumar dos números va así:

```
func main{output_ptr: felt*}():
    alloc_locals

    const NUM1 = 1
    const NUM2 = 10

    let (sum) = sum_two_numbers(num1 = NUM1, num2 = NUM2)
    serialize_word(word=sum)
    return ()
end

```

Vemos que llamamos a `serialize_word` por lo que necesariamente tenemos que también pedir el argumento ímplicito `output_ptr` en nuestra función `main`. Aquí entra en acción otra propiedad de los argumentos ímplicitos, y quizás la razón por la que se llaman así. Vemos que al llamar a `serialize_word` solo pasamos el argumento explícito `word`. El argumento ímplicito `output_ptr` se pasa autómaticamente ?! Ojo, también pudimos haber hecho explícito el argumento ímplicito así: `serialize_word{output_ptr=output_ptr}(word=a)`. Ya sabemos programar en Cairo? ?

Entonces, el argumento ímplicito es ímplicito porque:

1.  Dentro de la función ímplicita, automáticamente se retorna el valor final del argumento ímplicito.
2.  Cuando se llama a la función ímplicita, no necesitamos indicar que vamos a ingresar el argumento ímplicito. Automáticamente se incluye el valor ímplicito.

10\. Locals (locales, en español)
---------------------------------

Estamos casi listos para comprender al 100 lo que hicimos en nuestra función que suma dos números. Lo sé, ha sido un camino piedroso ?. Pero hay un arcoíris al final del tutorial ?.

Así definimos una variable local: `local a = 3`.

> Cualquier función que use una variable local debe tener la declaración `alloc_locals`, generalmente al comienzo de la función. Esta declaración es responsable de asignar las celdas de memoria utilizadas por las variables locales dentro del scope de la función ([documentación](https://www.cairo-lang.org/docs/reference/syntax.html#locals) de Cairo).

Como ejemplo, mira esta parte de nuestra función que suma dos números:

```
func sum_two_numbers(num1: felt, num2: felt) -> (sum):
    alloc_locals
    local sum = num1+num2
    return(sum)
end

```

Es muy sencillo ?.

Como no queremos que sea tan fácil, hablemos de memoria. Cairo guarda la variables locales en relación al frame pointer (`fp`) (en un siguiente tutorial entraremos en detalles sobre el `fp`). Por lo que si necesitaramos la dirección de una variable local no bastaría con `&sum` pues nos daría este error: `using the value fp directly requires defining a variable __fp__`. Podemos obtener este valor importando `from starkware.cairo.common.registers import get_fp_and_pc`. `get_fp_and_pc` nos regresa una tupla con los valores actuales de `fp` y `pc`. Al más estilo Python indicaremos que solo nos interesa el valor de `fp` y que lo guardaremos en una variable `__fp__`: `let (__fp__, _) = get_fp_and_pc()`. Listo ahora sí podríamos utilizar `&sum`. En otro tutorial veremos un ejemplo de esto.

11\. Constants (constantes, en español)
---------------------------------------

Muy simples. Solo recuerda que deben dar un entero (un field) cuando compilemos nuestro código. Crea una constant:

```
const NUM1 = 1

```

12\. References (referencias, en español)
-----------------------------------------

Este es el formato para definir una:

```
let ref_nombre : ref_type = ref_expr

```

Donde `ref_type` es un type y `ref_expr` es una expresión de Cairo. Colocar la `ref_type` es opcional pero es recomedable hacerlo.

Una referencia se puede reasignar ([documentación](https://www.cairo-lang.org/docs/reference/syntax.html#references) de Cairo):

```
let a = 7  # a está inicialmente ligada a la expresión 7.
let a = 8  # a ahora está ligada a la expresión 8.

```

En nuestra suma de dos números creamos una referencia llamada `sum`. Vemos que asignamos a `sum` el `felt` que nos retorna la funcion `suma_dos_nums`.

```
let (sum) = suma_dos_nums(num1 = NUM1, num2 = NUM2)

```

13\. Conclusión
---------------

Felicidades ?. Hemos aprendido los básicos de ? Cairo. Con este conocimiento podrías identificar lo que se hace en cada línea de nuestra función que suma dos enteros ?.

En los siguientes tutoriales aprenderemos más sobre los pointers y el manejo de la memoria; la common library de cairo; cómo funciona el compilador de Cairo; y más!

Cualquier comentario o mejora por favor comentar con [@espejelomar](https://twitter.com/espejelomar) ?.

Continuamos aprendiendo las bases para programar en Cairo para Starknet.

large_image (8).webp

medium_image (8).webp

small_image (8).webp

thumbnail_image (8).webp

image (8).webp

Programando en la L2 de Ethereum: Básicos de Cairo pt. 2

thumbnail_YUPy3O4J_400x400.jpg

YUPy3O4J_400x400.jpg

Escrito por [@espejelomar](https://twitter.com/espejelomar). Mándame un DM y aprenderemos juntos ?

? El futuro de Ethereum es hoy y ya está aquí. Vamos a aprender a usar un ecosistema:

-   Sostiene a [dYdX](https://dydx.exchange/), DeFi que ya hizo cuatrocientos billones de trades y representa alrededor de un cuarto del total de las transacciones hechas en ethereum. Funcionan apenas desde hace 18 meses y constantemente [vencen a Coinbase](https://www.coinspeaker.com/dydx-coinbase-trade-volume/) en volumen de trades. Redujeron el precio de las transacciones de 500 a 1,000 veces. Son tan baratas que no necesitan cobrar el gas a los usuarios ?.
-   En la la semana del 7 al 13 de marzo de 2022, por primera vez, logró tener 33% más transacciones que Ethereum ?.

Y apenas es el comienzo. Aprende un poco más sobre el ecosistema de Starkware en [este texto corto](https://mirror.xyz/espejel.eth/PlDDEHJpp3Y0UhWVvGAnkk4JsBbJ8jr1oopGZFaRilI). Únete al [mayor Meetup](https://www.meetup.com/fr-FR/starknet_latam/) de habla hispana sobre StarkNet. Saluda en el el canal ```#?-español``` en el [Discord](https://discord.gg/uJ9HZTUk2Y) de StarkNet.

___

Vamos a aprender a cómo instalar Cairo en nuestras máquinas y a dejar todo listo para comenzar a programar ❤️. También aprenderemos comandos básicos para interactuar con Cairo desde nuestra terminal.

La [documentación de Cairo](https://www.cairo-lang.org/docs/quickstart.html) nos da instrucciones muy claras. Sin embargo, puede haber excepciones según tu máquina.

## 1. Instalando Cairo


La [documentación](https://www.cairo-lang.org/docs/quickstart.html#installation) de Cairo dice:

Recomendamos trabajar dentro de un entorno virtual de python, pero también puedes instalar el paquete de Cairo directamente. Para crear e ingresar al entorno virtual, escriba:

 ```
 python3.7 -m venv ~/cairo_venv
 source ~/cairo_venv/bin/activate

 ```

 Asegúrate de que `venv` esté activado; deberías ver (`cairo_venv`) en la línea de comando.

 Asegúrate de poder instalar los siguientes paquetes de pip: `ecdsa`, `fastecdsa`, `sympy` (usando `pip3 install ecdsa fastecdsa sympy`). En Ubuntu, por ejemplo, primero deberá ejecutar: `sudo apt install -y libgmp3-dev`.

 En Mac, puedes usar brew: `brew install gmp`.

 Instala el paquete de Python `cairo-lang` usando:

`pip3 install cairo-lang`

Si todo te salió bien con estas instrucciones, excelente ?. Es muy probable que no haya sido así. Yo instalé Cairo en Ubuntu y en MacOS y ninguna instalación salió a la primera ?. No te preocupes. Se resuelve.

### 1.1. MacOS

Si estás usando MacOS es probable que tengas problemas para instalar `gmp` con `brew install gmp`. [Esta respuesta](https://github.com/OpenZeppelin/nile/issues/22) a un issue en el repositorio de Nile tiene cuatro formas diferentes de solucionarlo:

Yo usé `CFLAGS=-I`brew --prefix gmp`/include LDFLAGS=-L`brew --prefix gmp`/lib pip install ecdsa fastecdsa sympy` en mi terminal y funcionó de maravilla.

Otro artículo muy interesante recomienda instalar usando Docker:

```

# instala build tools
xcode-select --install

# instala brew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# instala python3.7
brew install python@3.7 git gmp

# instala cairo
python3.7 -m venv ~/cairo_venv
source ~/cairo_venv/bin/activate
pip3 install ecdsa fastecdsa sympy cairo-lang

# instala docker: https://docs.docker.com/desktop/mac/install
# pull containers
docker pull shardlabs/starknet-devnet
docker pull trufflesuite/ganache-cli
docker pull eqlabs/pathfinder

# comienza ganache
# para ver los logs de ganache: docker logs -f $(docker ps | grep ganache-cli | awk '{print $1}')
docker run -d --rm --network host trufflesuite/ganache-cli

# comienza starknet-devnet
# to tail ganache logs: docker logs -f $(docker ps | grep starknet-devnet | awk '{print $1}')
docker run -d --rm --network host shardlabs/starknet-devnet

#  pathfinder
# para ver los logs de pathfinder: docker logs -f $(docker ps | grep pathfinder | awk '{print $1}')
git clone https://github.com/eqlabs/pathfinder.git
cd pathfinder; docker build -t pathfinder .
docker run -d --rm --network host -e RUST_LOG=info -e ETH_RPC_URL=https://mainnet.infura.io/v3/<INFURA_ID> pathfinder

# cairo shortcuts
# NOTA: se asume que usas zsh
mkdir -p $HOME/cairo_libs
git clone git@github.com:OpenZeppelin/cairo-contracts.git $HOME/cairo_libs
ln -s $HOME/cairo_libs/cairo-contracts/src/openzeppelin $HOME/cairo_libs/openzeppelin
echo 'alias cairodev="python3.7 -m venv ~/cairo_venv; source ~/cairo_venv/bin/activate; export STARKNET_NETWORK=alpha-goerli; export CAIRO_PATH=~/cairo_libs; export STARKNET_WALLET=starkware.starknet.wallets.open_zeppelin.OpenZeppelinAccount"' >> ~/.zshrc
echo 'alias cairoprod="python3.7 -m venv ~/cairo_venv; source ~/cairo_venv/bin/activate; export STARKNET_NETWORK=alpha-mainnet; export CAIRO_PATH=~/cairo_libs; export STARKNET_WALLET=starkware.starknet.wallets.open_zeppelin.OpenZeppelinAccount"' >> ~/.zshrc
source ~/.zshrc```



### 1.2. Ubuntu

El mismo artículo recomienda la siguiente instalación para Ubuntu:

```
# system setup
sudo apt update && sudo apt upgrade
sudo apt install -y software-properties-common git curl pkg-config build-essential libssl-dev libffi-dev libgmp3-dev

# instala python3.7
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt install -y python3.7 python3.7-dev python3.7-venv python3-pip

# instala cairo
python3.7 -m venv ~/cairo_venv
source ~/cairo_venv/bin/activate
pip3 install ecdsa fastecdsa sympy cairo-lang

# cairo shortcuts
mkdir -p $HOME/cairo_libs
git clone git@github.com:OpenZeppelin/cairo-contracts.git $HOME/cairo_libs
ln -s $HOME/cairo_libs/cairo-contracts/src/openzeppelin $HOME/cairo_libs/openzeppelin
echo 'alias cairodev="python3.7 -m venv ~/cairo_venv; source ~/cairo_venv/bin/activate; export STARKNET_NETWORK=alpha-goerli; export CAIRO_PATH=~/cairo_libs; export STARKNET_WALLET=starkware.starknet.wallets.open_zeppelin.OpenZeppelinAccount"' >> ~/.bashrc
echo 'alias cairoprod="python3.7 -m venv ~/cairo_venv; source ~/cairo_venv/bin/activate; export STARKNET_NETWORK=alpha-mainnet; export CAIRO_PATH=~/cairo_libs; export STARKNET_WALLET=starkware.starknet.wallets.open_zeppelin.OpenZeppelinAccount"' >> ~/.bashrc
source ~/.bashrc

```

### 1.3. Windows

? ... ?

2\. VSCode para tu Cairo ?


Si escribes `cairo` en el buscador de plugins de VSCode ([aquí](https://code.visualstudio.com/docs/editor/extension-marketplace#:~:text=You%20can%20browse%20and%20install,on%20the%20VS%20Code%20Marketplace.) tutorial sobre cómo instalar plugins) te aparecerán solo dos. Estamos comenzando ?:

![1.jpg](/uploads/1_8b212f01fd.jpg)

Ambas extensiones son útiles.

1. La primera, `Cairo`, fue creada por StarkWare.
2. La segunda, `Cairo language support for StarkNet`, fue creada por [Eric Lau](https://github.com/ericglau/cairo-ls) quien es parte de Open Zepellin.

Recomiendo instalar ambas en tu VSCode.

Ahora verás que tu código en Cairo se ve mucho mejor, es más fácil de leer y te retorna errores en tiempo real. No tienes que esperar a compilar tu código para observar si tiene errores ?.

![2.jpg](/uploads/2_d237666324.jpg)

##3. Compila y corre tu código de Cairo ?


Las herramientas que ofrece StarkNet para interactuar con la línea de comando son muchas ?. No entraremos en detalle hasta más adelante. Por ahora, solo mostraremos los comandos con los que podremos correr la aplicación que haremos en el siguiente tutorial ?‍♀️. Pero no te preocupes, los comandos para correr otras aplicaciones serán muy similares.

`cairo-compile` nos permite compilar nuestro código y exportar un json que leeremos en el siguiente comando. Si tenemos un programa llamado `array_sum.cairo` y queremos que el json se llame `x.json` entonces usaríamos el siguiente código:

```
cairo-compile array_sum.cairo --output x.json

```

Sencillo, cierto? ❤️

Ok ahora corramos nuestro código con `cairo-run`.

```
cairo-run --program=x.json
    --print_output --layout=small

```

Aquí los detalles:

-   Indicamos en el argumento `--program` que queremos correr el `x.json` que generamos antes.
-   Con `--print_output` indicamos que queremos imprimir algo de nuestro programa en la terminal. Por ejemplo, en el siguiente tutorial usaremos el builtin (más adelante los estudiaremos) `output` y la función `serialize_word` para imprimir en la terminal.
-   `--layout` nos permite indicar el layout a utilizar. Según los builtins que utilicemos, será el layout a utilizar. Más adelante estaremos usando el builtin `output` y para esto necesitamos el layout `small`. Abajo una foto de los builtins que cubre el layout `small`. Si no usaremos ningún builtin entonces podemos dejar este argumento vacío por lo que usaríamos el layout default, el `plain`.

![3.jpg](/uploads/3_744f7ca101.jpg)

Ahora sí...


En el [siguiente tutorial](https://mirror.xyz/espejel.eth/jN2rapzYQDKJqY-MAz2Bz0VMIkmqi0IAmWbFdhq09CU) aprenderemos los básicos de Cairo ?. Usaremos todo lo aprendido y preparado aquí. Nos vamos a divertir aún más.

En los siguientes tutoriales aprenderemos más sobre los pointers y el manejo de la memoria; la common library de cairo; cómo funciona el compilador de Cairo; y más!

Cualquier comentario o mejora por favor comentar con [@espejelomar](https://twitter.com/espejelomar) ?.


Una introducción al lenguaje de programación para escribir contratos en Starknet.

Programando en la L2 de Ethereum: Básicos de Cairo pt. 1

Originado vía mirror: [link a la publicación original](https://mirror.xyz/defilatam.eth/1GhzBbXgJSoX6erTnyax4Cm2StWCG35w6irW6awdK1w).

> Escrito por Omar Espejel ([Twitter](https://twitter.com/espejelomar))
Disclaimers. Nada de aquí es ideado por mí. Se obtuvo de la entrevista de [@HenriLieutaud](https://twitter.com/HenriLieutaud), Developer Advocate en [@StarkWareLtd](https://twitter.com/StarkWareLtd), con [@0xJoxes](https://twitter.com/0xJoxes) y [@utonianum](https://twitter.com/utonianum) el 11 de marzo de 2022 ([link](https://twitter.com/SpacesArgentina/status/1502372285520433152)). Muy recomendada. Si existe algún error es culpa mía y de mi interpretación. Por favor comentarme en [@espejelomar](https://mobile.twitter.com/espejelomar).

Bienvenid@ ???!

Leerás sobre un ecosistema que:

-   Sostiene a [dYdX](https://dydx.exchange/), DeFi que ya hizo cuatrocientos billones de trades y representa alrededor de un cuarto del total de las transacciones hechas en ethereum. Funcionan apenas desde hace 18 meses y constantemente [vencen a Coinbase](https://www.coinspeaker.com/dydx-coinbase-trade-volume/) en volumen de trades. Redujeron el precio de las transacciones de 500 a 1,000 veces. Son tan baratas que no necesitan cobrar el gas a los usuarios ?.
-   Que de la semana del 7 al 13 de marzo de 2022, por primera vez, logró tener 33% más transacciones que Ethereum ?.


## Una historia de STARKs ?

Debajo de todo el ecosistema de Starware están las [STARK](https://eprint.iacr.org/2018/046.pdf) (inventados por Eli Ben-Sasson, cofundador de Starkware). Las STARK son una herramienta matemática que le permiten a una Persona A probarle a una Persona B que para una ecuación con miles de coeficientes diferentes, la Persona A conoce los puntos donde la ecuación se reduce a 0. La Persona A quiere probarle a B que tiene la solución a la ecuación sin que B tenga que hacer todos los cálculos.

Para esto Starkware creó [Cairo](https://www.cairo-lang.org/) ?, un lenguaje de programación, en el que una persona A puede ejecutar un programa y generar una prueba computacional y enviársela a B. B luego logra, sin tener que ejecutar el programa ella misma, verificar esta prueba y asegurarse de que el programa sea ejecutado correctamente y lograr el resultado que envía A. En otras palabras, B no tiene que confiar ? en A para estar seguro de que se logra el resultado.

Una de las razones por las que el gas en Ethereum es caro ? es porque cada nodo de la red ejecuta cada transacción. Cuando ejecutas una transacción, esta misma operación es replicada por diez mil nodos. Cairo permite que solo una persona ejecute una transacción y proporcione al resto una prueba de ejecución. Otros pueden verificar si la transacción se ejecutó correctamente sin ejecutarla ellos mismos. Esto hace que la transacción sea mucho más rápida y económica.

## StarkEx - El corto plazo ⌛

![have a title](/uploads/5giv_I_Tnpxl36_A9_Sxr_YFGT_5498f259bc.webp "Valor total bloqueado, número total de transacciones, y trading acumulativo en StarkEx hasta el 9 de marzo de 2022.")

Hace dos años el caso de uso de la escalabilidad de Ethereum era el trading. Por ejemplo, trading de NFTs o tokens. Starware implementó StarkEx con [dYdX](https://dydx.exchange/), [Sorare](https://sorare.com/), [Immutable](https://www.immutable.com/) y otros. Hay mucho interés en StarkEx porque ya está probado que funciona. Muchos clientes quieren usarlo.

Aquí una foto de actuales clientes. Notar que dYdx, Sorare e Immutable ya son unicornios.

![have a title](/uploads/image_350d77576c.webp "Clientes de Starkware usando StarkEx")

[Aquí](https://starkware.co/starkex/) puedes ver la página oficial de StarkEx con más detalles.

## Starknet - El futuro ?

> [Según su sitio web](https://starkware.co/starknet/): StarkNet es una ZK-Rollup descentralizada que no requiere permiso para ser utilizada. Funciona como una red L2 sobre Ethereum, lo que permite que cualquier dApp alcance una escalabilidad ilimitada para su cálculo sin comprometer la compatibilidad y la seguridad de Ethereum.

![have a title](/uploads/R_Fe_K_Vwt_Mrb_Ya_E_Cda_Mj6s_K_b654d3466e.webp "Logo de StarkNet.")

En otras palabras, es una red paralela a Ethereum en la que Starkware comenzó a trabajar hace poco más de un año. La Mainnet ha estado operando desde diciembre y la Testnet desde julio. Puedes escribir contratos inteligentes e implementarlos. La ejecución de cada transacción crea una prueba interpretada por Ethereum. El software todavía está en Aplha, por lo que aún se está desarrollando y requiere features aún. Sin embargo, una meta para el segundo semestre de 2022 es pasar a Beta y hacer diez veces más transacciones en Ethereum.

Hoy en día ya muchos proyectos se ejecutan en Starknet, y Starware se enfoca en construir el ecosistema. Hay tremendas oportunidades aquí. El objetivo es hacer las mismas cosas en Starknet que en el ya probado y exitoso StarkEx. Por ejemplo, podríamos tener un StarkEx encima de StarkNet, según nuestras necesidades. Este sería un caso de una Layer 3, pero ese es un tema para otro día. A mediano plazo será más cómodo construir sobre StarkNet que sobre StarkEx por el ecosistema y las funcionalidades creadas. Día a día se mueve el ecosistema y es mejor estar temprano ?.

## La decentralización de Starkware ?

Está en proceso. Lo que ha estado en Testnet desde julio de 2021 es una prueba de que el concepto matemático y de ingeniería se puede realizar. StarkNet funciona, pero aún no está descentralizada. ¿Qué puede hacer Starkware para dar seguridad a los usuarios de Starknet de que su dinero no será robado? No te preocupes, aunque StarkNet ahora está centralizado, no puede quedarse con el dinero ni apropiarse de él, pero sí puede censurar las transacciones.

Hoy StarkNet está centralizado, pero el objetivo es la descentralización ?. Para fines de 2022, el objetivo es tener un plan concreto para proceder con la descentralización. Hoy la comunidad está contribuyendo y discutiendo cuál será la mejor manera.

## Cairo - Una nueva forma de escribir smart contracts ✍️

![have a title](/uploads/7_Sig_D_b_A_Sjmo8rlh_B_Lq_N6_03bf6db453.webp "Logo de Cairo")

Siguen dos fantásticas explicaciones de Henri (nuevamente, cualquier error fue debido a mi interpretación).

Te preguntarás, ¿por qué aprender Cairo?

¿Por qué aprendiste Solidity y el ecosistema Ethereum?

¿Por qué no nos quedamos con Bitcoin?

¿Por qué no nos quedamos con los bancos antes?

Eres un@ inconformista. Te adaptas ?. Bitcoin te permite hacer más cosas que un banco. Ethereum y Solidity te permiten hacer más cosas que Bitcoin. Ahora, Cairo te permite hacer más cosas con Solidity. Realmente te permite lograr algo que Solidity no puede. Es hora de dar el siguiente paso.

Ponlo de esta manera. Ethereum es una tostadora que puede hacer dos piezas de pan simultáneamente ?. Se ajusta muy bien y es lo que necesitas si solo te alimentas a ti mism@. StarkNet es un horno donde puedes hacer lo mismo pero con muchas más piezas de pan a la vez. Pero no solo eso, también puedes hacer pasteles, todo tipo de panes, carnes y más ?. Aquí la diferencia clave más allá de los menores costos.

StarkNet no solo lo hace para que puedas hornear más de lo mismo; es decir, no solo abarata y agiliza las transacciones. Pero, y quizás aún más importante, te permite hacer cosas que antes estaban fuera de nuestro alcance en Solidity y la Layer 1 de Ethereum. Por ejemplo, le permite hacer cálculos matemáticos que de otro modo serían costosos en Solidity. Calcular la inflación diaria en Ethereum sería demasiado costoso, pero con StarkNet podemos calcularlo usando Cairo. Una sola persona obtiene el cálculo y puede demostrar al resto de la red que este cálculo es válido y se realizó. Esto también se aplica a los videojuegos, el machine learning y muchas otras aplicaciones. Está dando más poder de cómputo a los desarrolladores.

Ahora, escribir contratos inteligentes en Cairo es difícil. Pero no es difícil por Cairo; escribir contratos inteligentes en cualquier lugar es difícil. Si ya sabes cómo escribir contratos, la transición a Cairo no será difícil. Hoy lo más difícil de programar en Cairo es que el ecosistema y las herramientas aún se están construyendo. Por ejemplo, no es fácil encontrarlo en Google o Stack Overflow cuando hay un error. Sin embargo, estas herramientas están en construcción. Open Zeppelin ya está construyendo sus contratos Solidity pero ahora para Cairo, por ejemplo, las interfaces para contratos como el ERC20. Además, se está trabajando en la versión dos de un transpilador que le permite escribir Solidity e implementarlo en StarkNet. Todavía está en desarrollo, pero se están haciendo progresos.

En un capítulo por salir del [Podcast We Decentralize Tech](https://open.spotify.com/show/1BncjQN6iZKb0a5qY4MxV9) (donde soy host principal), Henri nos aconseja por dónde comenzar con Cairo.

-   Si te gusta ir directo a lo práctico prueba los [tutoriales en StarkNet Cairo 101](https://github.com/l-henri/starknet-cairo-101).
-   Si te gusta comenzar desde los fundamentos prueba desde la [documentación con Hello, StarkNet](https://starknet.io/docs/hello_starknet/index.html#hello-starknet).
-   Habla y colabora en el [Discord](https://discord.com/invite/uJ9HZTUk2Y) de StarkNet.
-   ¿Aprendiendo en español? Únete al canal en español de StarNet Discord. Todos aprendemos juntos allí.

* * * * *

Gracias por leerme. Puedes contactarme en [@espejelomar](https://mobile.twitter.com/espejelomar).


Starkware es uno de los principales proyectos de escalabilidad en Ethereum mendiante el uso de pruebas STARK.

medium_starkware.png

small_starkware.png

thumbnail_starkware.png

starkware.png

Una introducción concreta al ecosistema de Starkware

Por LeoSagan. Originado vía Mirror: [link al artículo original](https://mirror.xyz/defilatam.eth/cikrIVBZvIRGbhnx3HB-uDLrX5FZfrUdmQo-vV8ZAR8)

## Recursos para iniciarse en su desarrollo

Este documento apunta a ser una compilación exhaustiva (y por lo tanto constantemente actualizada y nuevamente desactualizada) de muchas fuentes que he estado usando desde que comencé en crypto allá por 2016. La mayor parte del contenido está en Inglés??, pero como quisimos compartir el conocimiento con la audiencia de países de habla hispana, también hemos recolectado recursos en Español??.He seguido el increíble [DeFi Developer Roadmap](https://raw.githubusercontent.com/OffcierCia/DeFi-Developer-Road-Map/main/DeFiRoadMapNewSVG.svg) de `Cia_Officer` como principal guía para completar este trabajo.Siéntanse libres de compartir, hacer contribuciones, borrados y críticas a este documento.Estamos aquí para aprender y construir!

*Leo*


## Acerca de los compilooooors

-   ?? [Tobias](http://www.twitter.com/0xtobias), OG en [?? DeFi_Latam](https://t.me/DeFi_LATAM) y "mastermind" de [Solidity Latam Shadowy Super-Coders](https://t.me/SolidityLATAM).
-   ?? [LeoSagan?](http://www.twitter.com/ethsagan), OG researcher en [Argenpool](https://t.me/Argenpool), OG developer en [?? DeFi_Latam](https://t.me/DeFi_LATAM) y editor del presente documento.
-   ?? Mención especial a [Lorena Fabris](https://twitter.com/blockya_), quien hizo un extraordinario trabajo al traducir muchos artículos de [dev.to](http://dev.to/)!

## Cómo empezar y no fallar

Cada vez que querés leer algo, diez nuevos (e interesantes) recursos aparecen. El universo Blockchain evoluciona a 100 veces la velocidad de la luz, y eso causa una enorme ansiedad... Entonces... ¿Cómo poder aprender más rápido, o al menos de una manera para que puedas sentir que hacés un progreso real? Quizás algo como el método `get things done` pueda ayudar:

```
- Querés aprender, no sabes por dónde empezar.
- Tomate 15 mins en la mañana.
- En un pizarrón o en un cuaderno,
- Escribí en forma de lista, todo lo que necesitas aprender.
- Usa esos 15 minutos para ordenar la lista.
- Marca los items como críticos, importantes, los que puedan esperar, irrelevantes.
- Y ahora: apegate a esa lista.
- Completá cada tarea.

Y a la mañana siguiente, repetí el proceso.
```

Existe una cantidad casi ilimitada e incontable de recursos. Y esto se está poniendo peor, porque como probablemente ya habrás oído, *llegamos temprano*.\
Pero `Cia_Officer` publicó un excelente trabajo que es realmente muy útil:

### La Hoja de Ruta del Desarrollador DeFi

![have a title](/uploads/axie_97205eaa2c.png "Esta es una fuente de ejemplo")

## ÍNDICE

### ESENCIALES

```
- Introducción al desarrollo
- Desarrollo Web
- Recursos generales de desarrollo
```

### APRENDER

```
- Tutoriales oficiales de Ethereum
- Plataformas de aprendizaje
- Aprendizaje sobre DeFi
- El lenguaje de programación Solidity
- Desarrollo de apps descentralizadas
- Seguridad
- Libros
- Cursos pagos
- Canales de Youtube
- El lenguaje de programación Rust
```

### CONSTRUIR

```
- Herramientas y ejemplos
- Desafíos
```

### INVESTIGAR

```
- Artículos sobre EVM
- Podcasts
- NFT
- L2
```

### MANTENERSE ACTUALIZADO

```
- Noticias
- Otras compilaciones de recursos (como la presente)
```

## ESENCIALES

> ?? El idioma inglés *es muy necesario*, sin él, hay una gran probabilidad de [NGMI](https://coinblurbs.com/crypto-slang-terms/)!

### Introducción al desarrollo

-   ?? [Primeros pasos en programación](https://mumuki.io/primeros-pasos)
-   [CS50's Introduction to Computer Science](https://www.edx.org/course/introduction-computer-science-harvardx-cs50x) por la Universidad de Harvard
-   ?? [Aprende Javascript](https://aprendejavascript.org/)
-   [Learn JS](https://scrimba.com/learn/learnjavascript)
-   ?? [Aprende JavaScript - Curso Completo desde Cero](https://www.youtube.com/watch?v=ivdTnPl1ND0) por FreeCodeCamp

### Desarrollo Web

-   [Full stack JS course](https://www.theodinproject.com/) por The Odin Project
-   [Node.js / Express Course - Build 4 Projects](https://www.youtube.com/watch?v=qwfE7fSVaZM) por FreeCodeCamp
-   [Learn React](https://scrimba.com/learn/learnreact) por Scrimba
-   [React JS Course for Beginners - 2021 Tutorial](https://www.youtube.com/watch?v=nTeuhbP7wdE) por FreeCodeCamp
-   [React Course - Beginner's Tutorial for React JavaScript Library 2022](https://www.youtube.com/watch?v=bMknfKXIFA8) por FreeCodeCamp

### Recursos generales de desarrollo

-   ?? [Pro GIT](https://git-scm.com/book/es/v2)
-   ?? [Curso práctico de GIT y Github desde cero](https://www.youtube.com/watch?v=HiXLkL42tMU)
-   ?? [Introducción a Github Actions](https://collectednotes.com/gndelia/introduccion-a-github-actions) por Gonzalo D'Elía
-   [Modern applications at AWS](https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html)

### Tutoriales oficiales de Ethereum

-   ?? [Whitepaper](https://ethereum.org/es/whitepaper/)
-   ?? [Documentación de desarrollo](https://ethereum.org/es/developers/docs/)
-   ?? [Tutoriales de desarrollo](https://ethereum.org/es/developers/tutorials/)

### Plataformas de aprendizaje

-   ?? [Cryptozombies](https://cryptozombies.io/es/course/)
-   ?? [The Ethernaut](https://ethernaut.openzeppelin.com/) por OpenZeppelin
-   [BuildSpace](https://buildspace.so/): Build alongside other devs
-   [Web3 University](https://www.web3.university/): Covering the fundamentals of web3 development: from writing Solidity, to minting NFTs, to building full-stack dApps

### Aprendizaje sobre DeFi

-   ?? [Primeros pasos en finanzas descentralizadas](https://mirror.xyz/0xcF5C9668234a1Ab8bAAaE52C4799875a5B993920/UyxkUJibw6CgHROXaMqq0PhFvJ2l1hxGjjfz6JDYZ2U) por Evangelina Rodriguez Machado
-   [What Is DeFi Composability? An Introduction To Money Legos](https://academy.shrimpy.io/post/what-is-defi-composability-an-introduction-to-money-legos) por [Shrimpy.io](http://shrimpy.io/)

### El lenguaje de desarrollo Solidity

-   ?? [(1/2) Introducción a Ethereum Development Clase I](https://www.youtube.com/watch?v=zoJb3G8TQcE) por Martin Triay
-   ?? [(2/2) Introducción a Ethereum Development Clase II](https://www.youtube.com/watch?v=i1IW9lK4mQw) por Martin Triay
-   ?? [Desarrollo en Ethereum - Cómo hacer un token ERC20](https://www.youtube.com/watch?v=G-Cco6I4US8) por Martin Triay
-   ?? [Desarrollo en Ethereum - Cómo upgradear un smart contract](https://www.youtube.com/watch?v=R7gi7l0luTw) por Martin Triay
-   ?? [(1/2) Introducción a DeFi Development](https://www.youtube.com/watch?v=dnxfqmjNAtQ) por Martin Triay
-   ?? [(2/2) Introducción a DeFi Development](https://www.youtube.com/watch?v=H8sbS9V6gVY) por Martin Triay
-   [Ethereum 101 - 101 key aspects of Ethereum](https://secureum.substack.com/p/ethereum-101) By Secureum
-   [Discover Ethereum & Solidity](https://www.ludu.co/course/ethereum) por Tristan Edwards
-   [Solidity Tutorial - A Full Course on Ethereum, Blockchain Development, Smart Contracts, and the EVM](https://www.youtube.com/watch?v=ipwxYa-F1uY) por FreeCodeCamp
-   [Creating your own ERC20 token in more than 2 hours](https://nanexcool.medium.com/creating-your-own-erc20-token-in-more-than-2-hours-f0846bc34c9c) por Mariano Conti
-   [How to Learn Solidity in 30 days](https://medium.com/coinmonks/how-to-learn-solidity-in-30-days-78b02e503d23) por Tom Terado
-   [Moralis full course for beginners: Web3](https://www.youtube.com/watch?v=MY4WYoZPr-U): Infraestructura Web3
-   ? [Solidity, Blockchain, and Smart Contract Course -- Beginner to Expert Python Tutorial](https://www.youtube.com/watch?v=M576WGiDBdQ&feature=youtu.be) por FreeCodeCamp
-   [How to test Ethereum Smart Contracts](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d?gi=59fa2f893853) por Alex Roan de Chainlink Labs

### dApp development

-   ?? [Curso de dApps con Solidity](https://courseit.io/cursos/curso-gratuito-dapps-solidity) por CourseIt
-   [Ethereum Dapp Crash Course: Make an ERC20 token faucet + Frontend](https://dev.to/richardmelko/ethereum-dapp-crash-course-make-an-erc20-token-faucet-frontend-2m43)
-   [NFT/ERC-721/Collectible END-TO-END TUTORIAL: Deploy, List on Opensea, Host Metadata on IPFS](https://www.youtube.com/watch?v=p36tXHX1JD8) por Patrick Collins
-   [The Complete Guide to Full Stack Ethereum Development (Building Full Stack dApps with React, Ethers.js, Solidity, and Hardhat)](https://dev.to/dabit3/the-complete-guide-to-full-stack-ethereum-development-3j13) por Nader Dabit
-   ?? [La guía completa para el desarrollo de Ethereum](https://fabris-86569.medium.com/la-gu%C3%ADa-completa-para-el-desarrollo-de-ethereum-5cb10125c1c3) por Nader Dabit, traducción de Lorena Fabris
-   ?? [Definiendo la pila Web3](https://fabris-86569.medium.com/definiendo-la-pila-web3-73ac0cff750) por Nader Dabit, traducción de Lorena Fabris
-   [How To Build A Node.js API For Ethereum Blockchain](https://www.smashingmagazine.com/2021/01/nodejs-api-ethereum-blockchain)
-   [Zero-Config CLI to Deploy Static Websites to IPFS](https://github.com/ipfs-shipyard/ipfs-deploy)

### Seguridad

-   ?? [(1/2) Introducción a Hacking y Seguridad de Smart Contracts en Ethereum](https://www.youtube.com/watch?v=sqjHodAj5Xc) por Martín Abbatemarco
-   ?? [(2/2) Introducción a Hacking y Seguridad de Smart Contracts en Ethereum](https://www.youtube.com/watch?v=CEzERbkVAhk) por Martín Abbatemarco
-   ?? [Seguridad en Solidity](https://www.youtube.com/watch?v=q8u08Q2Dpgc) por Antonio Sanchez
-   [Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/): Wargame to learn offensive security of DeFi smart contracts
-   [Web App Vulnerabilities - DevSecOps Course for Beginners](https://www.youtube.com/watch?v=F5KJVuii0Yw) por FreeCodeCamp
-   [How To Secure Your Smart Contracts: Reentrancy and Owner Theft Attacks](https://medium.com/coinmonks/how-to-secure-your-smart-contracts-dc500f2c8fca) por Alex Roan de Chainlink Labs
-   [Eminence attack explanation](https://sampriestley.com/defi-arbs-explained-15m-eminence-attack/)
-   [Secureum - Education & Evaluation of Ethereum Security](https://secureum.substack.com/archive?sort=new) by Secureum
-   [Solidity 101 - 101 key aspects of Solidity](https://secureum.substack.com/p/solidity-101) by Secureum
-   [Solidity 201 - 100 more key aspects of Solidity](https://secureum.substack.com/p/solidity-201) by Secureum
-   [Secureum Youtube Channel](https://www.youtube.com/channel/UCJIdmjE0J_1zz1kUtbgedCA) by Secureum

### Libros

-   Ethereum for Web Developers por Patricio Palladino
-   Beginning Ethereum Smart Contracts Programming por Wei Meng Lee
-   [Building Ethereum Dapps](https://livebook.manning.com/book/building-ethereum-dapps)
-   Ethereum Cookbook por Manoj PR
-   Ethereum Smart Contracts Development por Mayukh Mukhopadhyay
-   Introducing Ethereum and Solidity por Chris Dannen
-   [Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) por Andreas Antonopoulos y Gavin Wood

### Cursos pagos

-   [Blockchain Web Development on Ethereum 2022](https://www.udemy.com/course/complete-blockchain-web-application-course-on-ethereum/?couponCode=BE7AEE438AED981D02F9) por Udemy
-   [Ethereum and Solidity: The Complete Developer's Guide](https://www.udemy.com/course/ethereum-and-solidity-the-complete-developers-guide/) por Udemy
-   [The Complete Solidity Course - Blockchain - Zero to Expert](https://www.udemy.com/course/the-complete-solidity-course-blockchain-zero-to-expert/) por Udemy
-   [Complete DApp - Solidity & React - Blockchain Development](https://www.udemy.com/course/complete-dapp-solidity-react-blockchain-development/) por Udemy

### Canales de Youtube

-   [Austin Griffith](https://www.youtube.com/channel/UC_HI2i2peo1A-STdG22GFsA/videos)
-   [Scaffold-ETH Workshop](https://www.youtube.com/watch?v=8P1mIlKGFMs)
-   [Patrick Collins de FreeCodeCamp](https://www.youtube.com/c/PatrickCollins/videos)
-   ?? [Alberto Lasa](https://www.youtube.com/c/AlbertoLasa/videos)
-   [Secureum](https://www.youtube.com/c/SecureumVideos/videos) by Secureum

### El lenguaje de programación Rust

-   ?? [FUNDAMENTOS de RUST - Aprende Rust desde Cero en español](https://www.youtube.com/watch?v=AD1JyZ3blgI) por Carlos Azaustre
-   [Rust Programming Course for Beginners](https://www.youtube.com/watch?v=MsocPEZBd-M) por FreeCodeCamp
-   [A gentle introduction to Solana](https://dev.to/kelvinkirima014/a-gentle-introduction-to-solana-2h3k) por Kelvin Kirima
-   [Rust Crash Course Tutorial for Solana](https://www.youtube.com/watch?v=-AAtfPHEMbA) por Leet Dev
-   [Developing with Rust](https://docs.solana.com/developing/on-chain-programs/developing-rust) por Solana Documentation

## CONSTRUIR

### Herramientas y ejemplos

-   ?? [Lista de herramientas para desarrollador de Ethereum](https://github.com/ConsenSys/ethereum-developer-tools-list/blob/master/README_Spanish.md): Una guía de herramientas, componentes, patrones y plataformas disponibles para desarrollar aplicaciones en Ethereum. *PR pendiente de aprobacion del repositorio original [en ingles](https://github.com/ConsenSys/ethereum-developer-tools-list)*
-   [DappTools](https://github.com/dapphub/dapptools): una suite de herramientas de Ethereum basada en línea de comandos
-   [HardHat Tutorials](https://hardhat.org/tutorial/)
-   [Projects for learning solidity and ethereum](https://github.com/antico5/solidity_learning)
-   [EthereumDev](https://ethereumdev.io/): Desde la implementación de su primer smart contract, hasta la interacción con los protocolos DeFi
-   [Scaffold-eth](https://github.com/austintgriffith/scaffold-eth): ofrece un stack de prototipado rápido en Ethereum, dando a los desarrolladores acceso a herramientas de ultima generación para un aprendizaje y entrega rápidos de una dApp
-   [EtherScripter](https://etherscripter.com/): una herramienta visual de scripting de smart contracts
-   [Eth.build](https://eth.build/): Un sandbox educacional para Web3
-   [BuidlGuidl](https://buidlguidl.com/): un "curated group" de productos, prototipos y tutoriales hechos con Scaffold-eth
-   [Mainnet forking with Hardhat](https://hardhat.org/guides/mainnet-forking.html)
-   [How to Write Smart Contracts That Optimize Gas Spent on Ethereum](https://betterprogramming.pub/how-to-write-smart-contracts-that-optimize-gas-spent-on-ethereum-30b5e9c5db85)
-   [Solidity by Example: an introduction to Solidity with simple examples](https://solidity-by-example.org/)
-   [Contraktor](https://github.com/wslyvh/contraktor): un explorador de smart contracts. Visualiza e interactúa con proyectos DeFi populares o cualquier otro contrato verificado

### Desafíos

-   [Capture the Ether](https://capturetheether.com/challenges/)
-   [Smart Contract Engineer](https://www.smartcontract.engineer/challenges)
-   [Accessing Private Data](https://www.youtube.com/watch?v=Gg6nt3YW74o)
-   [SpeedRunEthereum](https://speedrunethereum.com/)

## INVESTIGAR

### Artículos sobre EVM

-   [Ethereum address checksum explained](https://coincodex.com/article/2078/ethereum-address-checksum-explained/)
-   [Ethereum is a Dark Forest](https://medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff)
-   [How to munch on pickles from a whale dinner](https://medium.com/@mierzwik/how-to-munch-on-pickles-from-a-whale-dinner-edb5628cc769)
-   [Escaping the dark forest](https://samczsun.com/escaping-the-dark-forest/)
-   [Frontrunning for Dummies](https://medium.com/@parzival.is.sweet/crypto-front-running-for-dummies-bed2d4682db0)
-   [Flash Boys 2.0:Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges](https://arxiv.org/pdf/1904.05234.pdf)
-   ?? [MEV, Flashbots y Dark Forest](http://youtu.be/ba2R1uLj9Fc) por DeFi Latam
-   [Hitchhiker's Guide to the EVM: Gas Golfing by Optimizing Storage](https://medium.com/geekculture/hitchhikers-guide-to-the-evm-56a3d90212ac) por Alex Roan de Chainlink Labs

### L2

-   [Optimistic rollups](https://research.paradigm.xyz/rollups) por Paradigm

### DAOs

-   [Decentralized Autonomous Organizations Canon](https://future.a16z.com/dao-canon/) by Sonal Chokshi, Zoran Basich, and Guy Wuollet from a16z

### Podcasts

-   [Uncommon Core: Exploring the big ideas in crypto from first principles. Hosted by Su Zhu and Hasu](https://open.spotify.com/show/3vuV292Him90EjQ5YL4XIw)
-   ?? [DeFiLatam](https://open.spotify.com/show/2nrHx0HsLCw4oBBk5n3wN9)
-   ?? [Ethereum BA](https://open.spotify.com/show/2WPeBSDNqG2YDPGfYHoKPN)
-   ?? [DeFi en español](https://open.spotify.com/show/3BQuz3YdP8B7y49HgUMhpe?si=z7iZl842Tcy3zLrbj1MRlw)

### NFTs

-   ?? [Construyendo un Marketplace de NFT de Pila Completa en Ethereum con Polygon](https://fabris-86569.medium.com/construyendo-un-marketplace-de-nft-de-pila-completa-en-ethereum-con-polygon-5dabef0814d5) por Nader Dabit, traducido por Lorena Fabris
-   [NFTGAN: Non-Fungible Token Art Generation Using Generative Adversarial Networks](https://arxiv.org/pdf/2112.10577.pdf) por Sakib Shahriar and Kadhim Hayawi
-   [OpenSea guides](https://opensea.io/blog/category/guides/)
-   [Zima Red](https://andrewsteinwold.substack.com/) por @AndrewSteinwold
-   [DeFi Arts Intelligencer](https://artsdefi.substack.com/) por @WPeaster
-   [Jamm Session](https://outpost-protocol.com/) por @Flynnjamm

## MANTENERSE ACTUALIZADO


### Noticias

-   [Week in Ethereum](https://weekinethereumnews.com/) por @evan_van_ness
-   [The daily Gwei](http://thedailygwei.substack.com/) por @sassal0x
-   [EthHub Weekly](http://ethhub.substack.com/)
-   [Decrypt](https://decrypt.co/)
-   ?? [DeFi_LATAM](https://twitter.com/DeFi_LATAM) por @Defi_LATAM
-   [Unqualified Opinions](https://messari.io/newsletter) por @MessariCrypto
-   [The Block](https://theblockcrypto.com/newsletter-signup) por @TheBlock
-   [Bankless](https://bankless.substack.com/) por @BanklessHQ
-   [The Defiant](https://thedefiant.substack.com/) por @DefiantNews
-   [This Week in DeFi](https://defirate.com/newsletter) por @DeFiRate
-   [DeFi Pulse Farmer](https://yieldfarmer.substack.com/) por @defipulse
-   [Today in DeFi](https://todayindefi.substack.com/) por @safetyth1rd
-   [Yearn Finance by @iearnfinance](https://yearn.substack.com/)
-   [DeFi Weekly](https://defiweekly.substack.com/) por @kermankohli
-   [Dose of DeFi](https://doseofdefi.substack.com/)
-   [Weekly Jobs Update](https://cryptocurrencyjobs.substack.com/) por @jobsincrypto

### Otras compilaciones de recursos (como la presente)

-   [UseWeb3](https://www.useweb3.xyz/): Explora los últimos recursos, tutoriales, desafíos, herramientas, cursos y ejemplos
-   [Awesome Solidity](https://github.com/bkrem/awesome-solidity): Una lista muy detallada de recursos y herramientas de Solidity
-   [DeFi Developer Roadmap](https://github.com/OffcierCia/DeFi-Developer-Road-Map?s=09) por Officer_cia, un magnífico mapa de recursos de desarrollo
-   [Blockchain Development Resources](https://github.com/frankiefab100/Blockchain-Development-Resources) por Franklin U.O. Ohaegbulam


Una guía que nos acerca a como adentrarnos en el mundo del desarrollo en DeFi

medium_leo.jpg

small_leo.jpg

thumbnail_leo.jpg

leo.jpg

La enciclopedia DeFi

thumbnail_07Hq4xli_400x400.jpg

07Hq4xli_400x400.jpg

Un reporte especial dedicado al estado actual de los cuatros grandes Optimistic Rollups

medium_2.png

small_2.png

thumbnail_2.png

2.png

Estado de la escalabilidad en Ethereum - Enero y Febrero 2022

Originado vía Mirror: [link a la publicación original](https://mirror.xyz/defilatam.eth/C4gjpjtCGqN6tV1d9tpT_yxEPt69blwwA5eK64oL4Zw)

Conocimientos previos a tener en cuenta:

-   [Optimistic Rollups](https://www.defilatam.com/blog/escalabilidad-en-ethereum-optimistic-y-zk-rollups)
-   [Introducción al MEV](https://mirror.xyz/defilatam.eth/nU0v23aHxFI7Aml-7JJr0i0VQyhzzLYqkqDnypxVN2Y)

A grandes rasgos, hay dos grandes escuelas de pensamiento acerca de cómo se deberían abordar los problemas que acarrea la extracción de MEV en redes distribuidas:

-   **MEVA (Subastas de MEV)**: Aceptar que el MEV siempre se encontrará en blockchain e implementar un sistema de subastas de forma democrática para que la extracción no se vea centralizada en unos pocos actores.
-   **Mitigación del MEV**: implementar mecanismos para minimizar la extracción de MEV ya que causan una amenaza existencial para los usuarios de la red. Sobre esta vereda, suelen argumentar que MEVA le facilita el trabajo a los ladrones.

En este blog exploramos el mecanismo desarrollado por Chainlink e implementado a futuro por Arbitrum para lidiar con el problema del 'fair-ordering' en redes distribuidas, y los posibles trade-offs que afronta.

## Secuenciador en Arbitrum:

Básicamente, el secuenciador es el actor que toma las txs que envían los usuarios en L2, las ordena y luego envía el conjunto de esas txs agrupadas al contrato en L1.

A diferencia de L1, el orden de las transacciones en Arbitrum está determinado por un contrato en L1 llamado [Inbox](https://etherscan.io/address/0x4c6f947ae67f572afa4ae0730947de7c874f95ef). El secuenciador es un actor al que se le otorga el poder de reordenar las últimas transacciones en el Inbox.

En la etapa inicial de Arbitrum, el secuenciador se encuentra controlado por Offchain Labs, la compañía detrás de Arbitrum, esto significa que la empresa cuenta con el poder de manipular el orden de las transacciones en los bloques de L2. El secuenciador decide unilateralmente cómo se ordenan las txs, y ya que este poder se encuentra centralizado en una sola entidad, podría verse beneficiado enormemente a costa de los usuarios. Al comienzo, y ya que el secuenciador corre por parte de Offchain Labs, el mecanismo de *slashing* por mal comportamiento no se encuentra activado.

Al principio, los usuarios estarán confiando en que el secuenciador centralizado no actúe de forma maliciosa, e.g. front-runeando o censurando las txs que procesa.

En las L2, las transacciones no se dirigen hacia a la mempool pública, sino que se concentran en el contrato del rollup en cuestión. En definitiva, lo que sucede es que se transfiere el poder de la extracción de MEV desde los miners / validators en L1 hacia el secuenciador en L2.

## 'Fair Ordening' en blockchain

Dos definiciones opuestas demarcan el orden de las transacciones en un sistema P2P:

-   **Send-order-fairness**. En un mundo utópico, el orden de las transacciones en un bloque se darían por el orden específico en el que los usuarios envían sus txs. Por ejemplo, si un usuario envió una tx1 antes que otro usuario haya enviado una tx2, la tx1 siempre debería procesarse antes que la tx2.

Lo ideal sería que las transacciones se asienten en la red en el mismo orden en que fueron creadas y enviadas a los nodos. Pero dado que en una blockchain el sistema se encuentra distribuido geográficamente, no se puede capturar tal orden.

En la práctica, este escenario es **difícilmente alcanzable**. Los nodos que conforman la red pueden recibir las transacciones de los usuarios en tiempos diferentes, debido a la ubicación geográfica de ambos (usuarios + nodos) y su respectiva latencia. Por lo tanto, cuentan con diferentes visiones del estado de la blockchain en un momento específico. Cada nodo puede recibir transacciones en momentos ligeramente diferentes, derivando en un orden distinto.

-   **Receive-order-fairness**. Lo que finalmente termina por suceder es que el orden de las transacciones se define observando cuándo la mayoría de los nodos recibieron las transacciones individualmente, de forma local. Esta visión corresponde al concepto de FIFO (First-In-First-Out o 'primero en entrar, primero en salir')

Cuando suficientes nodos reciben transacciones y logran un consenso sobre el orden de las mismas, éste ordenamiento será el del estado final. Por ejemplo, **si suficientes nodos** reciben una transacción tx1 antes de otra transacción tx2, entonces tx1 debe ordenarse antes que tx2 en en el estado final.

## Fair Sequencing Services, por Chainlink:

El concepto que busca implementar FSS es el de 'descentralizar' el ordenamiento de bloques: en lugar de contar con una sola entidad centralizada que mantenga el poder de crear bloques, el secuenciador es reemplazado por un comité de nodos de Chainlink (**DON***), los cuales deciden colectivamente cómo se ordenan las txs en los bloques. La red de oráculos en CL recolectan las transacciones y luego llegan a un consenso sobre su orden, en vez de que un solo líder lo dictamine. Hay dos formas en que los nodos recopilan las txs:

-   Los usuarios pueden enviar sus txs normalmente para que se asienten en la mempool pública, y los nodos del comité de Chainlink observan la mempool y recopilan los txs desde allí.
-   Los usuarios pueden enviar sus txs directamente a los miembros del comité, y luego éstos deciden cómo se ordenan las txs.

***Decentralize Oracle Network**

Los usuarios envían las transacciones **simultáneamente a múltiples nodos**, y el contenido de las transacciones que envían a los nodos de CL **se encuentran cifrados**, de modo que el contenido de la transacción se revele sólo después de que se haya llegado a un consenso acerca del orden de las transacciones.

## Secure causal ordering en FSS:

Ningún nodo puede ver el contenido de la transacción antes de que se llegue a un consenso sobre el orden de la misma. Las transacciones se ordenan y secuencian antes de que alguien pueda observar su contenido. Es válido aclarar que el SCO en realidad no especifica cómo se deben ordenar las txs en sí, solo especifica que una vez ordenadas las txs, se pueden descifrar.

**¿Cómo se implementa?**

-   Las txs se transmiten al comité en forma encriptada bajo una private key que pertenece al comité de nodos, con su correspondiente public key
  ![image (2).webp](/uploads/image_2_354223b712.webp)
-   El comité ordena las txs cifradas en función de su llegada a la mayoría del DON
  ![image (5).webp](/uploads/image_5_dfe1d21c21.webp)
-   Después que se haya llegado a un consenso sobre el orden, se descifran. Cuando se revela el contenido de la transacción, es demasiado tarde para front-runearlas.
  ![image (3).webp](/uploads/image_3_39ba959be8.webp)

Siempre habrá actores primarios con la potestad de re-odernar transacciones. Lo que se logra con este mecanismo es transferir este poder. De los miners en L1 → secuenciador centralizado en L2 → nodos de Chainlink.

## La paradoja de Condorcet

La '[paradoja del voto](https://es.wikipedia.org/wiki/Paradoja_de_Condorcet#:~:text=La%20paradoja%20de%20Condorcet%20ilustra,capacidad%20de%20guiar%20la%20elecci%C3%B3n.&text=Las%20diferentes%20variantes%20del%20m%C3%A9todo,para%20seleccionar%20a%20un%20ganador.)' es un resultado de la teoría de la elección social que indica que las preferencias de voto colectivas no cumplen el supuesto de transitividad aunque las preferencias individuales si lo cumplan

El supuesto de transitividad establece: dadas tres alternativas (A, B y C) se cumplirá el supuesto de transitividad si se dan los siguientes resultados:

-   **A** es mejor que B
-   B es mejor que **C**

Entonces, por el supuesto de transitividad, podemos afirmar que A es mejor que C.

Aplicando la paradoja al ordenamiento de las txs, en el siguiente escenario encontramos 3 nodos: **A, B y C**. Hay 3 usuarios, los cuales envían 3 transacciones - **tx1, tx2 y tx3** - a todos los nodos.

-   El nodo A recibe transacciones en el orden tx1, tx2, tx3
-   El nodo B recibe transacciones en el orden tx2, tx3, tx1
-   El nodo C recibe transacciones en el orden tx3, tx1, tx2

Ahora, 2 nodos (A y C) recibieron **la tx1 antes que la tx2**, 2 nodos (A y B) recibieron la tx2 antes que la tx3 y 2 nodos (B y C) recibieron **la tx3 antes que la tx1**. Las 3 visiones de los 3 nodos son diferentes, y paradójicamente, todas son correctas. No hay un único camino que satisfaga a todos los usuarios ya que el orden final dependerá del tiempo en que los nodos vieron las txs de los 3 usuarios.

Un protocolo que quiera implementar un mecanismo de 'fair ordering' deberá incluir tx1 antes que tx2; tx2 antes de tx3; y tx3 antes que tx1 en el estado final, un escenario visiblemente contradictorio.

## La imposibilidad de un orden justo

El argumento principal sobre la imposibilidad de un orden justo en blockchain es que diferentes nodos pueden recibir la misma transacción de un usuario en tiempos diferentes de llegada, lo que deriva en **perspectivas diferentes** sobre el orden de las transacciones.

En un escenario en donde el threshold del consenso debe llegar a 2⁄3 de los nodos, y la mayoría necesaria de los nodos para llegar a un acuerdo se encuentran en Europa, un actor o entidad con la suficiente motivación económica puede establecerse geográficamente (o bien rentar espacios) lo más cercano posible de los miners / validators, o dicho de otra forma: elegir un punto medio entre la mayoría de los nodos. Lo que en TradFi se conoce como '**Collocation**', es también factible en blockchain.

Si un usuario envía su tx primero, pero luego este actor/entidad ubicado mucho más cerca de la mayoría de los nodos envía su tx después que el usuario, su transacción **muy probablemente** sea procesada por encima de la nuestra debido a la latencia, y las transacciones que envíe siempre se verán propagadas primero por encima del retail user, siéndole a éste imposible competir.\
Los usuarios más alejados geográficamente de la mayoría de los nodos contarán con una desventaja sustancial frente a los demás. Incluso si su transacción se envió primero, no importará.

Ya que las transacciones que contiene un bloque son limitadas (**blocksize**), los usuarios deben contar con una forma de comunicarle al miner que desean que su tx sea procesada primero; en consecuencia, los miners deben contar con una forma de priorizar unas transacciones por encima de otras. Generalmente, los miners ordenan las txs de forma descendente de acuerdo al fee ofertado por los usuarios.

Actualmente en Ethereum, los usuarios para asegurarse un espacio en el siguiente bloque participan en una especie de 'subasta' en la cual ofrecen el mayor gasfee que están dispuestos a pagar al miner para que su transacción sea procesada e incluída por encima de las demás en la red.

Lo que potencialmente puede suceder en la práctica si se implementa un mecanismo de 'fair ordering' en donde este sistema de 'subasta' es desechado, es que los searchers, al no poder sobornar a los miners / validators para contar con un espacio prioritario en el siguiente bloque, terminen por spamear sus txs a los nodos para aumentar las chances de capturar el MEV de forma probabilística, derivando en un aumento del costo del gas en la red y afectando a los usuarios normales.

Tomemos el ejemplo de redes como [Polygon](https://polygonscan.com/address/0x84e5bc3df0df0f543648f250443c6f4077218312) o [Solana](https://solscan.io/account/HbqevNcdN1mrNbDKAXYDsSrJnCuPwzfcfZ2CMFSKxVoU), en donde si bien no se implementa FSS, las transacciones son muy económicas y el costo marginal de spamear la red es irrisorio. La estrategia por excelencia para intentar extraer MEV en redes con un gasfee bajo, es spamear la chain enviando la misma tx una y otra vez hasta que su tx sea finalmente procesada. Aunque éstas txs duplicadas sean revertidas, igualmente consumen un espacio inútil en el bloque, congestionando la red y creando un bottleneck entre los usuarios normales y los bots que intentan extraer MEV. Una pésima experiencia de usuario.

![have a title](/uploads/image_6_60246b2cd7.webp "MEV bot spameando txs")

`¿Cómo puede, entonces, existir el concepto de 'order fairness' en web3 sin perjudicar sistemáticamente a unos usuarios y beneficiar enormemente a otros?`

El concepto de 'order-fairness' en redes distribuidas geográficamente es **subjetivo**, no es una cuestión de semántica. No hay una única verdad en la visión de los nodos sobre el estado de la blockchain en un momento específico, ya que todos los nodos cuentan con perspectivas diferentes sobre un mismo estado, y todas son potencialmente correctas.

![image (4).webp](/uploads/image_4_01ecacfa39.webp)

## FSS como solución temporal en L2:

Ciertamente, en un rollup diseñado como el de Arbitrum, puede ser una mejor implementación contar con una red distribuida de nodos como lo propone FSS - aunque al contrario de lo que su nombre indica, lejos esté de ser 'justo' - para ordenar las transacciones en L2, en vez de concentrar este poder en un solo actor por parte de la empresa.

Claro está que el mecanismo de FSS lejos se encuentra de ser una solución a largo plazo, sino que más bien puede actuar en lo inmediato parcheando el problema de centralización en un solo secuenciador, mientras se desarrolla una idea para descentralizar el secuenciador de una forma realmente eficaz.

Cierto también es que, al implementar FSS, el único token necesario para 'descentralizar' el secuenciador termina siendo LINK, sin necesidad que Arbitrum lance un token propio para incentivar a correr un secuenciador.

#### Further reading:

-   [Ari Juels: Keynote on Chainlink Fair Sequencing Services](https://www.youtube.com/watch?v=wGBilgN-KHo&ab_channel=Chainlink)
-   [Fair Sequencing Services](https://blog.chain.link/chainlink-fair-sequencing-services-enabling-a-provably-fair-defi-ecosystem/)
-   [Chainlink 2.0 - Whitepaper](https://research.chain.link/whitepaper-v2.pdf)
-   [Order-Fairness for BFT](https://eprint.iacr.org/2020/269.pdf)
-   [Rollup tokens are coming](https://newsletter.banklesshq.com/p/rollup-tokens-are-coming)




Una introducción a las 2 escuelas de pensamiento sobre el abordaje del MEV en redes distribuidas y porqué no existe tal cosa como un "orden justo" o preestablecido para transacciones en la Web3.

medium_1.png

small_1.png

thumbnail_1.png

1.png

MEV - Subastas vs Mitigación: ¿Por qué no existe el fair ordering en Web3?

Originado vía mirror: [link a la publicación original](https://mirror.xyz/defilatam.eth/JUvjMMrlSzgEgdWBFafnMkIydf_6wi1zQLfsVXqji0k).

### Glosario

**Sistema de gauge**: mecanismo por el cuál la gobernanza dirige o "calibra" a qué pools (y en qué proporción) entregar emisiones pautadas de un token, a modo de incentivos. En la vida real se puede entender como una tubería que pasa agua constante con diferentes grifos/llaves el cual podemos abrir y cerrar a donde queramos que salga en agua. En DeFi, los tokens están a disposición a ser votados a cual pool beneficiar con incentivos.

* * * * *

Como las emisiones del token de Solidly están a menos de diez días por empezar, pensamos que sería un buen momento para explicar Solidly de una forma resumida y con suerte, fácil de entender.

## Que es Solidly?


**Solidly es un exchange descentralizado**, AMM basado en Uniswap V2. Permite realizar intercambios entre dos tokens a través de un pool de liquidez (LP) de forma totalmente descentralizada. A diferencia de Uniswap V2, el primer lanzamiento de Solidly permitirá también intercambios con bajo slipagge entre activos relacionados como intercambios entre stablecoins.

Quienes provean su liquidez en un pool de Solidly *whitelisteado* reciben recompensas por *liquidity mining* (emisión) en forma de SOLID: el token de gobernanza y que otorga derechos para recibir renta de los ingresos del protocolo.

## El token


**El token SOLID existe en dos formas**: el principal **SOLID**, intercambiable pero no otorga poder de voto en la gobernanza ni derecho a los ingresos del protocolo. El otro, **veSOLID, que es la forma lockeada de SOLID, en forma de NFT**. "ve" significa voto en custodia, un nuevo y popular paradigma en DeFi, que fue implementado por primera vez por el protocolo Curve Finance.

Si posees SOLID y deseas participar en la gobernanza de Solidly y recibir una parte de los ingresos del protocolo, bloquee sus SOLID y conviertalos en veSOLID. Los bloques pueden durar entre un mes y cuatro años y se puede extender en cualquier momento. Diferentes longitudes de bloqueo implican diferentes cantidades de veSOLID:

1 SOLID bloqueado durante cuatro años = 1 veSOLID

1 SOLID bloqueado durante dos años = 0,5 veSOLID

1 SOLID bloqueado durante seis meses = 0,125 veSOLID

Tu saldo en veSOLID decae linealmente con el tiempo si no lo extiendes. Una vez que caduque el bloqueo, puedes retirar tu SOLID. Una vez que la posición de SOLID bloqueada se crea, recibes comisiones de intercambios (ingresos del protocolo) de los *gauges* por los que votó (tal y como en Curve dónde se vota a qué pools dirigir la nueva emisión de CRV), un boost por dirigir las emisiones de SOLID; pero hay más.

## ve(3,3)


Otro cambio importante con respecto a los modelos "ve" existentes es **el concepto de ve(3,3), donde los que bloquean tokens también reciben una parte de las emisiones en función del suministro circulante**. La idea detrás de este cambio es evitar la dilución de los primeros que decidieron bloquear sus tokens.

El porcentaje de emisiones que reciben los que bloquean sus tokens es el siguiente:

veSOLID.totalsupply() / SOLID.totalsupply()

Esto crea una teoría de juegos interesante, ya que **mientras más personas bloqueen sus tokens, reducirán la cantidad de SOLID otorgado a los proovedores de liquidez en una semana determinada**.

Los que bloquean su SOLID incrementan sus *holdings* (participaciones) proporcionalmente a las emisiones semanales. Esto hace que la propuesta de valor por bloquear los tokens sea muy atractiva ya que hacer ésto no diluye tu participación con respecto a la emisión general de nuevos tokens SOLID.

## Los fees

En Solidly, todas las comisiones por trading se destinarán a los usuarios que votaron por el respectivo pool-gauge. Los proveedores de liquidez reciben tokens SOLID y las comisiones se otorgan a quienes votaron por ello**, lo que crea un ciclo de retroalimentación positiva en el que el pool que genera muchas comisiones atraerá más votantes y por ende más incentivos en SOLID.

**Si el pool no está en la lista blanca y sin gauge, los fees van directo a los proveedores de liquidez**, como ocurriría en otros DEXes. Cualquiera puede desplegar un LP con gauge si ambos tokens forman parte de la lista blanca de la gobernanza.

## Emisiones

Varios mecanismos usados en Solidly se toma prestado de lo implementado en Curve Finance. El principal es el sistema de *gauges,* que ha estado ganando atención gracias a las llamadas "*curvewars*" y sobornos en Convex. Habiendo depositado liquidez en un pool en específico, los proveedores podrán stakear sus LP tokens y recibirán las recompensas correspondiente según el gauge, que es donde comienzan a recibir las emisiones de SOLID.

El concepto es simple, **cada semana se distribuirán SOLID tokens a modo de emisión a partir de 20.000.000 por semana, decayendo a razón de un 2% por semana**. A partir de la semana 167, lasemisiones disminuyen aún más a medida que el suministro total alcanza los mil millones de SOLID. **Los tenedores de veSOLID deciden qué proveedores de liquidez reciben esas recompensas**. Tener el poder de dictar qué grupos recibirán nuevos tokens SOLID es extremadamente valioso para los protocolos que desean profundizar su liquidez en cadena. Esto es igualmente importante para los titulares de ve, que tienen interés en dirigir las emisiones hacia los pools que generan reciben más fees, para ellos mismos.

Las emisiones de nuevos SOLID tokens se actualizan semanalmente los jueves a la medianoche UTC.

## Boosting

Al igual como pasa en Curve, además de decidir dónde deben asignarse las nuevas emisiones de SOLID, los que lockean sus tokens pueden también boostear sus recompensas en SOLID. **Basado en que tanto veSOLID un usuario posee, ellos pueden recibir hasta 2.5x mas en recompensas de SOLID**. Cada gauge tiene un saldo que puede ser calculado por la siguiente fórmula:

![usb0GkB7CINFvYid-lU8T.webp](/uploads/usb0_Gk_B7_CIN_Fv_Yid_l_U8_T_6346ddf637.webp)

Y esta es la principal razón detrás del éxito de Convex, ya que permitió a los proovedores de liquidez obtener recompensas aumentadas sin la necesidad de mantener un bloqueo “ve-lock” de 4 años.

## Sobornos (bribes)

El concepto de *bribes* o sobornos fué popularizado por Convex, que llegó a controlar una gran parte del poder de voto en Curve. A medida que los usuarios perseguían altas recompensas en CRV, los protocolos se dieron cuenta de que podían hacer crecer el uso de su protocolo y liquidez en cadena sobornando a los tenedores de veCRV para que votaran por su pool.

En Solidly, **cualquiera puede sumar sobornos a un determinado gauge y aquellos que votan por él pueden reclamar estas nuevas recompensas**.

Solidly también **introduce el concepto de voto negativo *o en contra* que permite a los usuarios evitar que las emisiones vayan a parar a un pool en específico**.

## Lanzamiento

Solidly ya se lanzó y se espera que las emisiones de SOLID comiencen el 24 de febrero, aunque Andre Cronje advirtió que puede ocurrir un re-despliegue del protocolo si alguna vulnerabilidad crítica es encontrada antes de esa fecha.

Aquellos que dessen votar sobre las emisiones para el lanzamiento deberán hacerlo antes de la medianoche UTC del día 24 de enero.

Protocolo: <https://solidly.exchange/>

Averiguá que pools recibirán emisiones del token SOLID: <https://solidly.exchange/vote>

## Misceláneos (por joxes.eth)

Inicialmente, Solidly propone 2 tipos de pools: variable y stable. Los pools en modo variable sigue la misma ecuación invariante usada por uniswap (xy=k, en verde) para proveer liquidez*.* En el modo stable, se introduce la formula x^3*y +y^3*x=k (en azul), que ofrece liquidez más concentrada en el intervalo central, pero con alto slipage a medida que la liquidez se desequilibra.

![have a title](/uploads/7h_P4_Nqwd_B_Viny_Jo_X9_Wbe_03ee040a64.webp "Verde: Uniswap y Solidly (modo variable); Azul: Solidly (modo estable)")

Dado que es imposible decidir dónde alocar los incentivos en SOLID sin siquiera haberse lanzado el token, es indispensable determinar una distribución inicial de las mismas. Andre Cronje consideró como justó **distribuir un veNFT al top 25 de protocolos DeFi en Fantom por TVL de acuerdo a una snapshot tomada el 23 de Enero**.

Los proyectos merecedores del veNFT son: Multichain, 0xDAO, SpookySwap, Yearn Finance, veDAO, Curve, Tomb Finance, Geist Finance, Beefy Finance, RenVM, Synapse, Radial, Iron Bank, SpiritSwap, Scream, Abracadabra, SushiSwap, Frax, Reaper Farm, Beethoven X, Hundred Finance, Morpheus Swap, Saddle, Liquid Driver y Tarot. Cada veNFT representará una cantidad específica de SOLID tokens. En este sentido, **dependerá completamente de estos proyectos y su gestión sobre el veNFT lo que decidirá la dirección de los incentivos y crecimiento del ecosistema alrededor de Solidly**.

Será interesante ver como Solidly se convierte en el primex DEX que alinea los incentivos para premiar los pools con mayor volumen de intercambio y generació de fees en lugar de la liquidez depositada, como siempre ocurría en el resto de los programas de liquidity mining de otros protocolos.

Fuente: github.com/andrecronje/solidly

Traducción al español de “All about Solidly” de Solidex (incluye técnica de paráfrasis para un mejor entendimiento y una sección extra con más datos).

medium_Diseño sin título (26).png

small_Diseño sin título (26).png

thumbnail_Diseño sin título (26).png

Diseño sin título (26).png

Todo sobre Solidly

Aunque la extracción de MEV se concentra mayormente en el ecosistema de Ethereum, no es exclusiva de la red. En diversas blockchains encontramos un mundo de posibilidades por explorar y explotar. En esta segunda entrega de [MEV ](https://www.defilatam.com/blog/introduccion-al-mev-mev-series-vol-1)Series nos adentramos en el ecosistema de Solana para explorar las diferencias con Ethereum en cuanto a la extracción de valor y las posibilidades que brinda la arquitectura de construcción en la red.

### Mecanismo de transacciones en Solana

Solana es mempool-less, ya que las transacciones que reciben los validadores se ejecutan al instante, llevando a tener 50.000 transacciones por segundo. A este mecanismo lo llaman **Gulf Stream**. Los validators en Solana pueden manejar hasta 100k transacciones en su mempool local. Esto combinado a un throughput de 50k TPS, lleva a que los validators ejecuten la totalidad de transacciones en su mempool en cuestión de segundos.

Dado que cada validator en la red conoce el orden de los próximos líderes, los clientes y validators envían las transacciones que les llegan al validator que se sabe que será líder  antes de que efectivamente lo sea. Esto permite a los validators ejecutar transacciones con anticipación.

Los validators envían las transacciones que les llegan directamente al líder actual y al próximo líder  en la secuencia del líder schedule para que la incluya en sus slots, en vez de propagar las transacciones de forma aleatoria como en Ethereum. Si el líder actual no puede procesar todas las transacciones, las reenvía a los próximos validadores. [Explicación detallada acá](https://medium.com/solana-labs/gulf-stream-solanas-mempool-less-transaction-forwarding-protocol-d342e72186ad).

### Propagación de transacciones: Turbine Block

![vJH3Y_UjnNI-oci1nKzl5.webp](/uploads/v_JH_3_Y_Ujn_NI_oci1n_Kzl5_20c9635818.webp)

Solana se divide en **clusters**. Los clusters son un conjunto de validadores que trabajan juntos para procesar transacciones. En la red, pueden coexistir muchos clusters en simultáneo. Las transacciones enviadas al cluster incorrecto son rechazadas.  [Explicación detallada acá](https://docs.solana.com/cluster/overview).

Cada validador retransmite las transacciones a un grupo de pares que llaman Vecindario. Se puede entender a la red como un árbol de vecindarios, en donde cada uno retransmite lo que le llega al vecindario que le corresponde. **Cada nodo es responsable de compartir cualquier dato que reciba con los otros nodos en su vecindario, además de propagar los datos a un conjunto de nodos en otros vecindarios**. De esta manera, cada nodo sólo tiene que comunicarse con los nodos a los que retransmite los datos.

### Slots y transacciones en la red

Solana avanza en epochs, los que tienen una duración de 2-3 días, y cada epoch consta de un conjunto de bloques (~432k), con un blocktime de ~400ms. Cada validator tiene el deber de votar en cada bloque, y ya que los votos en Solana son on-chain y cada voto es una transacción, la mayoría de las transacciones que se encuentran en un bloque son votos de validators. **Por cada voto correcto que emiten, obtienen recompensas.**

![W6d8hQhqZwc3OJF-Z3h9i.webp](/uploads/W6d8h_Qhq_Zwc3_OJF_Z3h9i_749a9f9048.webp)

Si bien los validadores que serán líderes se conocen con mucha anticipación en la red, concretamente 2 epochs anteriores, el líder escucha las transacciones que incluirá en su bloque solamente cuando le toca su turno, no antes.

Los validadores están programados para ser líderes y validar un set de transacciones. Por el líder schedule, cada validator puede calcular individualmente quien será el próximo líder en la secuencia. El líder puede escuchar las transacciones por N slots antes de ser efectivamente validador, **pero no tiene la certeza de que validará esas transacciones, porque éstas pueden haber sido incluidas por otro líder previamente**. Entonces, éste conoce concretamente qué transacciones incluirá solamente en su turno.

Debido a lo anterior, no puede haber 2 líderes creando bloques al mismo tiempo. Es posible, pero ya que todos los nodos en la red saben quien es el próximo líder en la secuencia, no van a votar al que esté intentando crear ese bloque malicioso. Si no fuiste ‘elegido’ como líder para crear bloques, nadie te votará y directamente rechazan ese bloque.

### Costos y ganancias de un validador

El hardware necesario para configurar un validador es muy alto. Algunos de los requerimientos comprenden 128GB de RAM y una velocidad de 1 Gbit/s, entre otros.

Además de los costos de hardware, los validadores deben incurrir en gastos para cubrir los costos de votar bloques de los demás validadores (**vote credits**). Los validadores obtienen vote credits cada vez que envían un voto sobre un bloque de la red finalizado, cada voto correctamente emitido representa 1 crédito. Los validadores que votan con más frecuencia son recompensados con más créditos. Votar incorrectamente, resta créditos.

Actualmente estos costos son de 1.1 SOL por día, arrojando un gasto de ~$6.6k por día a los precios actuales; por lo que si un validador no consigue atraer suficientes delegantes a su stake y no cuenta con un self-stake para cubrir este costo, entrará en pérdidas, ya que en los ingresos que obtiene el validator por asegurar la red, **se incluye la recompensa por votos correctamente emitidos**, y lo que gana por crear el bloque. Un validador necesita suficiente participación para ganar más en recompensas de lo que gasta en votar.

En Solana, los validadores pueden ganar muchas más recompensas como consecuencia de votar correctamente a tiempo, que lo que obtienen por ser líderes y procesar bloques en la red. Por cada bloque creado, **se llevan el 50% de los fees de las transacciones** (el otro 50% de SOL es quemado). Así, los validadores están incentivados para incluir tantas transacciones como sea posible dentro de su tiempo límite.

En esto, Solana se diferencia de otras blockchains, en las cuales si un minero/validador no procesa bloques, no obtendrá ganancias.

![OsVYqsvTPZ7xYSo5t1Cc4.webp](/uploads/Os_V_Yqsv_TPZ_7x_Y_So5t1_Cc4_39a0b2251b.webp)

**Skip rate:** es el porcentaje de slots donde un validador no cumple con los requisitos de la network. Básicamente cada vez que un líder se “pierde” la oportunidad de validar un bloque por no mantener los estándares de la network respecto de la velocidad, van a ir acumulando la cantidad de “skips” que hizo en la network y esto va a representar la fiabilidad que uno puede tener en este validador. En este sentido, la latencia que los nodos tienen entre sí juega un papel fundamental, ya que si un validador se encuentra muy lejos de la mayoría, probablemente cuente con un porcentaje mayor de skip rate por la latencia entre éstos, en consecuencia no produciendo bloques.

### Dificultades que comprenden la extracción de valor

Ya que no hay mempool, no hay un lugar al que los bots de arbitraje puedan acceder en busca de transacciones a la espera de ser confirmadas. Siendo así, los únicos que tendrían la potestad de ver las transacciones pendientes son los validadores, en consecuencia cuentan con la posibilidad de reordenar transacciones, pero esto conlleva varias dificultades:

- Las transacciones en Solana son deterministas, esto quiere decir que todos pagan lo mismo por cada transacción. Si bien los fees pueden variar bloque a bloque, son deterministas en el sentido en que las transacciones específicas a un blockhash son similares, y se pagan de acuerdo con la configuración de ese bloque en particular. Los fees varían levemente de acuerdo al protocolo y la complejidad, pero en general rondan los $0,001.

- No es posible modificar el gas artificialmente. Esto invalida la posibilidad de una gas war entre searchers. Directamente anula la posibilidad de bribear al validador enviando una transacción con un fee alto para que contar con prioridad de ordenamiento por sobre los demás.

- No existe (actualmente) una variable similar a block.coinbase en Rust que retorne la address del líder actual para bribear directamente al líder enviándole una transacción.

- Cada líder cuenta con un tiempo límite de 400ms para incluir 4 slots en la blockchain, y luego la oportunidad para validar bloques se transfiere inmediatamente al líder subsiguiente. Tienen una ventana de tiempo muy corta para ejecutar arbitrajes.

- Cada validador es responsable de armar su secuencia de PoH, completando el proceso de VDF. Al finalizar la secuencia de PoH, las transacciones (y por lo tanto, los slots) quedarán estampadas (timestamping). La transacción que procesa el validator incluye el hash del PoH de la transacción anterior y la firma del usuario, por esto no será posible reorganizar bloques.

### Ciclo de las transacciones en Solana

![Z_It1TTOKLQLktJc318Rl.webp](/uploads/Z_It1_TTOKLQ_Lkt_Jc318_Rl_459e46a5fb.webp)

- La dapp crea una transacción para comprar algunos tokens
- La dapp envía la transacción a la wallet del usuario para que sea firmada
- El usuario firma la transacción y la envía de nuevo a la dapp
- La dapp toma la transacción firmada por el usuario y la envía al nodo especificado en la dapp
- El nodo envía las transacciones que recibe al próximo líder validador en la secuencia
- El líder recibe las transacciones a procesar, verifica las firmas y elimina las transacciones maliciosas, procesa las correctas, las marca con un hash tick (PoH) y las propaga al resto de la red. La diferencia entre el validador y el líder es que si un validador observa una transacción incorrecta, no puede simplemente eliminarla como lo haría el líder, porque eso haría que el hash de PoH cambie. En cambio, rechaza todo el bloque.

### Actores que entran en juego en este escenario

**Los nodos** mantienen las transacciones que les llegan en sus servidores. El nodo que recibe las transacciones y luego las envía al líder, tiene la posibilidad de revisarlas. Aunque no tienen la potestad de reordenar ni decidir qué transacción se incluye primero, pueden leer oportunidades con anticipación y retrasar la propagación de transacciones hasta enviar sus propias transacciones. Con una latencia extremadamente baja con los nodos y el validator, podrían enviar su transacción primero.

En la medida que **los validators** puedan ser conocidos/calculados con tanta anticipación (2 epochs), se abre la posibilidad de coludir entre éstos para generar estrategias y extraer valor en múltiples bloques secuenciales.

### MEV - front running y reorgs

Bob, Alice y Josh envían sus transacciones. El líder recibe el conjunto de transacciones a procesar, incluidas las transacciones de Bob y Alice que **cuentan con el mismo blockhash**, y la de Josh que tiene un **blockhash diferente** al de Alice y Bob.

El líder puede incluir su propia transacción antes, después y entre las de Alice/Bob/Josh. Al armar el VDF, puede incluso reordenar la transacción de Alice para que pase antes que la de Bob, pero no puede hacer que la transacción de Josh suceda antes que la de Alice y Bob, porque tienen blockhash diferente. Si la transacción no se confirma a tiempo (<32 blocks), se invalida y se tendrá que firmar nuevamente con un blockhash más reciente.

![Qyz52B1iejvyel1V2oHrW.webp](/uploads/Qyz52_B1iejvyel1_V2o_Hr_W_9b9f5feaa6.webp)
![d6Zed5hvyfq5CcqQr-S3K.webp](/uploads/d6_Zed5hvyfq5_Ccq_Qr_S3_K_d0f8b67a31.webp)
![WXNppXiFcODTSYHL646l0.webp](/uploads/WX_Npp_Xi_Fc_ODTSYHL_646l0_de6c0cb055.webp)

### Posibles escenarios que se pueden dar

- Un validador encuentra la forma de deployar un bot de arbitraje lo suficientemente rápido como para extraer MEV. Debido a esto, ofrece un porcentaje mayor de recompensa como incentivo, prometiendo extraer MEV y atrayendo a los usuarios para que deleguen con él, y así aumentar sus chances de ser elegido como líder. Los usuarios estarían incentivados a delegar en su pool, al ser uno de los pocos (o el único) que dispone de este mecanismo, y por lo tanto, puede ofrecer un interés mayor que los demás pools como incentivo.

Su stake crece, y aumentan sus chances de ser elegido validador y extraer MEV en cada ocasión → Mayor centralización. ‘*the rich get richer*’. Esto podría derivar en que los grandes pools de stake sean mayormente elegidos como líderes para incluir bloques, permitiendo la extracción de MEV en múltiples bloques concentrados en una sola entidad.

- Ahora mismo no hay un ‘*priority fee*’ con el cual se pueda incentivar a los validadores para que procesen nuestra transacción primero por encima de otras, ya que como explicamos más arriba, los fees son deterministas en la red.

Esto es un poco confuso debido a que en los [documentos oficiales](https://docs.solana.com/implemented-proposals/transaction-fees) se establece que “*Si la red está congestionada, el slot líder puede priorizar las transacciones que ofrecen los fees más altos*” y que “*En la primera implementación de este diseño, el único parámetro de fee es lamports_per_signature. Cuantas más firmas necesite verificar el cluster, mayor será el fee*”

*Claramente se deja entrever que el usuario puede incluir más firmas en las transacciones que efectiviza, en consecuencia haciendo subir el fee que paga artificialmente. **Los fees son proporcionales a las firmas necesarias para procesar la transacción**, no importa la cantidad de instrucciones que requiera dicha transacción para interactuar con X protocolo.

La unidad básica de medida de SOL es llamada ‘*lamports*’. 1 lamport = 0.000000001 SOL.

Cada firma que incluye el usuario en la transacción es igual a 5000 lamports. Por lo tanto: a más firmas incluidas en la transacción → más alto el fee → el validador puede escoger qué transacción tiene prioridad, en base a sus incentivos económicos.

- Un validator detecta MEV en las transacciones que debe incluir en sus slots. Para apropiarse de ésta, decide censurarla y colocar su transacción en primer lugar.

Ej: en un contexto de baja generalizada en el mercado, se ejecutan liquidaciones en los vaults de Parrot después de una actualización en los precios del oráculo. El líder  actual detecta esto y decide procesar primero su transacción para adueñarse de tales liquidaciones.

- Ya que el validator es el último actor en decidir quién se queda con la oportunidad de arbitraje en sus slots, y teniendo en cuenta que se conocen con mucha anticipación se podría generar un mecanismo de off-chain bribes en donde los validators vendan el blockspace o se genere una especie de dark-mempool en paralelo para vender esa información privilegiada. Igualmente, esto solo sería posible si los searchers cuentan con una latencia extremadamente baja con el validator.

#### Posibles soluciones

**Mitigar el MEV
**Disminuir el tiempo de rotación entre líderes. Los líderes cambian cada 2.5 aproximadamente. A menor tiempo → Menor probabilidad

Disminuir el blocktime. Menor blocktime → Mayor dificultad para extraer MEV.

Esto solo es posible si todos los clusters se actualizan. Una vez que así sea, se podría upgradear el blocktime. Pero esto aumentaría la centralización al ser necesaria una inversión mayoritaria en hardware para alcanzar niveles de blocktime más bajos de los demás validators.

**Democratizar la extracción**

La visión con la que cuenta Flashbots para democratizar el MEV parece ser la más justa en este caso. Nivelar la extracción de valor de los validators para que todos puedan acceder y no tienda a centralizarse en los que encuentren la forma de extraer valor. Separar los roles en la construcción de blocks como en eth2 y que se venda el blockspace más rentable.

El problema en separar los roles entre block proposer/producer sería, de nuevo, la latencia. Con el blocktime de 400ms sería cuasi imposible enviar bundles al validador exitosamente, incluso estando en el mismo estado/región.

### Conclusión:

Solana está creciendo a pasos agigantados, el crecimiento del capital bloqueado y el desarrollo de la red atraen a varios arbitrajistas en busca de oportunidades (todavía) por explotar. Si bien este es un tema poco explorado en la red, podríamos llegar a verlo en el ojo de la tormenta dentro de relativamente poco tiempo.

Explicadas las posibles razones y teniendo en cuenta la dificultad que conlleva deployar bots de arbitraje al igual que sucede actualmente en Ethereum, la extracción de MEV podría verse centralizada en los pocos actores que logren verlo efectivizado. Por otro lado, las barreras de entrada para esto son excesivamente altas: los costos de correr (y mantener) un nodo validador y la complejidad/robustez del lenguaje Rust en comparación a Solidity llevarían a que sea difícil democratizar.

Este ‘problema’ podría posponerse, pero definitivamente será un enigma a tener en cuenta en el futuro considerando que cuando hay una gran cantidad de dinero en juego, los searchers lo seguirán de cerca.

Gracias a [@0xPEPO](https://twitter.com/0xPEPO), [@martintriay](https://twitter.com/martriay) y [@josebaredes](https://twitter.com/josebaredes) por los comentarios y sugerencias recibidas.

Fuentes:

- [Solana validator 101](https://jito-labs.medium.com/solana-validator-101-transaction-processing-90bcdc271143)

- [Solana - documentos oficiales](https://docs.solana.com/cluster/leader-rotation)


Aunque la extracción de MEV se concentra mayormente en el ecosistema de Ethereum? 

MEV en Solana: Un panorama temprano

La seguridad en PoW recae en las recompensas a lo mineros x bloque creado y los incentivos para los mineros 

medium_12.png

small_12.png

thumbnail_12.png

12.png

PoW vs PoS: Dos consensos en contraste

1. En blockchains tradicionales como Bitcoin o Ethereum, el problema de escalar la red a medida que crece su adopción se agrava cada vez más.

En éstas redes, cada nodo es responsable de procesar, validar y guardar todos los datos de la blockchain, por lo que actualmente se ven limitadas a ofrecer entre 10 a 20 transacciones por segundo. Cada bloque que se crea, puede contener un número máximo de transacciones, y cada bloque nuevo es añadido a la red cada cierto tiempo (esto es llamado block time). En Bitcoin, se crea un nuevo bloque cada 10 minutos, y en Ethereum, cada 10-20 segundos.

Éstas limitaciones combinadas con la alta demanda por parte de los usuarios de la red para incluir transacciones en los acortados bloques, llevan a que el costo de transaccionar sea muy elevado.

# Sharding - Divide y reinarás

Una de las visiones para hacer escalable una blockchain es mediante el sharding:

La idea detrás de este mecanismo busca partir la blockchain en varias sub-chains llamadas shards, las cuales cuentan con el mismo mecanismo de consenso, la misma arquitectura de construcción de bloques y la misma capacidad. Mediante esta dinámica, en vez de ejecutar una sola blockchain, se ejecutan varios shards en paralelo, conectados entre sí.

Cada shard cuenta con su propio conjunto de validators/miners que crean bloques por separado. Así, no es necesario que absolutamente todos los nodos en la red validen todos los bloques que se crean, sino que cada set de nodos valida las transacciones del shard al que fue asignado. De esta forma, si una blockchain tiene un poder de procesamiento de 10 TPS, al dividir la blockchain en 10 partes iguales logramos escalar hasta 100 TPS.

En lugar de colocar la carga de procesar todas las transacciones en todos los validadores, aplicando el sharding distribuimos la responsabilidad para que se puedan procesar más transacciones sin ralentizar la red.

Los diferentes shards que conforman la blockchain cuentan con una blockchain de ‘coordinación’ en común, la cual no se encarga de validar y procesar bloques, ni cuenta con dapps corriendo sobre ella, sino que más bien actúa como punto de encuentro entre shards. 
Cada cierto tiempo, los diversos shards envían snapshots del estado del shard para que se asienten sobre ésta ‘main-chain’.

Ésta blockchain de coordinación, cuenta con el deber de asignar validadores de forma aleatoria a cada shard y rebalancear el grupo de validadores cada determinado tiempo, procesar el stake que los validadores dejan como depósito en garantía e implementar el mecanismo de slashing de ser necesario.

Aunque cada blockchain cuenta con un sistema diferente, todas implementan una blockchain de conducción: En Ethereum 2.0, esta *main-chain* es llamada Beacon Chain; en Cosmos, Cosmos Hub; y en Polkadot, Relay Chain.


# La función de los nodos en una blockchain

Cada nodo validador en una red es responsable de procesar transacciones correctamente, distribuir las transacciones y bloques válidos hacia los demás nodos que conforman la blockchain y almacenar el historial de la red desde sus inicios de forma local.

En una blockchain, cada bloque que se crea consta de dos partes:

- **Block header**: Se puede entender como la información básica del bloque completo pero comprimida para que no ocupe el espacio requerido por el bloque completo. En el block header se incluye el [merkle root](https://academy.bit2me.com/que-es-un-arbol-merkle/)* para tener certeza que las transacciones incluidas en él son válidas. Si en el block header se incluyesen datos inválidos, el bloque completo sería rechazado, ya que no es posible falsificar los datos que contiene el block body.
- **Block body**: contiene todos los datos completos de las transacciones que incluye. Esto requiere almacenar una gran cantidad de datos.

Generalmente, los nodos que corren sobre una blockchain se dividen en dos grupos:

- **Full nodes**: descargan cada bloque completo y verifican que cada transacción incluida en los bloques sea válida. Montar un full node requiere un gran espacio de almacenamiento ya que debemos descargar todos los datos históricos de la blockchain.
- **Light nodes**: solo descargan el header del bloque que incluye un [merkle proof](https://academy.bit2me.com/que-es-un-arbol-merkle/) para asegurarse que las transacciones de los bloques que les env?an los full nodes sean correctas. Montar un light node es relativamente sencillo, y no requiere mucho almacenamiento, ya que descargamos una versión ‘simplificada’ de la blockchain.

![FULL NODE.png](/uploads/FULL_NODE_23f97a1efb.png)

# Vulnerabilidades del mecanismo

En una blockchain tradicional (Bitcoin o Ethereum) cada nodo debe verificar que cada transacción que se genera es correcta. Por lo que, si un atacante quiere incluir una transacción incorrecta en un bloque, deberá controlar el 51% de los nodos en la red para incluirla exitosamente. Poniendo como ejemplo una red que contiene 100 validadores, para atacar la blockchain creando transacciones inválidas o censurando algunas otras, es necesario dominar 51 validadores para hacerlo de forma exitosa.

Sin embargo, en una blockchain que implementa el sharding, corromper la red se torna un poco más fácil de lograr: ya que efectivamente la blockchain se divide en varias partes y se asigna un grupo de nodos a cada shard específico, la seguridad de la red no es la misma que si todos los nodos que conforman la blockchain estuviesen verificando cada bloque que se produce en toda la red.

Siguiendo el ejemplo anterior, supongamos que la blockchain ahora se parte en 10 shards. En este escenario, para corromper un shard no es necesario estar en control del 51% del hashrate total, sino más bien del 5.1% (51%/10) del total de nodos en la red. **Con esta visión, es mucho más probable un ataque del 51% en un solo shard que un ataque del 51% en toda la red.** Siguiendo esta línea, podemos agregar más y más shards y el número necesario para corromperla seguirá disminuyendo. Por lo tanto, la seguridad del protocolo disminuye cada vez más a medida que se agregan shards a la red, haciendo que cada shard sea más fácil de atacar individualmente.


# Randomness

Por suerte, existen soluciones que apuntan contra esta debilidad del mecanismo: **Si los validadores/mineros no pueden elegir a qué shard aplican su hash power/stake**, se vuelve poco probable que una entidad en control del 5.1% de los nodos sea asignada a un mismo shard, volviéndola corruptible. Para asegurar la integridad y seguridad de cada shard, es indispensable contar con un sistema de elección aleatoria de los validadores que lo conforman y así reducir las probabilidades de comprometer el sistema.

**En Ethereum 2.0**, esta elecci?n aleatoria se genera a trav?s del mecanismo llamado VDF (Función de Retardo Verificable), de la cual la blockchain ‘de conducción’ (Beacon Chain) es la encargada de asignar validadores a cada shard.

Beacon Chain avanza por epochs, los cuales contienen 32 slots (cada slot es una oportunidad para incluir un nuevo bloque). En Beacon Chain, los validadores se dividen por comités, los cuales deben contener por lo menos, 128 validadores en cada comité. Los validadores, agrupados por comités, son asignados a cada shard al inicio de cada epoch.

Las **funciones de retraso verificables** están diseñadas para **retrasar la revelación sobre a qué comités fueron designados** los validadores hasta el punto en que los actores maliciosos no puedan usar la información para beneficiarse, reduciendo la probabilidad de corromper un mismo shard.

![shard.png](/uploads/shard_ed38f4cceb.png)

[Why shardin is great](https://vitalik.ca/general/2020/04/07/sharding.html) 

Otra forma de generar aleatoriedad en blockchain es a través del sistema VRF (**Función de aleatoriedad verificable**). Chainlink y Algorand son algunos ejemplos que lo implementan.


# Data Availability aplicado en sharding

El mecanismo de sharding implica que los nodos que conforman la red no deben necesariamente validar absolutamente todos los bloques de todos los shards. Como tal, cada vez que un usuario necesita interactuar con un shard diferente al cual se encuentra, no puede descargar y validar el historial completo del shard al cual apunta.
Este problema desencadena una pregunta fundamental: sin descargar y validar el historial completo de un shard en particular, **¿Cómo puede un usuario estar seguro que el historial del shard con el que interactúa es correcto y no se omitió ningún dato?**

¿Cómo pueden los nodos de una red verificar que todos los datos de un nuevo bloque están realmente disponibles y que ningún dato ha sido ocultado o censurado? Si los datos no están completamente disponibles para ser verificados, **el bloque puede contener transacciones maliciosas que el block producer ha ocultado.**

Tomando la definición de full node y light node explicada más arriba, podemos aplicar el mismo criterio en sharding: los validadores asignados en cada shard verifican todas las transacciones de cada bloque en ese shard específico, pero no lo hacen de forma completa en los demás shards que conforman la red, solo verifican el block header de los demás shards. Sabiendo esto, podemos inferir que **el grupo de validadores aplicado a cada shard opera como un full node** chequeando el estado completo del shard, mientras que en **los demás shards**, **actúan como light node**.
Por lo general, un nodo en una blockchain con sharding ejecutará un full node solo para uno o unos pocos shards, y correrá un light node para los distintos shards que componen la red.**
**

**Cuál es el problema?** Ya que los validadores en un shard no pueden estar 100% seguros que los bloques creados en otro shard **del que no forman parte como full nodes** (más bien, operando como light nodes) contienen los datos completos en el bloque, no tienen la certeza que nada está siendo ocultado/censurado por los demás en otros shards. Por lo tanto, es indispensable contar con alguna manera de confirmar que en ningún momento de la historia en ningún shard se incluyó algún bloque inválido.

Para detectar si algún shard incluyó en un bloque una transacción inválida, es necesario poder garantizar que todos los datos en ese shard se publicaron y estuvieron disponibles para todos en la red.

La solución simplificada indicaría que todos los nodos en **todos los shards deberían actuar como full nodes de cada shard en la red**, pero esto rompería el propósito del sharding al ser necesario que todos los nodos almacenen una cantidad muy grande de datos. Esto sería posible en una blockchain diseñada con pocos shards, pero para escalar hasta decenas y decenas de shards, requiere una enorme cantidad de almacenamiento. No es razonable esperar que los nodos cuenten con el historial completo de todos los shards, por lo tanto no es una solución factible.

Algunas soluciones para este problema que no discutiremos en profundidad en este blog se tratan de Notaries, Erasure code, Validium y Volition.

- **Notaries**: éstos van rotando entre shards de forma más frecuente que los validadores para verificar el estado completo de los bloques y publican una prueba de su accionar.
- **Erasure code**: mediante este mecanismo, es posible recuperar el estado del bloque completo, incluso si solo una parte del bloque fue publicado.
- **Validium**: a diferencia de los zk-rollups, Validium guarda los datos off-chain.
- **Volition**: permite a los usuarios cambiar entre un zk-rollup y Validium y admite el almacenamiento off-chain u on-chain de los datos.


# Transacciones cross-shard:

**Ejemplo 1)** Supongamos el siguiente escenario: una blockchain se ha partido en 2 shards, pero el shard 1 contiene un conjunto de validadores coludiendo para incluir transacciones inválidas. Éstos, comienzan a producir un bloque malicioso B y logran insertarlo en el shard 1.

Una vez incluido el bloque B en el shard #1, los validadores intentan hacer una transacción cross-shard (entre shards) hacia el shard #2 para que así, su bloque sea incluido en un shard válido, y las transacciones incluidas en el bloque B tengan más chances de pasar desapercibidas. Pero este accionar no sería posible, ya que si bien los light nodes del shard #2 no verifican los datos completos del shard #1, sí reciben el header del bloque B (el cual no se puede adulterar) del shard #1. Por lo tanto, los nodos del shard #2 rechazarían el bloque inválido del shard #1.

![Shard 1 (1).png](/uploads/Shard_1_1_f8faa48d97.png)
Cross-shard tx inválida

**Ejemplo 2)** Siguiendo la línea del ejemplo 1: Ahora bien, ¿Qué pasaría si los nodos maliciosos incluyesen un bloque C válido por encima del bloque B inválido que han creado anteriormente?

De ser así, una transacción cross-shard desde el shard 1 hacia el shard 2 podría ser incluída, ya que aparentemente para los nodos del shard 2, el bloque C (que incluye el bloque B) es válido.

Teniendo esto en cuenta, que los nodos del shard de destino **verifiquen el estado completo del bloque del shard desde el cual se inicia la transacción**, no es una solución viable.

![Shard 1.png](/uploads/Shard_1_882e6f4aab.png)
Cross-shard tx válida


# La visión de Kadena para lidiar con este problema: Chainweb
 
El sistema que utilizan para escalar de forma horizontal es sencillo pero eficaz: unir shards entre sí de manera que cada shard se conecte con sus shards vecinos y otros shards más alejados, y solo permitir transacciones cross-shard entre los shards vecinos conectados.

El protocolo requiere que cada bloque en cada shard incluya el blockhash del bloque anterior del mismo shard, pero además exige que se incluya **el blockhash del bloque anterior de todos los shards** con los cuales se conecta directamente.

Cada nodo en los diversos shards, cuentan con el deber de validar tanto los bloques en el shard en el que se encuentra como **todos los bloques de todos los shards vecinos**.

![kda.png](/uploads/kda_7ea6c83aac.png)

[Estructura del sharding en Kadena's Chainweb](https://medium.com/kadena-io/how-to-scale-a-proof-of-work-blockchain-9233e5b4b62)

Para efectuar una transacción cross-shard entre shards que no son vecinos, dicha transacción se enruta a través de varios shards en la red. Cada shard se conecta con los 3 shards vecinos de forma multidireccional. Por lo tanto, para saltar desde cualquier shard hacia cualquier otro shard, solamente es requisito pasar por no más de 2 o 3 shards hasta llegar al shard deseado.

Para asegurarse que todo el hashpower/stake de la red esté protegiendo el bloque en el cual se incluye nuestra transacción, debemos esperar la inclusión de por lo menos 3 bloques luego del nuestro. Por lo que, como sucede en una blockchain tradicional, para atacarla/censurarla se debe estar en posesión del 51% del hashpower/stake.

**Volviendo al ejemplo 2:** si los nodos en el shard 1 comienzan a coludir para incluir transacciones inválidas en el bloque B, luego crean un bloque C válido e intentan iniciar una transacción cross-chain hacia el shard 2, ésta no se efectuará debido a que los nodos en el shard 2 han validado el estado completo del shard 1, rechazando el bloque malicioso.

![Shard 1 (3).png](/uploads/Shard_1_3_5ed14938b7.png)

Cross-shard tx en Chainweb


**Fuentes y links de utilidad:**

- [How to scale a proof of work blockchain - Kadena](https://mirror.xyz/defilatam.eth/fJPdJSSacuQA9l4VHq_l9PP0xvA45SmFt778BK8NCms) 
- [What is Data Availability?](https://coinmarketcap.com/alexandria/article/what-is-data-availability)
- [Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities](https://arxiv.org/pdf/1809.09044.pdf)
- [Ethereum Sharding - FAQs](https://eth.wiki/sharding/Sharding-FAQs)
- [On the Security and Performance of Blockchain Sharding](https://eprint.iacr.org/2021/1276.pdf)
- [WTF is Data Availability?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f)


En blockchains tradicionales como Bitcoin o Ethereum, el problema de escalar la red a medida que crece su adopción se agrava cada vez más.



medium_8.png

small_8.png

thumbnail_8.png

8.png

Sharding & Data Availability: Un problema para escalar

MEV es la sigla de ‘*Maximal Extractable Value*’ (Valor máximo extraíble), antes llamado ‘Miner Extractable Value’. El término fue originalmente utilizado en el documento [Flashboys 2.0](https://arxiv.org/pdf/1904.05234.pdf), en el que se describe cómo actúan estos individuos o grupos y el problema que conlleva para la network.

MEV es el valor económico que pueden extraer los block proposers (*validators en PoS, miners en PoW, sequencers en rollups*) a través de la habilidad de incluir, censurar o reordenar transacciones arbitrariamente en los bloques que crean. Ya que son actores privilegiados en el consenso de la blockchain, pueden decidir qué transacciones incluyen en sus bloques y cuales ignoran.

Sin embargo, por más que los mineros sean los encargados de organizar los transacciones dentro de los bloques que construyen, los que realmente extraen el valor son los arbitradores, quienes le pagan al minero en forma de ‘soborno’ un porcentaje de las ganancias obtenidas por el servicio de re-organizacion que los mineros le ofrecen.

El valor extraíble se encuentra tanto en liquidaciones en protocolos de lending, arbitrajes entre exchanges descentralizados, sandwich attacks y frontrunning, entre otros. 

Al enviar una transacción, el usuario debe setear el gas en base al costo de transaccionar en la red en ese momento especifico, lo que determinará si su transacción es finalmente procesada o deberá esperar un tiempo mayor al estándar. Las transacciones que no son procesadas inmediatamente, se almacenan en la **mempool** – una base de datos local de transacciones en cada nodo a la espera de ser confirmadas - 

Debido a que en Ethereum se crean bloques nuevos cada 12/14 segundos (blocktime), y dado que cada bloque sólo puede contener un número limitado de transacciones, los block producers (mineros) tienen la última palabra en cuanto a qué transacciones escogen y procesan primero de su mempool local.

Esto quiere decir que no hay un orden secuencial sobre qué transacción se envió primero, es más bien arbitrario. Si un usuario envía una tx, pero llega otro usuario dispuesto a pagar un mayor fee, su transacción muy probablemente sea procesada primero.

Por cada transacción que el block producer procesa (en Ethereum, el minero) recibe una porción de los fees que se cobra al usuario, además del block reward por crear el nuevo bloque. **El MEV trae una nueva variable a la ecuación**: ya que el minero es el que decide qué transacciones se procesan primero en su bloque, y debido a que el fin de éstos es maximizar ganancias, procesarán primero las transacciones en las que los usuarios oferten el mayor gasfee.

**Ejemplos:**

El arbitraje entre DEXs es la forma más común de extraer MEV. El desbalance en los precios de diversos pares que se generan en los exchanges descentralizados dejan abierta la posibilidad de arbitraje para obtener ganancias. Básicamente, se trata de comprar barato en un AMM (Uniswap, Sushiswap) y vender más caro inmediatamente en otro.

[En este ejemplo](https://etherscan.io/tx/0xb8293765e505daae02e116bc972032bd8ab50c94cff0f4ac75939d75e73dba2e), un bot de arbitraje obtuvo una ganancia neta de $137k, convirtiendo 207 ETH en 247 ETH de inmediato. Pero para que su transacción sea minada primero tuvo que pagar $21k de fee elevando artificialmente el gwei hasta 47.589,56.

![imagen1.png](/uploads/imagen1_4580ca5a2c.png)

Pero como es una red pública, no somos los únicos al acecho: En este escenario entran los **searchers**, individuos/grupos que corren software automatizado (bots) para monitorear la mempool pública en busca de oportunidades de extraer este valor.

Estos bots exploran la mempool y verifican las transacciones pendientes de todos los usuarios de la red, detectan estas oportunidades y copian exactamente los datos de la transacción (txid) a la que buscan anteponerse, ofertando un mayor gasfee para que el minero la escoja primero por encima de la transacción original. Esto es lo que se llama **frontrunning** o **Priority Gas Auctions** (PGA)

Dependiendo de cuán alto es el profit, el minero puede decidir en última instancia insertar su transacción por encima de las demás y apropiarse de ésta. Actuando económica y racionalmente, obtienen mayores ganancias aparte de los block rewards y fees de la red.

Al configurar un slippage alto (tolerancia ante el deslizamiento de precios) quedamos expuestos al frontrunning. Cuando hacemos un swap y colocamos un slippage alto, estamos aceptando que de moverse el precio del activo, estaremos de acuerdo. Si un bot detecta esto, enviará 2 transacciones a al red:

 - La compra del mismo activo, copiando el txid de nuestra operación pero ofertando un mayor gasfee que el nuestro, para que su tx se confirme primero.
 - La venta de este activo, pero ofertando un gasfee ligeramente menor al nuestro. De esta forma, el bot comprará el activo que estamos intentando comprar y nos lo venderá inmediatamente a un precio mayor al original (a esto se lo llama **Sandwich attack**).
Así, los bots manipulan el precio sin que los usuarios siquiera lo noten debido a un alto slippage.

**Pros y contras:**

En un mercado eficiente, estos bots son de utilidad para equilibrar los desbalances en los precios entre diferentes exchanges descentralizados y ayudan a los protocolos de lending realizando liquidaciones para que no quiebren y puedan seguir operando de forma eficiente.

Pero así como son de ayuda, también perjudican a los usuarios finales: los bots de arbitraje compiten entre sí por obtener el arbitraje ofertando cada vez mayores fees, como una especie de subasta, lo que termina inflando artificialmente el precio del gas de la red, volviéndola prohibitiva. 

**Timebandit attack:** Es un tipo de ataque al consenso que involucra la reorganización de bloques pasados en los que se puede extraer una gran cantidad de MEV.

Supongamos que en un contexto de una caída brusca en el mercado, se genera una gran liquidación en el vault ETH-A de MakerDAO, por un valor de 100 ETH. En este escenario, el minero que crea el bloque puede elegir insertar su transacción en el mismo y apropiarse de la liquidación o dejar que otro la tome, si los fees que recibe lo incentivan a hacerlo.

![imagen2.png](/uploads/imagen2_bba8b4c7f2.png)

El comportamiento que se espera de los siguientes mineros sería el de añadir nuevos bloques sobre la blockchain más longeva, y seguir extendiendo la blockchain. Pero conociendo el valor que puede ser extraído de la liquidación del bloque anterior (100 ETH), el nuevo minero puede escoger no seguir extendiendo la blockchain más larga y reescribir la historia para capturar el MEV del bloque anterior (re minar). Esta es una reorganización de 1 bloque, pero si los incentivos son suficientes (Por ejemplo, si el MEV capturable > block reward), pueden ocurrir reorganizaciones de +3 bloques para tratar de capturar el MEV del pasado.

![imagen3.png](/uploads/imagen3_43b44371c3.png)

Este es un problema grave para la red, el consenso y los usuarios en general, ya que se podría generar una guerra en la que los mineros al querer capturar este gran valor que se puede extraer, intenten reorganizar infinitamente bloques anteriores sin dejar avanzar la blockchain.

Cuanto más MEV haya para extraer, mayores serán los incentivos para realizar este tipo de ataque.

[Flashbots](https://docs.flashbots.net/) es un colectivo independiente de hackers éticos formado con el fin de mitigar el impacto que genera la extracción de MEV (ej: congestión de la red, inflación artificial del gas, etc) y democratizar el acceso al mismo en Ethereum, tanto de los pequeños participantes como los grandes.

La organización desarrolló el cliente modificado de GoEthereum, MEV-geth, el cual enruta las transacciones de los usuarios hacia los mineros de manera privada sin pasar por la mempool pública, por lo que no pueden ser vistas por el resto de la red, previniendo el frontrunning y optimizando la comunicación entre searchers y mineros. Con esto, cualquiera puede pagar un bribe privado a los mineros para ejecuten su transacción antes de que nadie mas tenga oportunidad.

Recientemente lanzaron [Flashbots Protect](https://medium.com/flashbots/announcing-flashbots-protect-9e039e9f0aa3), un RPC para agregar en la wallet al que los usuarios finales pueden acceder y enviar directamente las transacciones hacia los mineros que corren el cliente mev-geth. Actualmente el 90% del hashrate de Ethereum corren geth-mev.

[Flashbots](https://explore.flashbots.net/) cuenta con un dashboard con diversas métricas, algunas de ellas:

![imagen4.png](/uploads/imagen4_444c23602d.png)

https://dashboard.flashbots.net/network

Lógicamente, la extracción de MEV se concentra en los principales AMM de Ethereum (Uniswap V2/Sushiswap) con 66% del valor total extraíble entre los dos, ya que es el lugar por excelencia para realizar arbitrajes. La gran parte de las operaciones que incluyen MEV son arbitrajes (96%).

![imagen5.png](/uploads/imagen5_6afe1feab7.png)

MEV es la sigla de 'Maximal Extractable Value' (Valor máximo extraíble), antes llamado 'Miner Extractable Value'. 

medium_post-img-854-480-instroduccion.png

small_post-img-854-480-instroduccion.png

thumbnail_post-img-854-480-instroduccion.png

post-img-854-480-instroduccion.png

Introducción al MEV - MEV SERIES Vol.1

Una clasificación de las L2s en Ethereum, TVL y estado de las DEXes, noticias y más

medium_3.png

small_3.png

thumbnail_3.png

3.png

Estado de la escalabilidad en Ethereum - Noviembre y Diciembre 2021

**Introducción**
----------------

Ha pasado un año desde que el cofundador de Ethereum, Vitalik Buterin, anunciara a través de un [hilo de discusión](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)?desde el foro de contribuidores de Ethereum, '*Fellowship of Ethereum Magicians*', un texto cuyo título marcaría el inicio del camino en la forma en la que los builders, usuarios y comunidad en general se alinean y trabajan hasta ahora en coordinación con el futuro de Ethereum:

> "*¿Cómo sería un roadmap de Ethereum centrado en rollups?*"
![7.jpg](/uploads/7_7b7486218b.jpg)

En ello, Vitalik enfatizó que el estado de los proyectos trabajando en el desarrollo de rollups, cuyas etapas inclu?a algunos en fase de red pruebas, llamaba a que el progreso en el desarrollo futuro de la red principal (incluyendo Ethereum 2.0) buscase a ser amigable con las necesidades tempranas y posteriores, como el ya conocido cambio en el cálculo y modo de proceder con las comisiones de la red mediante la propuesta [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).  Además, motivó al ecosistema a la continua construcción de herramientas para desarrolladores y usuarios, desde la arquitectura fundamental hasta aplicaciones y puentes, que pueda permitir un buen futuro dentro de las segundas capas.

Consecuentemente, durante el 2021 se ha presenciado un crecimiento en el número de proyectos de soluciones de segunda capa para el público, cerrando para finales de octubre un total de [18 redes activas](https://l2beat.com/)?sobre Ethereum, basadas en las tecnologías Optimistic Rollups, ZK Rollups, Validiums y Plasma chains. 

![clasificacionoctubre.jpg](/uploads/clasificacionoctubre_e4bd56c310.jpg)

Por supuesto, **a medida que el tiempo pase, es lógico pensar que nuevos proyectos lancen sus soluciones de escalabilidad, así como también versiones mejores de los ya existentes**. En este trayecto, se podría pensar que ha iniciado la etapa del Renacimiento en Ethereum.

## **Estado actual del valor total bloqueado- TVL?en L2**

A pesar de que la llamada “*L2 summer*” (visto como un relanzamiento en alusión del boom DeFi durante el verano del 2020) anunciada a principios de años nunca llegó a gran escala, el continuo desarrollo de soluciones de escalabilidad ha dado pasos importantes y **las soluciones activas en la red principal han tenido un buen desempeño en términos de seguridad, con cero incidentes catastróficos hasta la fecha.** 

Según datos proporcionados por [L2BEAT](https://l2beat.com/), el valor total bloqueado en las soluciones de segunda capa existentes exceden los **4.5 mil millones de dólares**. En el mes de octubre tuvo un crecimiento de 14% explicado mayormente por la revalorización de activos, pero también la entrada de nuevo capital. 

![l2beat-october.jpg](/uploads/l2beat_october_eff9f8f380.jpg)


Este número, aunque parezca ínfimo, va acompañado de una tendencia de crecimiento, en el que por lo menos **se ha multiplicado por diez veces respecto en los últimos tres meses**. Puesto en mejor contexto, el valor total bloqueado dentro de las L2s, en comparación con el ecosistema DeFi total según [DefiLlama](https://defillama.com/chain/Ethereum) (y corregido), las segundas capas han alcanzado equipararse en una relación cercana a **100:2** respecto a la suma del ecosistema DeFi en la red principal de Ethereum y otras redes.


![12.png](/uploads/12_23fc5c3f83.png)


¿En otra perspectiva? El TVL en L2s ha alcanzado el **2.86%** del tamaño de DeFi en Ethereum y el **6.11%** con el ecosistema fuera de Ethereum.

Dentro del universo de las L2s, el valor total bloqueado está distribuido según sean las características particulares de cada proyecto y su estado actual en el desarrollo. Estos puntos, por lo tanto, influyen en las preferencias de los usuarios y se traduce en una distribución, que a primera vista luce dispareja.


![22.png](/uploads/22_14c6d34440.png)

**En este ranking lidera [Arbitrum](https://bridge.arbitrum.io/)**, ya que hasta hoy es el único rollup de propósito universal (es decir, para desplegar contratos inteligentes de todo tipo) y composabilidad, con protocolos DeFi activos como **Curve, Uniswap, Sushiswap**, **Beefy** y [más](https://portal.arbitrum.one/). **En segundo lugar está situado? [dYdX](https://dydx.exchange/)**, un ZK-rollup de tecnología StarkEx para aplicaciones específicas, que ha atraído liquidez y traders para su mercado de *contratos perpetuos descentralizados*. **En tercer puesto, Optimism**, de características similares al líder del ranking, pero aún en etapa de ecosistema permisionado, por lo que sólo están activas las aplicaciones Uniswap y Synthetix. **El resto lo componen L2s de usos específicos**, como exchanges descentralizados (**Loopring, DeversiFi, ZKSwap**), plataformas para NFTs (**Immutable X, Sorare**) y para transacciones.

Por las mismas razones que explican la distribución del valor total bloqueado en el total de L2s, determina la distribución de las diferentes clases de activos en estas soluciones de escalabilidad.

![42.png](/uploads/42_d200cf6354.png)

Casos particulares, **dYdX** 100% en monedas estables ya que opera únicamente con la token USDC, y **Boba Network**, con > 98% en otros activos, fundamentalmente por el almacén del token $OMG asociado al proyecto, cuya historia se mencionará más adelante en este artículo.

Otros datos, como el número de transacciones promedio por día, aunque se presentan relativamente bajos respecto a la actividad en la red principal y otras cadenas, existen algunos números para destacar.

![32.png](/uploads/32_66d8534c54.png)

Los datos globales de las soluciones de escalabilidad provistas usando la tecnología **StarkEx** muestra un buen desempeño, pero principalmente **dominado por el proyecto dYdX**, dado la naturaleza de los exchanges basados en contratos perpetuos con apalancamientos. Luego  se encuentra **Optimism** y **Arbitrum**, EVMs en el cual tienen desplegadas reputables aplicaciones de Ethereum para el usuario DeFi promedio, y el resto con aún poca actividad dado los pocos incentivos o casos de uso para migrar a las mismas. 

A medida que el desarrollo continúe sobre estas, con nuevas versiones y nuevas soluciones de escalabilidad, **las expectativas apuntan a que estos números continúen en ascenso de cara al futuro**.

**Desarrollo e Innovación**
---------------------------

### **Arbitrum Nitro, la próxima versión de Arbitrum**

![arbitrum-nitro.png](/uploads/arbitrum_nitro_c357a9b947.png)

Como acabamos de ver, Arbitrum One ha gozado de un relativo éxito en términos de adopción como la Rollup con más valor total bloqueado hasta el momento. Ahora los chicos de OffChainLabs están preparados para dar el siguiente gran paso: **actualizar su Optimistic Rollup y hacerla mucho más escalable**.

Con miras de escalar en el futuro, la arquitectura de [Nitro](https://medium.com/offchainlabs/arbitrum-nitro-sneak-preview-44550d9054f5) estará construida sobre las tecnologías de **WASM (WebAssembly)** y **Geth**, para reemplazar la EVM personalizada implementada hasta el momento (AVM -*Arbitrum Virtual Machine*), ofreciendo en términos netos **un aumento de rendimiento entre 20 y 50 veces del actual**. Velocidad en la ejecución de transacciones y disminución de los costes para el usuario final.

Y la mejor parte: para implementar Arbitrum Nitro solo requerirá actualizar Arbitrum One (la rollup en funcionamiento) descartando todo trabajo de migración y readaptación por parte de desarrolladores y usuarios. Todas las dApps seguirán funcionando, y los datos y eventos existentes previo a la actualización permanecerán accesibles.

Por ahora, el team a cargo no se atreve a mencionar fechas sobre esta nueva actualización, pero **aseguran que en las próximas semanas proporcionarán más detalles** de la misma, así como también todos los pasos previos como el despliegue en la red de pruebas.

### **Lanzamiento de StarkNet Alpha en la red principal de Ethereum anunciado para noviembre**

![starknet.png](/uploads/starknet_f998b45738.png)

StarkWare ha estado desarrollando **StarkNet** como una ***permissionless*** ZK Rollup basado en STARK**, que permite la implementación de contratos inteligentes en un entorno de composabilidad y gestión de la misma (la red) de forma descentralizada. Durante todo el 2021 diferentes objetivos (etapas llamadas Alpha 0, Alpha 1, Alpha 2 y Alpha 3) fueron alcanzados satisfactoriamente en su implementación desde las redes de pruebas, como permitir a los desarrolladores construir sus primeros contratos inteligentes y testear la interacción entre L2 y L1.

Ahora el proyecto se prepara para lanzar ***StarkNet Alpha*** en la red principal de Ethereum (no confundir con las etapas de testnet) en algún momento de este mes de noviembre, en el cuál apostarán inicialmente por un lanzamiento suave, con incorporación de lista blanca para el despliegue de contratos inteligente, estrategia similar a la llevada a cabo por desarrolladores de Optimistic Rollups ya en funcionamiento en la red principal (Arbitrum y Optimism).

**Características notables a considerar para usuarios y desarrolladores**:

-  Soporte nativo al algoritmo de firma ECDSA para fácil integración con billeteras existentes
-  Especificaciones para correr un nodo completo de StarkNet similares a las de Ethereum
-  Fees ajustados al costo de operación de StarkNet en L1, cobrados en ether
-  Un solo secuenciador o coordinador estará a cargo del procesamiento de transacciones en la red
-  La red podrá estar sujeta a cambios en cualquier momento y sin tiempo de espera
-  Implementación de Warp: el compilador de Solidity a Cairo, el lenguaje de programación nativo de StarkNet desarrollado por Starkware

Como ya se había [anunciado el año pasado](https://medium.com/starkware/hello-cairo-3cb43b13b209),?[**Cairo es el nuevo lenguaje**](https://www.cairo-lang.org/) **clave para la operación de la red y generación de pruebas de validez basadas en STARK**. Esto implica que los desarrolladores tendrían que adaptarse a este nuevo marco de trabajo, o bien apoyarse en las herramientas proporcionadas por Nethermind (Warp, mencionado arriba) y OpenZeppelin (estandarización de contratos inteligentes para StarkNet).

De hecho, una implementación de un Automated Market Making (AMM) sobre la testnet en StarkNet puede ser revisada y probada desde ya en el siguiente sitio web [starkware-amm-demo.netlify.app](https://starkware-amm-demo.netlify.app/), usuarios corrientes pueden empezar a interactuar con ella sin necesidad de conectar sus billeteras personales, *Mintea y swapea!*.

### ?‍**ZkSync 2.0 cada vez más cerca: prueba un DEX en testnet**

![zksync2.png](/uploads/zksync2_ab8d630a7d.png)

Matter Labs ha trabajado desde hace un tiempo en **un nuevo ZK Rollup, zkSync 2.0, apuntando a ser completamente compatible con la EVM**: contratos inteligentes escritos en solidity, composabilidad y tecnología de conocimiento cero/pruebas de validez en un solo lugar (***zkEVM***a través de [LLVM](https://en.wikipedia.org/wiki/LLVM)). Inicialmente el lanzamiento de este rollup a la red principal estaba estimado para mediados de agosto, pero retrasos en su desarrollo conllevaron a patear para adelante las expectativas.

No obstante, progresos se han realizado exitosamente en la red de pruebas, **permitiendo ahora que los usuarios tengan oportunidad de tener una probada inicial del potencial de la red utilizando la versión de Uniswap V2 adaptada a zkSync 2.0 nombrada como "UniSync"**.

A través del siguiente portal [uni.zksync.io](https://uni.zksync.io/) los usuarios pueden empezar a interactuar con el frontend de UniSync y conectarse a la red de pruebas de zkSync 2.0 desde metamask:

1.  Click en "*Launch app!*"
2.  presionar "*Conectarse a una cartera*"
3.  seleccionar Metamask
4.  conectar tu cuenta y añadir la red "zkSync 2.0 Rinkeby"
5.  solicitar fondos para probar el DEX "*Request tokens from a faucet*".

Listo, tokens testnet de **DAI, LINK, USDC y wBTC** son recibidos en la billetera y la interacción puede empezar tal como ocurriría en un DEX -- AMM convencional, y sus resultados observarse desde el [block explorer oficial](https://zksync2-alpha.zkscan.io/).

### ? **Optimism apunta a un L2 EVM-equivalente**

![1_-enL6vtwDRutggKjbu8Y4Q.jpeg](/uploads/1_en_L6vtw_D_Rutgg_Kjbu8_Y4_Q_b44e944167.jpeg)

Optimism avanza en su misión de convertirse en el **Optimistic Rollup más semejante a la arquitectura de Ethereum en términos de infraestructura y ejecución**. Para esta tarea, han anunciado la *Optimistic Virtual Machine* (OVM 2.0) e introducido nuevas características en su red para ir más allá de la etiqueta "EVM compatible", e ir por [algo mucho más profundo](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306): la **EVM-equivalencia**.

Para el equipo de Optimism, cerrar la brecha de entre los efectos de red de la red principal de Ethereum hacia las segundas capas solo puede consolidarse con la construcción de una infraestructura que cumpla fielmente con la ya existente en la red principal, es decir, prácticamente absoluta incluyendo nodos, toolchains,  depuradores y más. ¿Qué implica esto para los participantes dentro de la red Optimism, incluidos a los desarrolladores del ecosistema DeFi? El respeto de cada línea de código en su implementación hacia la nueva arquitectura de este Optimistic Rollup. De este modo, en teoría garantiza que todo el entorno ejecución y actividad tengan los mismos niveles de seguridad en código tal como la red principal. **Optimistic Ethereum será Ethereum**.

Este cambio está [anunciado](https://twitter.com/optimismPBC/status/1453058222936313861) para este mes de noviembre, así como la continuación del programa/experimento de 1 millón de dólares llamado [*Retroactive Public Goods Funding*](https://medium.com/ethereum-optimism/retropgf-experiment-1-1-million-dollars-for-public-goods-f7e455cbdca).

### ✅ **OVM 2.0 ya disponible desde el rollup Boba Network**

![boba.png](/uploads/boba_2a16975a05.png)

Hace un mes atrás, el [20 de septiembre](https://boba.network/public-mainnet/), el grupo OMG Foundation había anunciado el **despliegue de su implementación de la red de segunda capa tipo Optimistic Rollup llamada** [**Boba Network**](https://boba.network/). A su vez, se anunció la intención de habilitar contratos inteligentes y el lanzamiento del token de gobernanza de la red, el token $BOBA.

Ahora, desde el [28 de Octubre](https://twitter.com/bobanetwork/status/1453834740767756288), la red completó con éxito la actualización de su red integrando la Optimistic Virtual Machine (OVM 2.0) para el alojamiento de contratos inteligentes basados en la EVM de la red principal. **La arquitectura en general está basada en el código? *open-source* construido por Optimism**, ya que “es esencialmente una versión modificada de Ethereum, lo que hace que sea relativamente fácil garantizar la compatibilidad con EVM y Solidity, minimizando los esfuerzos necesarios para migrar los contratos inteligentes de L1 a L2”.

Adicionalmente, está programado un **airdrop** para los que tengan en posesión tokens $OMG en sus billeteras personales y algunos exchanges centralizados ya confirmados, antes del 12/11 hora 00:00 AM (UTC). Tanto holders como proveedores de liquidez en la red principal de Ethereum o depositen en Boba Network también están calificados para recibir tokens $BOBA. El token está destinado para ser usado en la gobernanza de la red mediante la Boba DAO, y como token de staking para empezar a recibir comisiones por el uso de este rollup. Más detalles sobre el [airdrop y utilidad del token aquí](https://boba.network/airdrop/).

**Integraciones y eventos**
---------------------------

-   **DeversiFi** proveerá mercados tipo AMMs y aloja el lanzamiento del proyecto **Entropyfi** vía IDOs, mecanismo tipo DLM. [**Más detalles**](https://medium.com/entropyfi/entropyfi-and-deversifi-ido-participation-guide-35f21e4d53bb).
-   **Sorare** publica la Newsletter #4 con progresos para su plataforma.?[Más detalles](https://www.reddit.com/r/Sorare/comments/q82qix/newsletter_4_rookie_league_update_and_more/).
-   **Loopring** lanza nuevo programa de Liquidity Mining del 7 de octubre al 3 de noviembre. [Más detalles](https://medium.com/loopring-protocol/loopring-l2-liquidity-mining-round-15-ab48903bbb95).
-   Partnership entre **ImmutableX** y **ESL Gaming** para lanzar NFTs. [Más detalles](https://twitter.com/Immutable/status/1453723476645355520).
-   **Gnosis Safe** se integra a **Arbitrum**. [Más detalles](https://twitter.com/arbitrum/status/1448011308075470849).
-   **Across Protocol** anuncia su puente para transferencias rápidas y baratas entre **L2** y **L1**. [Más detalles](https://twitter.com/AcrossProtocol/status/1452645990750695433).?

**Final: ¿A dónde nos lleva todo esto?**
----------------------------------------

Escalabilidad sin límites. Hasta ahora, las blockchains tradicionales de capa única, (de cualquier esquema básico de ejecución, validación y sostenimiento de la red)  se ha enfrentado al inescapable trilema de las blockchains, esto es, para todos los tipos de “Layer 1” como Bitcoin, Ethereum 1.0, Litecoin, Binance Smart Chain, Solana, Fantom, etc. **Escalabilidad, seguridad y descentralización**, no se puede obtener el máximo relativo de las mismas al mismo tiempo.Cualquier “mejora” en alguno de estos puntos para una blockchain L1, lo hará siempre en detrimento del otro lado del trilema. Todo ello se le conoce a partir de ahora como ***Blockchain Monolítica***.

Escalabilidad sin límites es posible y superar el trilema también, lo cual, en teoría, garantizará un entorno seguro y descentralizado para los próximos millones de usuarios en el futuro, bajo el nuevo concepto de cadena de bloques: ***Blockchain Modular***. Segundas capas y Ethereum 2.0. 

Si bien está visión de **Blockchain Modular** es muy interesante, también es muy compleja y **merecerá un espacio dedicado para explayar toda esta visión del futuro de las blockchains**. Por ahora, los primeros pasos ya se están dando, con la salida y prueba en tiempo real de todas estas soluciones de segunda capa y los continuos esfuerzos de investigación y desarrollo, así que no queda mas que decir que **los próximos meses serán cada vez más interesantes**.

Un repaso del estado actual, analáticas y novedades de la soluciones que escalan el uso de Ethereum

medium_4.png

small_4.png

thumbnail_4.png

4.png

Estado de la escalabilidad en Ethereum - Octubre 2021

# Crecimiento TVL de DAOs

Un año atrás exactamente, el AUM (activos bajo gestión) total de las DAO combinadas sumaban 290.8M de dólares, una cifra sumamente alta para la época teniendo en cuenta el contexto en el que se encontraba el ecosistema DeFi, pero escaso si lo comparamos con el escenario actual.

El número aproximado de DAOs en actividad en aquel momento era de 76, hoy disponemos de más de 200 DAOs distribuidas a lo largo de varias blockchains.

![1.png](/uploads/1_38df65e37f.png)

Fuente: DeepDAO. Captura de septiembre 8 ? 2O2O

# Un poco de historia

Para ese entonces, no contábamos con la extensa gama de DAOs actuales. Por ejemplo, todavía no había sido anunciado el token de gobernanza de Uniswap ($UNI), [lanzado](https://uniswap.org/blog/uni) el 16 de septiembre de 2O2O, asignando el 60% de los tokens para los usuarios de la comunidad dándoles voz y voto en el protocolo que buscaba expandir la toma de ciertas decisiones de una manera descentralizada pero coordinada.

Aave aún no había transferido el control total del protocolo a los holders de $AAVE marcando el inicio de una nueva era. Anterior a esto, solamente los desarrolladores de la Dapp tenían la potestad de proponer cambios. La primera AIP (Aave Improvement proposal) ejecutada por la comunidad fue el [cambio](https://twitter.com/AaveAave/status/1311575613434724352) de su token, en su momento $LEND, por $AAVE con el ratio 100:1.

El treasury de Aave actualmente cuenta con $678M de dólares, siendo el 99% de los tokens del tesoro $AAVE asignados a la DAO. 

![2.png](/uploads/2_b90d0d4a7b.png)

Comenzaba a gestarse un ciclo en el que los usuarios operativos eran los que realmente tenían el ownership de los protocolos que utilizaban. Y de la mano, la expansión de las organizaciones autónomas.  

# Actualidad

Según DeepDAO, el AUM (activos bajo gestión) actual de todas las DAO en conjunto asciende a 10.9B de dólares. El crecimiento interanual es de **3.648%**, número clave que nos da la pauta de lo que *fue* y sigue siendo el desarrollo de las DAO.

![3.png](/uploads/3_8688b937c4.png)

Fuente: DeepDAO. Captura de septiembre 2O21

Uniswap registra el mayor número de miembros activos (275.652) seguido por Kusama (210.055) y Compound (174.329). Pero el número de miembros de una DAO no siempre es directamente proporcional al grado de actividad, propuestas y participación de la comunidad que la integra. Decentraland, protocolo con menos de ⅛ de miembros activos que Compound, cuenta con más del triple de propuestas que éste último en un período menor de tiempo.

Distintos protocolos requieren el voto de propuestas más esporádicas debido a su enfoque y la complejidad que necesita la implementación de las propuestas. 

Balancer, Sushiswap y yean.finance parecen ser los protocolos más equilibrados en cuanto a miembros/votantes, con 16.7, 16 y 7.9 respectivamente.

![4.png](/uploads/4_5ee5788cd3.png)

Un ranking más amplio y cercano a la realidad sitúa a Lido, Aave y Gitcoin en el top 5 en TVL de los tesoros de las DAO (en Ethereum).   

![5.png](/uploads/5_688ff50583.png)

Fuente: Openorgs

Un dato irrelevante pero interesante: el 18% del tesoro de [Gitcoin](https://etherscan.io/address/0xde21F729137C5Af1b01d73aF1dC21eFfa2B8a0d6) está compuesto por $AKITA (*meme-coin*), tokens [donados](https://etherscan.io/tx/0x2fb8b58f85ab4773da00771f7f1e1a9eacf99af0ef3310b75ebcd017099f7b3c) por Vitalik Buterin y valuados en el momento de la donación en 374M de dólares. 
<hr/>

La mayoría de los rankings centran su espectro solamente en el ecosistema de Ethereum, pero por fuera de éste se están forjando DAOs de todo tipo que merecen mención. 

Por ejemplo, Mango Markets (protocolo de Solana) recaudó $70M de dólares en el IDO de su token, $MNGO, los cuales fueron asignados a la DAO como insurance fund (fondo de seguro) para contar con un respaldo en caso de un eventual black swan que perjudique a los lenders.

El 89.9% (8.9B de $MNGO) de su total supply están [bloqueados](https://solscan.io/account/9RGoboEjmaAjSCXsKi6p6zJucnwF3Eg5NUN9jPS6ziL3) y fueron asignados a la DAO del protocolo, aproximadamente $2.2B de dólares al día de hoy, siendo accesibles solamente a través de su gobernanza.

La gobernanza ya cuenta con más de 18 propuestas ejecutadas por mayoría desde su comienzo en agosto de 2O21.

![image2.png](/uploads/image2_3441d6ec2f.png)

# ¿Cómo se implementan los cambios?

A grandes rasgos, hay 2 formas de actualizar contratos de gobernanza en DAOs: 

- Una multisig con addresses de personalidades reconocidas y *confiables* en el protocolo en cuestión, responsables de ejecutar cualquier votación que pase los requerimientos de la comunidad. 

Ejemplos: yearn.finance, Balancer, Sushiswap.

- Un contrato en el que (dado los parámetros establecidos) cualquiera pueda proponer y ejecutar propuestas de gobernanza on-chain, eliminando cualquier sistema multisig. Las propuestas de las DAO que utilizan este tipo de frameworks suelen ejecutarse más lentamente, ya que por lo general los smart contracts de las DAO están atados a un Timelock, se debe esperar a que transcurra un tiempo determinado antes de implementar lo que la comunidad votó a favor.

Ejemplos: Uniswap, Compound, Gitcoin, MakerDAO, Tornado Cash.
<hr/>

En sus inicios, Compound usaba el sistema de gobernanza basado en el contrato on-chain **GovernorAlph**a, el cual fue uno de los pioneros en desarrollar un método que permitía alcanzar un acuerdo entre los stakeholders de organizaciones autónomas descentralizadas sin necesidad de recurrir a una multisig, dando un paso más hacia la descentralización del protocolo. Cualquier usuario que cuente con ≥ 1% del supply del token de gobernanza puede emitir una propuesta para cambiar algún parámetro del protocolo. 

Este sistema de gobernanza no cuenta con un administrador o multisig capaz de actualizar los parámetros del contrato on-chain, sin que antes pase por una votación de la comunidad. Al permitir que la gobernanza realice actualizaciones, literalmente todo se puede cambiar, incluyendo el mecanismo de gobernanza en sí.

Tiempo después, la comunidad [decidió](https://www.comp.xyz/t/governor-bravo-proposal/1384) migrar a un sistema de gobernanza semejante en ejecución pero mejorando algunos aspectos, con GovernorBravo. La gobernanza de Uniswap imitó esta propuesta e implementó el mismo framework, actualización que luego fue empleada por varios protocolos. 

La secuencia para la actualización de contratos que deben seguir Alpha y Bravo es la siguiente: 

![6.png](/uploads/6_dd7ee325d4.png)


Principales diferencias entre Alpha y Bravo:

![7.png](/uploads/7_609c90154c.png)

Créditos a Tally por la imagen


**Gnosis Safe** es un smart contract basado en un sistema de wallet multisig. Requiere un número mínimo de personas que componen la wallet multisig para aprobar una transacción antes de que pueda efectivizarse. 

Por ejemplo, si una DAO cuenta con una multisig ⅝, se requieren 5 firmas de 8 distintas wallets antes que se envíe la transacción. Si bien este sistema no es ‘descentralizado’ al 100%, distribuye la confianza en las partes involucradas y no recae en un ente central. Esto disminuye el riesgo de comprometer los fondos.

**Snapshot** es un sistema de votación off-chain y gasless (sin costo de gas). Las DAO la utilizan para alcanzar consenso entre los usuarios que la componen, teniendo la posibilidad de presentar propuestas de manera user-friendly. Las votaciones que se realizan en la plataforma no son deterministas, osea que no se ejecutan inmediatamente en el código. La última palabra la tienen los dueños de la multisig que controla el contrato del protocolo..

- DAOs que utilizan Gnosis Safe/Snapshot como sistema multisig: Balancer, Sushiswap, yearn.finance, Synthetix, Aave.
- DAOs que utilizan Aragon como sistema de gobernanza: Lido, Badger, Decentraland
- DAOs que utilizan el sistema de Compound, GovernorBravo: Compound, Uniswap, Gitcoin

# Tokens populares entre los tesoros de las DAO: 

Como es de esperarse, del top 13 de los tokens más holdeados por las DAOs, el activo por excelencia elegido es ETH, seguido por USDC y DAI. También nos encontramos en el top activos con un valor notable a la hora de tomar decisiones como GTC y CRV, entre otros.

![8.png](/uploads/8_ae7b76bcc8.png)

# Sistemas elegidos:

Tomando como referencia 15 de las principales DAOs por valor en USD que utilizan Gnosis Safe/Snapshot, Compound Governance (Bravo/Alpha) y Aragon como sistemas de gobernanza, observamos que la implementación de Compound (ambas variantes: Bravo y Alpha) sin multisig lidera el gráfico en términos de USD con un total de $6.5B de dólares, seguido por Gnosis Safe/Snapshot con 4.1B y por último se encuentra Aragon con un valor aproximado de 1B.

![9.png](/uploads/9_64776b69c3.png)

Si bien Compound governance se mantiene Nº1 en términos de USD (con gran ayuda de Uniswap), **no lidera el ranking por sistema elegido en DAOs**. Este puesto lo tiene Gnosis Safe, con 8 protocolos que lo implementan contra los 5 protocolos que utilizan la gobernanza de Compound.
 

# Diversificación de activos en los tesoros

Tomando como referencia las principales 10 DAOs, analizamos la tenencia de activos en sus tesoros. Por lo general, el treasury de las DAO se compone mayoritariamente por los tokens de gobernanza del protocolo, que son asignados en la distribución inicial del mismo. Sin embargo, no todos los tesoros se componen de igual manera. Muchos optan por mantener posiciones en activos considerados como reserva de valor a largo plazo tales como BTC o ETH. 

![10.png](/uploads/10_49519ee33a.png)

Viendo la notable tendencia hacia los tokens nativos, es inevitable preguntarse: ¿Las organizaciones/comunidades tienen trazado un plan de salida para un eventual black swan? ¿Está contemplada una baja generalizada en el mercado? Abordar el manejo de fondos en tesoros no es tarea sencilla, pero sí crucial para una DAO. Mantener el 100% de posiciones en el token nativo conlleva afrontar una gran inestabilidad y volatilidad en términos de USD, dejando abierta la posibilidad de colapsar.

En caso de un bear market, muchos protocolos se verán obligados a vender parte de sus activos para mantener sus actividades en pie (pago de sueldos, auditorías externas, marketing, grants), esto podría generar un efecto dominó en donde los holders del token viendo este accionar salgan a vender, llevando a una caída significativa en el precio del token.  

 

Treasury Management es un tema recurrente discutido en las comunidades, podemos encontrar ejemplos en los foros de [Sushiswap](https://forum.sushi.com/t/sushihouse-a-treasury-management-proposal/3106), [Lido](https://research.lido.fi/t/proposal-ldo-treasury-diversification/458), [PoolTogether](https://gov.pooltogether.com/t/ptip-13-revised-treasury-diversification/1049), entre otros.

Fragmento de la [propuesta de Uniswap](https://gov.uniswap.org/t/temperature-check-should-we-be-managing-systemic-risk-in-uniswaps-community-treasury-using-kpi-options/12624):

> *"Durante el bear-market de 2017, varios proyectos se vieron obligados a vender su tesorería a valores históricamente bajos, lo que finalmente hizo que muchos de ellos se disolvieran y cerraran”*

Sushiswap abordó esta temática a través del sistema diseñado por Yam Finance: [DAO House](https://yamfinance.medium.com/yam-finance-presents-dao-house-86625f9bae5a) – una solución de gestión de tesorería diseñada para cada DAO en particular, según sus necesidades y aversión al riesgo. A través de éste, el protocolo migró una parte de sus activos a [sushiHOUSE](https://etherscan.io/address/0x7b18913d945242a9c313573e6c99064cd940c6af), una canasta distribuida en ETH, BTC y DAI, entre otros.

Fragmento de la [propuesta de Uniswap](https://gov.uniswap.org/t/temperature-check-should-we-be-managing-systemic-risk-in-uniswaps-community-treasury-using-kpi-options/12624):

> “El objetivo de inversión de sushiHOUSE es proteger contra un bear market extendido mediante la diversificación en activos de menor volatilidad como monedas estables, BTC, ETH y coberturas para proteger el ecosistema de Sushi. Este proceso permite una asignación de activos más dinámica con un mejor manejo y análisis de riesgos sin pérdida de descentralización”

Inspirados por la propuesta de Sushiswap, usuarios de Uniswap propusieron diversificar su tesorería de la misma forma, a una canasta de activos usando sintéticos de UMA – KPI Options – pero el resultado fue distinto: la comunidad optó por rechazar la propuesta. 
 
![11.png](/uploads/11_5370ea46df.png)

¿Cómo una DAO puede protegerse frente a una caída en el mercado? Una opción para afrontar este escenario sería diversificar una parte en stable-coins varias (USDC, DAI, LUSD)

¿No es factible pensar en un treasury que mantenga un 20-30% de posiciones en stables? Estos protocolos en vez de tener inmovilizados sus activos, podrían dejarlos generando yield en protocolos confiables del ecosistema (Curve, yearn, Aave, Compound), y contar con liquidez en caso de necesitarla. 
 

# ¿Cómo recaudan fondos las DAOs? 

Cuando se trata de diversificar los tesoros, las DAOs no pueden simplemente vender sus tokens al precio de mercado en un DEX, ya que debido al price impact la diferencia entre el precio de mercado y el precio estimado final varía significativamente, suponiendo un tamaño de operación inusual.

Una forma para encontrar financiamiento es la venta de tokens de gobernanza a diferentes inversores o socios estratégicos interesados en un intercambio, ventas que generalmente conllevan un descuento especial en el precio del token y están sujetos a un bloqueo durante un tiempo determinado. 
<hr/>

Actualmente es moneda corriente encontrarse con protocolos cada vez más complejos y disruptivos, en una escena en donde la teoría de los juegos corre un papel cada vez más importante en la composabilidad entre proyectos de gobernanza, y nuevos equilibrios encuentran nuevas estrategias dominantes.

¿Serán las DAOs las nuevas sociedades anónimas del mundo tradicional? ¿Veremos una horda de regulaciones por parte de los Estados en un intento de frenarlas? O peor aún, camuflar la regulación con el discurso de adopción/protección. 

Está clara la relevancia e influencia que ocupan en el terreno de las criptomonedas, pero queda aún por verse el potencial que estas organizaciones pueden alcanzar a gran escala. 

El reloj está corriendo..

![12.png](/uploads/12_6d4919e328.png)


Un análisis sobre el ecosistema pasado y actual de las Organizaciones Autónomas Descentralizadas - Octubre 2O21.

medium_5.png

small_5.png

thumbnail_5.png

5.png

DAOs: Una mirada al ecosistema actual

# Sidechains: Entendiendo Polygon PoS

> En primer lugar, es importante aclarar que durante el pasar de los años, los conceptos de escalabilidad y soluciones de segunda capa (Layer 2 en inglés) enfocadas en Ethereum han estado en pleno desarrollo y constante evolución, donde antes, cualquier propuesta que pudiera aliviar la congestión de la red principal y ser afín a esta misma, quiso ser considerada en algún momento como parte de la categoría de Layer 2. Así pues, propuestas como state channels, plasma, validium, rollups o sidechains cerraban juntas en esta categoría, como parte de la jerga de muchas comunidades y medios de difusión. No fué sino hasta principios del 2021 y a raíz de la crónica congestión de la red Ethereum, que la discusión si avivó en gran parte del ecosistema crypto, dando finalmente por sentado que las sidechains **no son soluciones de escalabilidad consideradas como de segunda capa**; por hacerse cargo de su propia seguridad, y no anclarla plenamente desde la red principal, como sí lo haría un [rollup](https://www.defilatam.com/blog/escalabilidad-en-ethereum-optimistic-y-zk-rollups). Pero tranquilo, si aún no sabes qué es una Sidechain, quédate, lo abordaremos a continuación.

### Introducción: ¿Qué son las sidechains?

Una cadena lateral (la traducción formal de sidechain), de acuerdo a la definición de ethereum.org, **es una blockchain separada que corre paralelamente con la red principal de Ethereum, conectado a esta por un puente (o bridge en inglés) de sentido doble y que usa su propio mecanismo de consenso** (PoA-Prueba de Autoridad, PoS-Prueba de Participación, PoW-Prueba de Trabajo, etc). Esto quiere decir que los activos de la red principal pueden ser transferidos desde red principal, almacenandose en el puente, y replicarlos en la cadena lateral para operar en esta nueva instancia, y en cualquier momento ser retirados de vuelta a la red principal, si el mecanismo de consenso y la administración del puente convalida la solicitud. Su alto grado de independencia en varias de sus funciones como blockchain la hacen ser extremadamente semejantes otro tipo de blockchain común o “L1” en cuanto a sus garantías de seguridad. Sin embargo, existen varias caracteristícas que pueden ayudar a distinguirlas del resto:

- Si tiene token propio ó usa activos de terceros proyectos como pieza clave de la economía de la red (staking, pago de comisiones), la emisión y los tokenomics están fundamentados desde la red principal en forma de tokens ERC-20 u otros (ether).
- Si usa mecanismo de consenso de Proof of Stake o similar, parte del mecanismo de staking deriva de contratos inteligentes desde la red principal.
- El puente está vinculado a la red y no provisto por terceros ajenos a la misma.
- Incluye otros mecanismos de dependencia con la red principal como el checkpointing.
- La red sólo utiliza una única blockchain como red principal; es decir, no concede estas características a 2 o mas redes al mismo tiempo.

A pesar de ello, una cadena lateral no tiene porqué cumplir con todas las caracteristicas mencionadas, por lo que estas definiciones siguen estando en discusión y debate, y los puntos de vista podrían cambiar en un futuro.

![sidechain.png](/uploads/sidechain_6fd8d4f677.png)
*Fuente: Horizen academy.*

La posibilidad de que estas cadenas laterales permitan resolver al usuario final alguno de los problemas y retos encontrados en la red Ethereum, como los altas altas comisiones, tiempos lentos de confirmación, poca capacidad de procesamiento de número de transacciones ante la demanda, entre otras, justifican su existencia. Además, si la red utiliza una implementación de la *máquina virtual de Ethereum* (EVM, por sus siglas en inglés), implica que la experiencia para el desarrollador y usuario promedio puede verse beneficiada, como la fácil puesta a punto de smart contracts y entendimiento de los modo de operación, lo cual impulsa el crecimiento del ecosistema dentro de ella, habilitando para las masas casos de uso como pagos, DeFi, NFTs, juegos y la experimentación.

POA Network, xDai, Skale y **Polygon PoS** son proyectos ejemplares de esta categoría de blockchains. En esta ocasión, *let's talk about Polygon PoS Chain*?.


### ¿Y qué es Polygon PoS?

Anteriormente conocida como la red Matic (o Matic Network), **Polygon PoS** es a toda regla una sidechain de la red Ethereum, compatible con la máquina virtual de la misma, con el propósito de escalar la actividad de los usuarios de dicha red principal, ofreciendo una plataforma base independiente en el cual transferir activos desde Ethereum y desplegar aplicaciones descentralizadas de cualquier índole, haciendo que todo el trabajo computacional de ejecución y validación de transacciones pase a estar asegurado por un set de nodos validadores regidos por el consenso de prueba de participación o *Proof of Stake* (PoS), con las características de ser una red con alta capacidad + bajo coste de transacciones. En pocas palabras, podemos trasladarnos en términos de usabilidad desde Ethereum hasta esta instancia separada pero bien conectada con dicha red y beneficiarnos de un entorno de mayor *throughput* (rendimiento).

Como primera impresión, en Polygon PoS, el alto rendimiento de la red está explicado por la producción de nuevos bloques cada [2-3 segundos](https://polygonscan.com/chart/blocktime) con un gas limit de 20M (asociado al tamaño de bloque), lo cual ha permitido alcanzar un procesamiento de ~4,8 millones de [transacciones diarias](https://polygonscan.com/chart/tx) en promedio desde que el protocolo Aave fuese lanzado al público y la actividad asociada al ecosistema DeFi tuviera lugar.

![polygonscan.png](/uploads/polygonscan_4c7e42ae6d.png)
*Fuente: polygonscan*

Hay razones para afirmar que Polygon PoS es una sidechain que posee características que las distingue del resto, denominándose también como cadena de *comité* o *commit chain*, que se mencionará más adelante. Empecemos a profundizar con los tópicos tales como tecnología base, validación, sus dos componentes principales Bor y Heimdall, y los puentes.


### Tecnología base

La arquitectura de Polygon PoS se concibe como un **híbrido de una cadena convencional de Proof of Stake** tomando una versión modificada del algoritmo de consenso Tendermint (de Cosmos SDK) llamada Peppermint, **e incorporando una solución de segunda capa primitiva conocida como Plasma**; o más bien, una variante de la misma: *Minimum Viable Plasma* (MVP). De este modo, ambos componentes están vinculados a la red Ethereum a través de diferentes contratos inteligentes que sustentan y permiten gestionar parte del consenso de la red, dar paso a su funcionamiento y administrar la seguridad de los fondos depositados por los usuarios en el puente. 

A nivel infraestructural, la red está instalada en una arquitectura de 3 capas:

1.  **Capa base**, situado en la red Ethereum, lugar donde se despliegan los contratos de staking y Plasma.

2.  **Capa Heimdall**, encargada de la agregación, validación y reportar el estado de la cadena a la red principal, rigiendo el trabajo de los validadores bajo el consenso de Proof of Stake.

3.  **Capa Bor**, como productora de bloques de la cadena lateral, en el cual por turnos los validadores se encargan de procesar las transacciones de los usuarios.

![maticnetwork.png](/uploads/maticnetwork_8e66402096.png)
*Fuente: whitepaper de Matic Network*

Aunque la solución de Plasma esté formalmente incorporado en esta infraestructura, el potencial de la misma (como el uso de pruebas de fraude) no es aprovechado como se pensaría, dado que casi toda la actividad se concentra en la cadena gobernada plenamente por el consenso de Proof of Stake, puesto que esta última es la que en realidad posee la compatibilidad con la EVM, que le da vida a prácticamente todos los smart contracts presentes en la red. 


### Validación y staking

A diferencia de otras cadenas laterales donde el consenso de la validación no está abierta para el público, quedando en manos de un conjunto cerrado y centralizado de operadores, en Polygon PoS la participación en la validación de la red ha estado abierta a libre ocupación por parte de los interesados en llevar a cabo esta actividad, pero admitiendo no más de 100 participantes de acuerdo a la configuración de la arquitectura en sí, lo que ha tenido como consecuencia que la red actualmente haya alcanzado el número máximo de validadores el [7 de mayo del 2021](https://twitter.com/0xPolygon/status/1390695696865447940). En otras palabras: validación no permisionada pero fijada a un número máximo de participantes (aunque por consenso, este número puede ser extendido mediante votación).

Como en toda cadena basada en prueba de participación, los validadores necesitan bloquear sus tokens MATIC en el [contrato de staking de Ethereum](https://etherscan.io/address/0x5e3ef299fddf15eaa0432e6e66473ace8c13d908) e ingresar en la red con sus nodos completos que los habilitará de participar en las capas de producción y validación. Si algún validador actúa de manera deshonesta o no participa en el consenso, su cantidad en stake se verá comprometida y eventualmente recortada. El usuario común también puede participar en el staking, delegando sus tokens a los validadores, recibiendo las mismas recompensas menos una comisión seteada por el validador.

Si bien parte de las reglas que derivan de los contratos de staking y plasma son las que regirán en parte el funcionamiento de la cadena lateral, al día de hoy **no son contratos inmutables** y [están en manos de los co-fundadores del proyecto y otros miembros del ecosistema](https://twitter.com/0xPolygon/status/1393256852201238534), avocados en abordar, en el mejor de los casos, futuras actualizaciones y corrección de errores críticos.


### Capa Bor

También conocido como Bor Chain, es la capa encargada de la producción de bloques para la cadena lateral,  **basada en una implementación básica de Geth (Go Ethereum o Ethereum Golang)** e inspirado en Clique, donde la plena compatibilidad con la EVM toma lugar. En esta capa (producción) todos los validadores no toman parte de esta actividad al mismo tiempo, sino que los productores de bloques son escogidos desde la capa Heimdall de forma aleatoria por grupos tomando como referencia los hashes (0xad823…) de los bloques de Ethereum para asegurar de que el proceso es auténtico. 

Los productores se organizan para generar estos bloques con transacciones, cuyo derecho de creación estará sujeto de forma proporcional según la cantidad de MATIC puesto en staking. Así pues, mientras más cantidad de MATIC en staking, mayor será la participación del validador en la producción. Expliquemos esto con un sencillo ejemplo:

1.  Asumamos que tenemos 3 validadores activos: **Alice**, **Bob** y **Clara**.

2.  **Alice** tiene 50 MATIC en staking, mientras que **Bob** y **Clara** tienen 20 MATIC cada uno en staking.

3.  Todos los validadores reciben cupos o slots según su cantidad de staking, como una manera de cuantificar su participación. Si **Alice** tiene 50 MATIC en staking y la red está configurada para dar un slot por cada 20 tokens (definido por la gobernanza entre validadores), **Alice** obtendrá 5 slots en total. Del mismo modo, **Bob** y **Clara** obtienen 2 slots cada uno.

4.  Se cuantifica el total de slots asignados a cada uno [A, A, A, A, A, B, B, C, C].

5.  Se emplean los hashes de los bloques de Ethereum como fuente reordenar el orden de sus participaciones.

6.  Como resultado obtenemos el siguiente orden [A, B, A, A, C, B, A, A, C].

7.  Ahora, dependiendo del recuento de productores (sujeto por la gobernanza de los  validadores), seleccionamos los validadores de izquierda a derecha, por ejemplo, si queremos seleccionar 5 productores, obtenemos el set de productores establecido como [A, B, A, A, C].

8.  Por lo tanto, el conjunto de productores para el siguiente tramo estaría definido como [A: 3, B: 1, C: 1].

9.  Usando este conjunto de validadores y el algoritmo de selección de proponentes de Tendermint, elegimos un validador como productor para cada sprint (conjunto de bloques asignados a producir) en Bor.

Con este mecanismo, se asegura la aleatoriedad del proceso de elección de productores, dando la posibilidad de que todos los validadores tengan oportunidad de producir los bloques, a la vez que garantiza que mientras más MATIC puesto en staking, más participación activa en la producción. 


### Capa Heimdall

La Heimdall Chain es la capa, que como se mencionó al principio, es donde el consenso toma lugar. A través de Heimdall, los validadores son enviados a “trabajar” en la producción de bloques en la Bor Chain mediante el mecanismo explicado anteriormente. A su vez, todos estos bloques creados en Bor, desde Heimdall son agregados en un árbol de merkle (los hashes de cada bloque generado en un periodo se juntan para generar un nuevo hash único) y se publican en Ethereum como prueba definitiva y punto de referencia sobre el estado de la cadena. Este proceso llamado **Checkpointing**, es heredado del mecanismo de plasma e implica una diferencia notable de Polygon PoS frente a otras sidechains que no incluyen este tipo de mecanismos.

A través del algoritmo de selección de proponentes por Round Robin, un validador es seleccionado para realizar el trabajo de validación y agregación de bloques, mientras que la infraestructura vigila el éxito o no del proceso para reiniciar la selección y proposición del nuevo o actual punto para checkpointing.

**El Checkpointing es el proceso crucial que explica porqué la red es denominada como una cadena de comité:** caracterizado por ser un proceso que ocurre en dos fases, el proponente envía el checkpointing con toda la información correspondiente (ID, bloques incluidos, hash árbol de merkle, etc) y +⅔ del set de validadores en stake lo convalidan, para dar paso a [publicar dicho estado de la red en Ethereum](https://etherscan.io/address/0x86e4dc95c7fbdbf52e33d563bbdb00823894c287). En la siguiente validación, un nodo validador envía una transacción de reconocimiento para demostrar que el checkpoint anterior fué realizado correctamente sobre la red Ethereum y continuar con el proceso. Este proceso es igualmente realizado por todos los validadores en algún momento y requiere de la aprobación de la mayoría en términos generales. Por lo tanto, los checkpoints y contratos de staking son considerados la última fuente de la verdad sobre el estado de la cadena lateral para los observadores externos, y son útiles también para la coordinación social entre validadores y responsables directos de los contratos para tomar como referencia y restablecer su estado en caso de que una conducta maliciosa o un conflicto caótico tenga lugar. 

![heimdallborr.png](/uploads/heimdallborr_9cf0d83bdb.png)

Además, el uso de checkpointing como referencia es importante para dar completa validez a las pruebas de quemado realizadas desde la cadena lateral como solicitud para el retiro de activos hacia la red Ethereum.

### Sobre los Puentes

El puente es el mecanismo por el cual los activos pueden virtualmente cruzar de Ethereum a Polygon y regresar. A diferencia de otras sidechains o blockchains donde el bridge es provisto por terceras partes de manera centralizada e incluso cobrando fees por su uso, [los puentes de Polygon PoS](https://wallet.polygon.technology/bridge/) transfieren los activos manteniendo el 1:1 para los usuarios, bloqueando los el activos (alojados en Ethereum) bajo los contratos de los puentes, y *minteandolos* (es decir, acuñandolos) en la cadena lateral. De modo inverso, como se mencionó en Capa Heimdall, la prueba de quemado efectuada desde la cadena lateral y confirmada a través del mecanismo de checkpointing, dan el aval para el retiro de fondos de vuelta a Ethereum, enviándose desde el contrato inteligente del puente a la billetera de los usuarios. Dado que la arquitectura de Polygon PoS es híbrida, de la misma manera dos puentes son concebidos:

#### - Puente PoS

Es el puente más utilizado, destinado para casi todos los activos de Ethereum, y asegurados por el completo set de validadores de Polygon PoS (que comprometen su staking) para la confirmación de depósitos y retiros. Este modelo de puente donde todos los validadores toman parte de su administración es el que les diferencia de de otras “blokchains L1” que incorporan servicios de puentes a Ethereum manejado por terceros y no por los propios validadores de la red en cuestión (Binance Smart Chain, Fantom, etc). La velocidad de retiro depende de la confirmación del próximo checkpoint una vez efectuada la solicitud, y podría tardar entre 20 y 180 minutos. 


#### - Puente Plasma

Destinado casi exclusivamente para el token MATIC y para activos que deseen ser usados en la solución de plasma, con restricciones de 7 días de espera (por el mecanismo de Plasma) para finalizar el retiro de este activo hacia la red Ethereum.

## Consideraciones finales

Como cadena lateral, Polygon PoS ha sido la red de mayor éxito en el último año, gracias a su infraestructura ha permitido que muchos usuarios tengan acceso a un entorno rápido y de bajo coste para el florecimiento de ecosistemas basados en DeFi, NFTs, DAOs y la experimentación. La flexibilidad de la red entre depósitos y retiros le da al usuario una experiencia relativamente cómoda para hacer uso conveniente de la misma. 

Sin embargo, dado su modelo de seguridad, la salud de la red está sujeta a la actuación honesta de la mayoría de validadores participantes (100) por poder de staking, que al final del día son los que resguardan cada minuto los fondos de los usuarios asegurados desde la red Ethereum y dictaminan lo que les pertenece a cada cual. Además, que Polygon PoS utilice la red Ethereum para administrar su seguridad no implica que Ethereum se haga cargo de su validación. Claramente esto la hace relativamente débil frente a redes activas de mayor envergadura como Bitcoin y Ethereum y teóricamente inferior a redes con modelos de seguridad novedosos como [las segundas capas de Ethereum](https://defilatam.com/optimistic-y-zero-knowledge-rollups/). Adicionalmente, la situación actual del manejo de los contratos de la red en Ethereum a través de una multisig, que idealmente tendrían la potestad de actualizar en caso de bugs y potenciales exploits, no dejan de significar un punto de centralización y riesgo de acciones maliciosas fulminantes ante una no descartable actitud negligente por parte de los responsables; aunque no seguirán trabajando en ofrecer modelos mejores de cara al futuro.

**En el corto plazo, cadenas laterales como esta son a primera vista beneficiosas y útiles para los usuarios y razonables para quienes evalúan sus ventajas respecto a sus riesgos. Desde DeFi LATAM abogamos al uso de ellas siempre que el usuario sea consciente de su funcionamiento y apoyamos a la continua investigación y construcción de soluciones más escalables y seguras.**

Fuentes:

1.  [Sidechains](https://ethereum.org/en/developers/docs/scaling/sidechains/)

2.  [Documentaci?n oficial de Polygon](https://docs.polygon.technology/)

3.  [Matic whitepaper](https://github.com/maticnetwork/whitepaper)

4.  [Polygon PoS Chain -- A Commit Chain And Not A Sidechain?](https://finematics.com/polygon-commit-chain-explained/)

5.  [Matic System Overview - Bor](https://forum.matic.network/t/matic-system-overview-bor/126)

6.  [Checkpoint Mechanism on Heimdall](https://forum.matic.network/t/checkpoint-mechanism-on-heimdall/127)

7.  [Matic System Overview - Heimdall](https://forum.matic.network/t/matic-system-overview-heimdall/125)



Polygon PoS es a toda regla una sidechain de la red Ethereum, ofreciendo una cadena base independiente en el cual transferir activos desde Ethereum y desplegar aplicaciones descentralizadas

medium_9.png

small_9.png

thumbnail_9.png

9.png

Sidechains: Entendiendo Polygon PoS

Los puentes son la piedra angular del futuro crosschain y en este artículo te explicamos qué son y sus tipos.

medium_photo_2022-05-01_11-04-06.jpg

small_photo_2022-05-01_11-04-06.jpg

thumbnail_photo_2022-05-01_11-04-06.jpg

photo_2022-05-01_11-04-06.jpg

Bridges en Blockchain: Construyendo puentes para criptomonedas

Guía sobre cuidados y recomendaciones para interactuar con plataformas crypto (centralizadas y descentralizadas).

medium_7.png

small_7.png

thumbnail_7.png

7.png

Manual de supervivencia: Seguridad en cripto


# ¿Cómo escala Ethereum a través de soluciones de layer 2?  

En la layer 1 de Ethereum (layer de la blockchain en donde se asientan las transacciones finalizadas) la alta demanda viene conduciendo a transacciones más lentas y precios del gas inviables. El objetivo principal de escalar la red es reducir los costos del gas y aumentar el throughput (transacciones por segundo) **pero sin sacrificar la descentralización ni la seguridad de L1.**

Los **rollups **son soluciones de layer 2 que ejecutan las transacciones off chain (*se implementan por separado de la layer 1; no requieren cambios en el protocolo Ethereum*) pero llevan los datos de las transacciones a la layer 1. Como los datos de las transacciones se asientan sobre la layer 1, **esto permite que compartan la misma seguridad**.

Ya que el **poder de cómputo** (*costo de realizar cálculos computacionales para la ejecución de smart contracts*) es la parte más lenta y costosa del uso de Ethereum, y esto se realiza off chain, permite escalar la red mejorando las TPS (transacciones por segundo) y reduciendo el costo del gas.

## Caracteristicas de un Rollup:

- Ejecución de la transacción off chain
- Los datos o ‘proof of transactions’ (prueba de validez de las transacciones en L2) se asientan sobre la layer 1.

os rollups requieren que los ‘operadores’ (validadores en PoS, mineros en PoW) bloqueen un depósito en garantía en el Rollup, el cual es susceptible de ser removido si actúan maliciosamente. Esto incentiva a los operadores a verificar y ejecutar transacciones correctamente.

# Zero Knowledge Rollups

Una prueba de conocimiento cero (ZK proofs) demuestra que alguien posee la veracidad de una información a otra persona sin revelar la información en sí. A través de las matemáticas, el probador puede demostrar que posee la información correcta sin necesidad de revelarla al verificador. Esto es importante porque el hecho de no compartir la información, significa que no se puede robar.

El t?rmino **‘Zero Knowledge’ (conocimiento cero)** se origina en el hecho de que no se revela ninguna información para realizar la verificación de los datos.

## ¿Cómo funciona?

Las transacciones se agrupan juntas, luego se firman y se envían al Layer 1 (Ethereum). Por lo tanto, se reduce la cantidad de datos almacenados en Ethereum. Todas las firmas se reemplazan por una prueba de conocimiento cero conocida como **SNARK**, que permite la compresión de las transacciones agregadas.

![image2.png](/uploads/image2_449a7e9bc6.png)


Créditos a Finematics por la imagen. 


## Modelo de seguridad en ZK Rollups

- **Validity proof (prueba de validez):** Un modelo de seguridad donde, para aumentar la velocidad, las transacciones se agrupan y se envían a Ethereum en una sola transacción. La transacción se realiza off chain y luego se envía a la main chain con una prueba de su validez. Este método aumenta la cantidad de transacciones posibles mientras mantiene la seguridad de la layer 1.
- **SNARK:** son pruebas criptográficas de validez con las que se puede probar la posesión de cierta información (una clave secreta, por ejemplo), sin revelar esa información, y sin ninguna interacción entre el probador y el verificador. Esta prueba criptográfica se asienta sobre la layer 1 en representación de todas las transacciones agrupadas en el ZK-Rollup.

Un SNARK incluye una prueba de validez para cada transacción que se incluye en un bloque.

Con los SNARKS es imposible que los retransmisores envíen información no válida o incorrecta. El SNARK prueba que la serie de transacciones enviadas, fueron correctamente firmadas por los propietarios y que las actualizaciones de los saldos de las cuentas son correctas.

Una vez que se envía una prueba de validez a la main chain y se verifica mediante el smart contract del Rollup, todas las transacciones en el bloque se finalizan y conllevan las mismas garantías de seguridad que las transacciones en la L1 de Ethereum.

El smart contract del ZK-rollup mantiene el estado de todas las transferencias en la layer 2, y este estado solo se puede actualizar con una prueba de validez. Esto significa que solo es necesaria la prueba de validez, en lugar de **todos los datos de todas las transacciones**.

No hay retrasos al mover fondos de la layer 2 a la layer 1 porque una prueba de validez aceptada por el contrato del ZK-Rollup ya ha verificado correctamente los fondos.

## Ejemplo: La cueva de Alí Babá

Un ejemplo muy simple de este concepto se puede ver con la cueva de Ali Baba, que es una cueva circular con una entrada y una puerta que sella el túnel en la parte trasera de la cueva.

Alice quiere demostrarle a Bob que posee la llave secreta que abre la puerta de la cueva de Alí Babá, pero no quiere mostrársela. Para esto Alice y Bob van hacia la cueva. Ambos caminos en la cueva se comunican sólo a través de la puerta mágica.

1) Alice entra a la cueva por A o por B, mientras que Bob se queda esperando en la salida de la cueva.

![image5.png](/uploads/image5_03b3088dac.png)


2) Bob elije que Alice salga por A o por B

![image3.png](/uploads/image3_86184868ff.png)


3) Si Alice tiene la llave que abre la puerta, puede salir por el lado que Bob le solicitó.

![image4.png](/uploads/image4_8dc458790b.png)


- Esto reduce a 50% las probabilidades de que Alice haya elegido en un primer intento el camino solicitado por Bob.
- La repetición de este esquema en varias ocasiones sirve entonces, para determinar que realmente Alice tiene la llave secreta para abrir la puerta, pero en ningún momento se la reveló a Bob.

# Optimistic Rollups

Corre una EVM (*Ethereum Virtual Machine*) llamada OVM (*Optimistic Virtual Machine*) que permite ejecutar los mismos smart contracts que en la layer 1. Esto es importante ya que permite a las aplicaciones ya existentes conservar su composabilidad, dado que los smart contracts en Ethereum son públicos, los desarrolladores no necesitan escribir nuevamente el smart contract, solo necesitan saber interactuar con los ya existentes para deployar uno nuevo en la OVM.

Todos los fondos en un Rollup se mantienen mediante un solo smart contract, en el que los secuenciadores dejan un depósito en garantía que puede removerse si actúan maliciosamente. Se opera bajo el supuesto de que todos actúan de manera ética y correcta, pero se incluye una alternativa en caso de que llegue una parte malintencionada.

En un Optimistic Rollup, el nuevo state root es publicado por los secuenciadores sin ser verificado cada vez por el smart contract del Rollup. En cambio, todos esperan que la transición del estado sea correcta. Sin embargo, si se publica una transición de estado incorrecta, los verificadores o usuarios (que deben observar lo que está sucediendo en la layer 1 del Rollup, ejecutando cada transacción) podrán apuntar a la transacción no válida y revertir el bloqueo incorrecto (ganando recompensas por ello), reduciendo drásticamente a los operadores maliciosos.

El propósito de esto es simple: permite que un nodo teniendo solamente el último bloque, junto con cierta seguridad de que el último bloque es en realidad el bloque más reciente, se “sincronice” con la blockchain rápidamente sin verificar ninguna transacción histórica.

## Conceptos a tener en cuenta:

- **State root**: el hash raíz que almacena todo el estado del sistema de la blockchain: todos los saldos de cuenta, almacenamiento de contrato y código de contrato están adentro. Es de utilidad para verificar la autenticidad de los datos recibidos.

- **Fraud Proof (prueba de fraude)**: las transacciones en los OR se asume que son válidas, pero pueden cancelarse si se sospecha de fraude. Si esto sucede, una prueba de fraude ejecutará la transacción nuevamente para corroborar si ocurrió el fraude.

- **Secuenciador**: Son responsables de almacenar y ejecutar las transacciones enviadas por los usuarios. Deben enviar periódicamente el estado de las transacciones que reciben y los **state roots** resultantes en Ethereum.

- **Verificadores**: son responsables de buscar fraudes y, si hay una discrepancia entre el estado de la layer 1 y la layer 2, publican una prueba de fraude. Si alguien sospecha de fraude, puede probarlo alertando a un verificador en la red principal de Ethereum, que puede verificar la validez (o invalidez) de los resultados producidos por el secuenciador utilizando la OVM.

## Secuencia de una transacción en un Optimistic Rollup

1) Se envía la transacción off chain (fuera de la blockchain principal de Ethereum) a un secuenciador para que ejecute la transaccion.
2) El secuenciador ejecuta la transacción y lo asienta en el nuevo state root.
3) El secuenciador envía una transacción de Ethereum (*pagando el costo del gas correspondiente a la layer 1, esto es, una transaccion de Ethereum normal*) que contiene la transacción y el nuevo state root (el bloque creado en el Optimistic Rollup).
4) La transacción ahora es asentada sobre la layer 1 de Ethereum y asegurada por la red.
optimistic-rollups

![image1.png](/uploads/image1_f20cbb70fb.png)

Interdax.

## Incentivos en Optimistic Rollups

La escalabilidad sobre L2 se basa en el hecho de que se intenta minimizar el número de transacciones on-chain (transacciones sobre la layer 1). Se usan *pruebas de fraude* para cancelar cualquier transición de estado inválida que pueda ocurrir. Pero dado que una prueba de fraude es una transacción on-chain, también es ideal minimizar la cantidad de pruebas de fraude que se ejecuten en Ethereum.

Esto se puede desincentivar mediante los requerimientos para ser un Secuenciador, explicado a continuación:

Para que un usuario se convierta en un secuenciador, primero debe depositar una garantía en Ethereum, que perderá si se prueba el fraude. Para incentivar a las personas a buscar fraudes, si el fraude es probado, la garantía del secuenciador se remueve y se distribuye a los verificadores. Cuanto mayor sea lo que el secuenciador deja en garantía, mayor será el incentivo para convertirse en verificador y menor será el incentivo para cometer fraude como secuenciador.

Es importante señalar que los secuenciadores y verificadores deben ejecutar un nodo completo de Ethereum y un nodo L2 completo, para producir el estado de L2. Los verificadores ejecutan el software responsable de *crear pruebas de fraude* y los secuenciadores ejecutan el software responsable de agrupar las transacciones de los usuarios y publicarlas.

Ben Jones de [Optimism](https://twitter.com/optimismPBC) describe el bonding system (sistema de depósito en garantía):

> *Básicamente, se toma algo de ETH, se bloquea y se dice ‘Prometo decir la verdad’ … Si no digo la verdad y se prueba el fraude, este dinero será removido y quemado. No sólo se removerá parte de este dinero, sino que parte de él pagará por el gas que la gente gastó en la prueba de fraude”*

Básicamente, **los participantes son penalizados por cometer fraude y reembolsados por demostrar el fraude**.

# Seguridad y Disputa de transacciones

Es importante implementar correctamente este mecanismo de castigo, de lo contrario, podría explotarse en la práctica. Acá hay un ejemplo de una implementación ingenua que no funcionaría:

1) Alice deja en garantía 1 ETH para convertirse en secuenciador
2) Alice publica una actualización de estado fraudulenta/invalida
3) Bob se da cuenta de eso y publica una disputa. Si tiene éxito, esto debería otorgar el 1 ETH de la garantía de Alice a Bob y cancelar la actualización de estado fraudulenta
4) Alice se da cuenta de la disputa y también publica una disputa (disputándose ella misma)
5) Alice recibe su 1 ETH, sin pagar ninguna multa a pesar de que intentó cometer un fraude.

Alice puede montar este ataque a través del llamado ‘frontrunning’,  es decir, enviando una transacción idéntica a la de Bob pero con un precio de gas más alto, lo que hace que la transacción de Alice se ejecute antes que la de Bob. Esto significa que Alice puede intentar engañar constantemente con costos mínimos (solo pagando el gas de Ethereum).

**Arreglar esto es simple**: en lugar de otorgar la garantía completa al disputador, un % se quema en su lugar. En el ejemplo anterior, si quemamos el 50%, Alice recibiría 0.5 ETH, lo que sería un desincentivo suficiente para no intentar cometer fraude en el Paso 2.

Es importante que exista un mecanismo para garantizar que las transacciones sean legítimas y no fraudulentas. Acá es donde entran las Fraud Proof. Si alguien nota una transacción fraudulenta, el Rollup realizará una prueba de fraude y ejecutará la transacción nuevamente, utilizando los datos de estado disponibles.

Cada vez que el secuenciador publica un conjunto de estado de transacciones, hay un “**período de disputa**” (*rango de tiempo durante el cual se puede publicar una prueba de fraude, después del cual una transacción L2 se considera segura en L1*) durante el cual cualquiera puede publicar una “*prueba de fraude*“. Esto se demuestra al reproducir nuevamente la transacción que causó la transición de estado y comparar el *state root** resultante con el que publicó el secuenciador. Si los state root no coinciden, entonces la prueba de fraude es exitosa y la transición de estado se cancela.

Si hubo más transiciones de estado después de la inválida, también se cancelarán. Las transacciones que son anteriores al período de disputa ya no se pueden disputar y se consideran finalizadas.

**Acá es necesario tener en cuenta que:**

Un largo período de disputa proporciona mejores garantías de seguridad contra ataques de censura.

- **Pero esto no es bueno para la adopción** de Optimistic Rollups, ya que los usuarios que quieran retirar sus fondos de L2 a L1 tendrán que esperar, digamos, 7 días +/- para que puedan ser efectivizados.

Un período de disputa más corto crea una experiencia de usuario amigable para los usuarios que retiran fondos de L2 y vuelven a la L1 porque no necesitan esperar mucho antes de poder reutilizar sus fondos en la L1.

- Pero nuevamente, esto conlleva **menor seguridad** ya que se corre el riesgo de que ocurra un fraude y no se incluya ninguna disputa a tiempo.

El modelo de seguridad de OR se basa en el supuesto de que hay al menos 1 de N participantes honestos que ejecutan todas las transacciones del Rollup y enviarán una prueba de fraude en caso de que se publique una transición de estado no válida.

Es realista esperar que solo los secuenciadores de OR supervisen y ejecuten las transacciones. Los usuarios normales no tendrán incentivos para hacerlo, ni capacidades técnicas para procesar transacciones. Afortunadamente, los secuenciadores están naturalmente incentivados a verificar la corrección de los bloques de los demás, porque si crean un bloque encima de uno no valido los fondos que han dejado bloqueados les serán removidos.

Debido a los problemas mencionados en la sección de seguridad anterior, OR solo puede ser seguro con una ventana de tiempo de 1 a 2 semanas para ejecutar pruebas de fraude. Ninguna transacción se puede considerar finalizada hasta que pase este tiempo, ni una transferencia hacia el rollup ni una salida del mismo.

# Críticas a la seguridad de Optimistic Rollups:

El dilema del verificador crea desincentivos para operar un verificador, rompiendo la seguridad:

Ed Felten escribió un [análisis ](https://medium.com/offchainlabs/the-cheater-checking-problem-why-the-verifiers-dilemma-is-harder-than-you-think-9c7156505ca1)y una solución al dilema del verificador, resumida a continuación:

- Si los incentivos del sistema funcionan según lo previsto, nadie cometerá fraude
- Si nadie comete fraude, entonces no tiene sentido ejecutar un verificador porque no se gana dinero al operarlo.
- Dado que nadie ejecuta un verificador, eventualmente existe una oportunidad para que un secuenciador cometa fraude.

Para no alarga el artículo, pueden leer la resolución a este dilema (en inglés) desde aquí: [Solución al dilema](https://medium.com/offchainlabs/cheater-checking-how-attention-challenges-solve-the-verifiers-dilemma-681a92d9948e)

## Fuentes:
1. ([Almost) Everything you need to know about Optimistic Rollup](https://research.paradigm.xyz/rollups)
2. [How does Optimism's Rollup really work?](https://research.paradigm.xyz/optimism)
3. [Scaling Ethereum on L2: Optimistic Rollups and ZK-Rollups](https://medium.com/interdax/ethereum-l2-optimistic-and-zk-rollups-dffa58870c93)
4. [Optimistic vs. ZK Rollup: Deep Dive](https://blog.matter-labs.io/optimistic-vs-zk-rollup-deep-dive-ea141e71e075)
5. [LAYER 2 ROLLUPS](https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/)
6. [Ethereum LAYER 2 SCALING Explained](https://finematics.com/ethereum-layer-2-scaling-explained/)
7. [Understanding the Optimistic Ethereum Protocol](https://community.optimism.io/docs/protocol/protocol.html#introduction)



Soluciones de Layer 2 para la escalabilidad de Ethereum sin sacrificar seguridad ni descentralización

Blogs

Filtrar por: