Estos problemas han hecho que las elecciones sean vistas con escepticismo. Es claro que la OEA, las reformas y las fuerzas armadas no han sido suficiente para restaurar la confianza. Tampoco el internet, pues está sujeto a la manipulación de votos electrónicos. Y aunque las blockchains, como Ethereum, resuelven el problema de la manipulación, tienen un defecto: la información es pública, lo que abre la puerta a la coerción y el soborno.

Aquí entra una tecnología relativamente reciente: Zero Knowledge (ZK). Aunque su origen data de los años 80, ha sido en los últimos años que ha dado saltos significativos, prometiendo restaurar la confianza no solo en las elecciones, sino en múltiples áreas.

¿Qué es Zero Knowledge?

Zero Knowledge, o ZK, permite demostrar algo sin revelar información adicional. Por ejemplo:

• Para entrar a una discoteca: Probar que soy mayor de edad sin revelar mi edad.

• Para obtener un préstamo: Demostrar que tengo suficiente salario para un préstamo sin revelar la cantidad exacta.

• Para votaciones: Mostrar que soy parte de un grupo de votantes sin revelar cuál soy.

En elecciones, ZK podría permitir a los ciudadanos demostrar que tienen derecho a votar sin exponer su identidad, previniendo la coerción y el fraude. Pero, ¿cómo funciona ZK a nivel técnico?

La Parte Técnica: ZK y Elecciones

Imagina que cada ciudadano tiene un par de llaves criptográficas: una llave pública y una llave privada. La llave pública es como tu número de identidad, mientras que la llave privada es un secreto personal que usas para probar que esa identidad te pertenece, sin necesidad de exponerla.

Una propiedad fundamental de las llaves criptográficas es que, con la llave privada, puedes generar tu llave pública, pero no al revés. Esto se logra usando funciones hash, las cuales convierten la llave privada en una llave pública. La función hash es unidireccional, lo que garantiza la seguridad de tu identidad.

hash(llavePrivada) = llavePublica

Cuando un ciudadano vota, su voto se puede incluir en una prueba de inclusión ZK. Esta prueba permite demostrar que un ciudadano está en una lista de votantes sin revelar quién es ni por quién votó.

Aquí entra en juego el concepto del Árbol Merkle, una estructura de datos que permite validar pruebas de inclusión de forma eficiente. Cada nodo del árbol es el hash de los nodos hijos, y el nodo raíz representa la lista de todos los votantes. Esto permite a cada votante generar una prueba de que está en la lista en tiempo logarítmico O(log n), sin que el sistema tenga que verificar toda la lista cada vez en tiempo lineal O(n). Este tipo de optimización es importante para poder ejecutar votaciones con un gran número de personas, ya que ZK es computacionalmente demandante, y necesitamos que cada votante pueda emitir su voto desde dispositivos personales.

Ejemplo de Prueba de Inclusión en ZK

inclusionProof(private: llavePrivada, public: listaVotantes) {
  llavePublica = hash(llavePrivada)
  existe = listaVotantes.contains(llavePublica)
  return existe
}

En este pseudocódigo, la función toma como entrada la llave privada y la lista de votantes (almacenada en un Árbol Merkle). Esto genera una prueba ZK que demuestra que la llave pública del votante está en la lista, sin revelar quién es ni detalles de la llave privada.

Verificación en Ethereum

Una vez que los votos se registran, se necesitan lugares confiables para validar las pruebas ZK y asegurarnos que nadie votó dos veces. ¿Dónde? La respuesta es Ethereum. Ethereum es una blockchain global descentralizada y resistente a la censura, donde cualquiera puede validar transacciones y pruebas. De esta manera no dependemos de gobiernos o empresas centralizadas como ser Google Cloud, Amazon Web Services, Microsoft Azure o el resto del internet al que estamos acostumbrados a usar hoy.

Con Ethereum, podemos verificar pruebas ZK de manera pública y segura. Aunque otras blockchains como Solana o Avalanche también son opciones, ninguna ofrece las garantías de seguridad y descentralización que Ethereum proporciona. La única vulnerabilidad sería lo que comúnmente conocemos como el ataque del 51%, pero hoy en día se necesitarían decenas de miles de millones de dólares para ejecutar este ataque.

¿Por qué No Usamos ZK Aún?

Aunque la tecnología ZK ha avanzado mucho, todavía está en fases experimentales. Los lenguajes como Circom, Noir, y Zokrates permiten crear circuitos ZK, pero aún quedan desafíos por resolver, como la escalabilidad y el costo computacional de generar pruebas ZK en dispositivos personales.

Además, otro gran obstáculo es cómo manejar el emisor de identidades. Si no confiamos en el gobierno para emitir identidades, necesitaríamos soluciones alternativas como la identificación biométrica o los grafos sociales (como los proyectos BrightID y Ethereum Attestation Service), donde las personas se verifican entre sí para combatir ataques Sybil.

Mi Nota Personal

Años atrás, comencé como desarrollador de videojuegos profesional y fullstack, pero luego enfoqué mi carrera hacia blockchain y luego, ZK. Creo que, aunque aún hay barreras por superar, estamos más cerca de lo que parece de lograr una adopción masiva de esta tecnología, que puede resolver los problemas actuales de confianza y privacidad.

Si te interesa iniciarte en el desarrollo ZK y contribuir a un futuro donde interactuemos de manera más justa, te invito a ver mi curso introductorio completo sobre ZK, donde además podrás acceder a excelentes oportunidades laborales a nivel mundial.

Gracias por leer, también me puedes encontrar en twitter, instagram y youtube para lo más nuevo en temas de desarrollo en ZK.

Quizás escuchaste que ZK es fundamental para Ethereum, ¡y sí es verdad! Esta tecnología trae dos propiedades muy importantes: la escalabilidad y la privacidad. Ya hemos visto la rápida implementación de ZK en escalabilidad a través de los rollups. Desde que zkSync lanzó su canal de pagos, hasta hoy que tenemos Rollups zkEVM que ofrecen la misma experiencia que Ethereum pero a una fracción de su costo.

Entonces, ¿porqué no ha ocurrido lo mismo con la privacidad? ¿Porqué no hay aplicaciones en Ethereum que hagan uso de la privacidad de ZK?

¿Es tán difícil ZK?

En realidad, no tanto.

Al inicio pensé que era un problema de falta de investigación. O falta de las herramientas necesarias para crear aplicaciones de esta naturaleza. Pero este claramente no es el caso pues seguramente hacer una zkEVM es mucho más complicado que, por ejemplo, votos anónimos on-chain.

Con esto no quiero decir que hacer aplicaciones con privacidad es sencillo, se necesita unir una serie de tecnologías: contratos, circuitos, probadores WASM en el navegador, una red de relayers incentivados. Pero a pesar que sea complejo no deja de ser accesible. Por cierto, si te llama la atención tengo una guía paso a paso sobre cómo hacerlo.

Habiendo descartado esta posibilidad, a continuación comparto las 3 razones por las que no hay aplicaciones de privacidad con adopción masiva en Ethereum.

Problema #1: Incertidumbre regulatoria

Saquemos primero el elefante en la habitación. El proyecto de privacidad con mayor cantidad de usuarios que ha tenido crypto ha sido Tornado Cash. Un mixer capaz de mantener nuestras finanzas privadas, protegiendo así nuestra soberanía y seguridad como individuos. El problema es que también se le da el poder a los hackers, estafadores y otros actores maliciosos de borrar su rastro.

Hoy Tornado Cash está prohibido para los ciudadanos estadounidenses, los repositorios de github archivados y un desarrollador en la cárcel (nota: se presume que no está en la carcel por desarollar en sí). Esto ha generado un clima de incertidumbre en los desarrolladores, inversionistas y usuarios.

La solución a este problema existe dentro la misma tecnología. Para entenderla primero debemos hablar ver cómo funciona un mixer. En resumidas cuentas, un mixer en el fondo usa algo que llamamos Prueba de Inclusión, donde demostramos que depositamos en un smart contract específico sin revelar cuál depositante somos. De esta manera podemos retirar fondos a una nueva address limpia.

La solución es aplicar el proceso inverso, una Prueba de Exclusión, para demostrar que no soy uno de los address excluídos o blacklisteados. Combinando ambas pruebas, la de inclusión con la de exclusión, puedo demostrar que soy un depositante honesto y mantener mi identidad privada.

El debate moral sobre bajo qué criterios se excluye un participante persiste. Pero ZK es una tecnología flexible y expresiva que puede adaptarse a diferentes regulaciones o requerimientos.

Problema #2: Mala UX

Esto va más allá que el problema de guardar las 12 palabras en un papel para crear una wallet. Sí, este es un problema que tenemos en web3 y seguimos trabajando para resolver. Pero ZK le agrega un nuevo inconveniente: largos tiempos de prueba en el cliente.

Resulta que el equipo de Ethereum, en etapas iniciales de desarrollo no sabía que iba a ser tán problemático implementar Keccak256 como algoritmo de hasheo para crear las cuentas. Pedersen o Poseidon son opciones con tiempos de para producir pruebas ZK mucho menores.

Si un desarrollador decide tomar el camino de Keccak, los usuarios pueden usar por ejemplo Metamask o Rabby. Pero el tiempo de generar una prueba es de varios minutos en una PC. Este problema se hace más grave en un celular porque adicionalmente se debe de tomar el sistema operativo no cierre el proceso si el usuario lo pone el teléfono en modo reposo.

Por otro lado, si se decide tomar el camino de Pedersen o Poseidon, se necesita crear un sistema de cuentas que no es compatible con las wallets de Ethereum como Metamask. ¿Quizás la solución es crear un sistema de cuentas con abstracción de cuentas combinado con una wallet nueva que los usuarios tienen que instalar? Suena como un esfuerzo bastante alto para onboardear usuarios.

Como nota positiva, hay bastante expectiva en métodos para reducir los costos y tiempos de espera usando Keccak256. Existen varios estudios y papers que en el futuro próximo serán aplicados.

Problema #3: Nulificadores ECDSA

Este problema es bastante técnico así que les invito a tener más paciencia.

Anteriormente mencionamos que usamos las Pruebas de Inclusión para demostrar que somos parte de un grupo sin demostrar cuál somos. Entonces ¿cómo prevenimos a alguien retirar dos veces los mismos fondos de un mixer? La respuesta es por medio de algo que llamamos nulificadores. Los nulificadores son una técnica creada para resolver el problema de, por ejemplo, el doble gasto (double spend) en DeFi, o de doble voto en un sistema de votación.

En Ethereum, podemos implementar nulificadores de la siguiente manera:

1. Los usuarios son colocados en una lista (o merkle tree), puede ser por ejemplo la lista de depositantes en un mixer, la lista de votantes o la lista de usuarios en una red social anónima.

2. Los usuarios firman un mensaje, este se usa para generar una prueba de manera local (en el navegador del usuario). La prueba contiene un hash de, en parte, la firma de un mensaje. De esta manera se puede verificar que es una firma válida sin revelar el orígen. A este hash le llamamos el nulificador.

3. Al pasar la prueba a un contrato de Ethereum, almacenamos el nulificador en el contrato (usualmente en un mapping(bytes32 nullifier => bool exists)). Únicamente se aceptan pruebas con nulificadores nuevos, de esta manera cada prueba o acción puede ser aplicada solo una vez.

El problema que tenemos es que el sistema de firmas actual no es nulificable. Es decir, las firmas implementadas en las wallets como Metamask, Rabby, Coinbase no tienen un mecanismo para generar hashs únicos. Y tampoco, con justa razón, mecanismos para extraer las llaves privadas.

Necesitamos implementar un nuevo sistema de firmas en las wallets. Pero este sistema debería ser adoptado por todas las wallets por igual, debería de existir un consenso. El mejor candidato que tenmos hoy es Plume. Y ya existen PRs, las wallets principales listos para ser mergeados. Pero las wallets se resisten a aceptarlo pues quieren estudiar primero la seguridad e implicaciones.

La alternativa también es implementar un sistema de firmas aparte con abstracción de cuentas (AA) que sea nulificable. Pero la comunidad de Ethereum no se ha decidido en un estandar aún.

Si eres un desarrollador nuevo en ZK, es importante no dejarte frenar por estas dificultades. Al contrario, busca alternativas creativas o soluciones a estas limitantes. Este es el espíritu que ha tenido blockchain y web3 desde su inicio. Estoy seguro que ZK seguirá avanzando y es por eso sigo estudiando de cerca esta tecnología.

¡Gracias por leer! Sígueme en Youtube, Twitter y dev.to para todo lo relacionado a ZK y Ethereum.

El origen de este concurso

En mi canal de youtube y blog me dedico a difundir las tecnologías en web3 de actualidad y que me parecen más importantes. Fue por eso que, al recibir fondos de las rondas de financiamento de ETH Latam y Ethereum TGU decidí lanzar un concurso para premiar a hackers que estudien tecnologías nuevas y escriban artículos. Lancé este programa través del artíclo que comparto a continuación donde explico los detalles sobre las reglas y mecanánicas:

https://mirror.xyz/filosofiacodigo.eth/f4ONOeNr6jKpif9L661juEUXUD7TtEaE0mV2Aeiyzbc

Resultados

Hubieron 2 ganadores del concurso que recibieron 300 DAI como premio.

• Lidia Canales
  Tema: Cómo interactuar desde una webapp con un Smart Contract con privacidad
  Síganla en Youtube

https://mirror.xyz/0xe527275DA855C658de60EcA230800458f668194B/zaNEPzGH-EQ909NYmL-KwvzByVDE0PTWQJU-4FKddRk

• Gilberts Ahumada
  Tema: Tokens con privacidad en Aztec Sandbox
  Síganlo en Youtube, Twitter e Instagram

https://gilbertsahumada.hashnode.dev/aztec-network-configuracion-sandbox-y-despliegue-de-un-token

• Como un extra, Gilberts y yo lanzamos un video usando el artículo que escribió

Cosas a repetir y cosas a mejorar

La calidad y el formato del contenido creado superó grandemente mi espectativa. Me gustaría hacer más concursos donde se promueva la producción de contenido técnico relevante y de actualidad. Ambos, Gilberts y Lidia, no solo explicaron paso a paso la tecnología sino que también expresaron su opinión sobre porqué esta tecnología les parece imporante.

Habiendo dicho esto, me parece que la dificultad de los retos fue demasiado elevada. Varios otros participantes me comentaron que intentaron cumplir un reto pero no lo lograron por su complejidad. Me gustaría que para una futura entrega debería acortar la distancia entre la dificultad del reto y sus participantes. Idealmente, creando más y mejor contenido educativo para preparar a los participantes de antemano. Además la creación de este contenido más introductorio podría ser a través una futura entrega de este programa.

Al inicio, tenía dudas sobre en qué momento lanzar el concurso. Sentía habían muchos hackathones y eventos durante las mismas fechas. Pero viendo hacia atrás me parece bien haberlo lanzado porque la actividad en web3 nunca para, así que solo es algo para tomar en cuenta pero el momento del lanzamiento siempre vá a colisionar con otros eventos.

En cuanto a los canales de distribución únicamente usé los mios personales. Y cuentas de twitter de individuos y organizaciones amigas me ayudaron a amplificar. Ahora que ya estoy más seguro sobre cómo debería funcionar un programa de este estilo me gustaría hacer una estrategia más planificada donde también se incluyan a los protocolos sobre los que se estará generando contenido.

Finalmente, ¡debo buscar alguna manera de prevenir que los bots farmeros inunden mi formulario!

¿Qué sucederá con el resto de los premios?

Estoy considerando hacer una segundo concurso y usar los fondos provinientes de la CRL restantes para eso. Pero si estás leyendo esto y te llama la atención hacer uno de los retos restantes comunícate conmigo y lo hablamos.

Al momento de escribir este artículo, los premios faltantes son:

• Firmas con plume: Verificar firmas nulificables de ECDSA en Aztec o Circom

• OP Stack + Eigen DA: Guardar los datos del OP Stack

• ZKML con Giza: Demo sobre verificación on-chain de un output de un modelo de IA

• Zokrates + Nova: Demo sobre folding usando Zokrates

En este link puedes ver la lista actual y completa.

Graciás por leer este artículo y para mantanerte al tanto de avances suscríbete en youtube y sigue a @FilosofiaCodigo en twitter y farcaster.

¿Cómo funciona un Crypto MMO?

Un MMORPG (juego de rol masivo online) es un videojuego donde cada usuario controla un personaje y junto con otros jugadores emprenden en aventuras subiendo de nivel y coleccionando items.

Crear un juego de estas características es bastante trabajoso, requiere de:

• Un backend que permita muchos usuarios simultáneamente

• Un cliente capaz de manejar actualizaciones

• Herramientas para definir la lógica de las misiones, diseño de mapas y animaciones

• Gráficos, audio, música consistente

• Historia y progresión cohesiva

Es por eso que para lanzar mi propio juego forkié un proyecto llamado The Mana World. Este proyecto es open source y cuenta con todo lo necesario para crear un juego de esta naturaleza. Actualmente, The Mana World en sigue en funcionamiento.

La diferencia de mi servidor con el resto era el hecho que cada personaje en el juego controlaba su propia wallet. Este fue el punto de entrada para más funcionalidades que implementé poco a poco.

Funcionalidades crypto que implementé

El primer paso fue implementar un wrapper de bitcoin en c++ dentro del backend. El wrapper es capáz de comunicarse con un nodo full RPC de dogecoin (o bitcoin, que es lo mismo) corriendo localmente en el mismo ambiente que el servidor. De esta manera, la primera versión del juego permitía a los jugadores tanto depositar y retirar fondos como hacer transacciones internas sin pagar comisión. Esto a través de comandos en la ventana de chat dentro del juego.

El siguiente paso fue habilitar transacciones de Dogecoin a nivel del scripting propio del juego, este fue el reto más grande.

Los videojuegos con naturaleza compleja como este usualmente están programados en lenguajes de uso general y con librerías orientadas para labores de ingeniería. Esto no es la exepción en TMW, más aún, el motor utilizado va un paso más allá pues está implementado usando C++ y usando únicamente librerías multimedia. Es decir, un ambiente muy seguro y escalable pero súmamente complicado para diseñar niveles, historia, misiones.

Es por eso que la mayoría de este estilo de juegos crean un nuevo lenguaje de scripting para labores de diseño, aisladas de las minuciosidades de lo que concierne a la arquitectura e ingeniería. Al implementar la interacción con el RPC de bitcoin a nivel de scripting, se abre la posibilidad de enfocarse en la experiencia crypto. Estas fueron las que implementé donde linkeo los scripts respectivos:

1. La fuente de los deseos: Un faucet que te regalaba 5 doges al día

2. Doge ATM: Un ATM dentro del juego capaz de hacer transacciones on-chain

3. La cueva del PvP: Battle royal donde pagas para participar, el último jugador en pie se lo queda todo

Recepción de la comunidad

El factor novedad definitivamente fue un factor para atraer usuarios. Pero recuerda que dogecoin pre-elon era muy diferente. No estoy seguro si ya existía crypto twitter en aquellos días pero discord ni había lanzado. Dogecoin tenía una comunidad pequeña mayormente en IRC, luego también en Reddit y algunos foros.

Encontré este post en reddit y también este video si te llama la atención conocer cómo era la comunidad en aquel entonces. (Nota: qué increíble cringe sentí al volver este video)

Me ponía muy feliz encontrarme ocasionalmente con jugadores probando las funcionalidades de dogecoin que implementé. Aunque debo admitir que me ponía un poco nervioso que, a pesar de mis mensajes de advertencia que el juego estaba en beta y era custodial, los usuarios depositaban considerables sumas de doges.

Y pues el desenlance de esta historia no es feliz, olvidé pagar el servidor donde estaba hosteado el juego y borraron toda la data, incluído el dinero de los usuarios.

No tenía backup de la llave privada.

Expliqué todo lo sucedido en la comunidad y mas bien recibí mucho apoyo y aliento. Pero sin lugar a dudas este incidente fue un factor detractor que me desmotivó de seguir con el proyecto.

Si lo hiciera de nuevo hoy, ¿cómo lo haría?

En 10 años mucho ha cambiado, incluída mi vida profesional. Durante este tiempo el desarrollo de juegos para mí pasó de ser un hobby a convertirse en mi carrera donde participé en varios equipos de desarrollo, desde bandas de una sola persona hasta studios AAA. Lo mismo sucedió con web3, que hoy estoy involucarado 100% a nivel profesional como devrel en Scroll la L2, creador de contenido en mi canal de youtube y desarrollo de shitcoins en las que no me voy a doxxear.

En este contexto fué que leí este tweet que me motivó a escribir este artículo.

https://x.com/pablowasserman/status/1804311956867711092

La tecnología ha cambiado, yo he cambiado. Si lo hiciera todo de vuelta, ¿cómo lo haría hoy?

Usar las nuevas funcionalidades de Ethereum

Ethereum y las L2s son mis favoritas, pero puede ser cualquier blockchain con smart contracts. El punto es que con la tecnología nueva se pueden hacer sistemas con buena experiencia de usuario y self custodial. De esta manera ya no se corre riesgo de que todos pierdan su dinero por no pagar un servidor.

En web3 hoy podemos apalancarnos de lo siguiente para ofrecer una experiencia novedosa:

• Account Abstraction puede introducir a los jugadores de una manera sencilla

• La economía de relayers combina AA con intents para generar oprtunidades de generar ingresos y ofrecer a los usuarios la experiencia de interactuar con crypto sin que se den cuenta

• ZK abre la posibilidad de que los usuarios participen en mecánicas de juego divertidas sin sacrificar su soberanía ante un backend web2. Dark forest ha demostrado lo que ya es posible.

• El ecosistema DeFi ya existente puede servir como base y también puede empujar la economía del juego.

De nuevo, forkearía un proyecto open source

Blockchain todavía es una tecnología muy nueva. En vez de hacer un motor desde cero, volvería a usar un proyecto en funcionamiento para no perder tiempo reinventando la rueda. Así, me enfocaría en las partes que necesitan mayor exploración: la economía, las interacciones on-chain y las facetas sociales y comunitarias.

El ambiente open source me parece el ídeal para llevar a cabo un proyecto pues comparte muchos valores fundamentales con crypto.

Estado actual de la cultura web3

Pienso que blockchain trae inevitablemente cambios sustanciales en la cultura a nivel global. Así que, al momento de construir cualquier proyecto web3 es necesario conectarlo y negociar ”qué tan web2 o web3” será.

Hoy tenemos comunidades crypto, interés a nivel mundial, financiamiento, desarrolladores y proyectos con quienes trabajar en conjunto. Además, el péndulo de “los videojuegos NFT son una estafa” está terminando su cíclo.

Me parece un buen momento para re-explorar la idea de un MMO crypto.

What is an Emoji language?

Emojity is a programming language for writing smart contracts on Ethereum. You can think of Emojity as an alternative to Solidity and Vyper, with the difference being that you write all the logic using only emojis.

Why use Emojity? Emojity is not only a more creative and fun way to write smart contracts but also aims to help diversify Ethereum at language level to make it more resilient.

How to win 1 ETH?

The bug bounty is about breaking a simple staking contract written in Emojity. In that contract I staked 0.5 ETH and only I should be able to withdraw it. However, if you manage to break the contract and obtain the funds through an error (whether at the contract or compiler level), those funds are yours. Furthermore, if you write and publish a post-mortem article explaining in detail how you performed the exploit and how to replicate it, including the code or method used, you'll earn a prize of 0.5 ETH.

Currently, I don’t have a development incentive or bug bounty program at the compiler level, but I have open PRs and issues on github, and I will be reviewing all contributions.

Everything you need to get started

Key links:

• Contract address deployed in Scroll Mainnet: 0x4Eb6FFa53Ff43EaCdCAcb8813686F19AC1a97bca (Might change each Solidity version)

• Emojity Official documentation

• Remojix, the web compiler

• Compiler github repo (pull requests and issues welcome!)

Apendix A: Emojity Contract

• 🍇 is a state variable. A hashmap that stores each user’s stake balance.

• 🍇🔼 is a function that allows any caller (or sender) 👤 stake ETH by sending it as value 💰.

• 🍇🔽 es a function that returns the caller’s 👤 stake

• 🍇❓ is a view function. Returns the stake of the address sent as parameter 🍓

0️⃣🤗0️⃣

🗺️🍇

🍇🔼📢↩️🔢
🏁
  🍇👤📥🍇👤➕💰
  ↩️1️⃣
🔚

🍇🔽📢↩️🔢
🏁
  🔢🍓
  🍓📥🍇👤
  🍇👤📥0️⃣
  📡👤📍0️⃣💸🍓⛽0️⃣
  ↩️1️⃣
🔚

🍇❓👀#️⃣🍓↩️🔢
🏁
  ↩️🍇🍓
🔚

Apendix B: Equivalent contract in Solidity

Even though the following contract is not equivalent at the bytecode level, it follows the same logic as the contract in the bug bounty. You can use it as a guide to understand the logic.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract StakingContract {
    mapping(address account => uint balance) stakeBalance;

    function stake() public payable returns(bool success) {
        stakeBalance[msg.sender] += msg.value;
        return true;
    }

    function unstake() public returns(bool success) {
        uint senderStake = stakeBalance[msg.sender];
        stakeBalance[msg.sender] = 0;
        (bool sent, bytes memory data) = msg.sender.call{value: senderStake}("");
        data;
        return sent;
    }

    function getStake(address account) public view returns(uint balance) {
        return stakeBalance[account];
    }
}

Apendix C: Contract’s compiled contract

Apendix D: JSON ABI

[   {      "inputs":[               ],
      "name":"grapesUpwardsButton",
      "outputs":[
         {
            "internalType":"uint256",
            "name":"",
            "type":"uint256"
         }
      ],
      "stateMutability":"nonpayable",
      "type":"function"
   },
   {
      "inputs":[
         
      ],
      "name":"grapesDownwardsButton",
      "outputs":[
         {
            "internalType":"uint256",
            "name":"",
            "type":"uint256"
         }
      ],
      "stateMutability":"nonpayable",
      "type":"function"
   },
   {
      "inputs":[
         {
            "name":"strawberry",
            "type":"address"
         }
      ],
      "name":"grapesQuestionMark",
      "outputs":[
         {
            "internalType":"uint256",
            "name":"",
            "type":"uint256"
         }
      ],
      "stateMutability":"view",
      "type":"function"
   }
]

Apendix E: Solidity interface

You can use IEmojiContract to interact from Remix, Foundry, Hardhat or from another contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IEmojiContract {
    function grapesUpwardsButton() external returns (uint256);
    function grapesDownwardsButton() external returns (uint256);
    function grapesQuestionMark(address strawberry) external view returns (uint256);
}

Now lets hack!

¿Qué es un lenguaje Emoji?

Emojity es un lenguaje de programación para escribir smart contracts en Ethereum. Puedes pensar en Emojity como una alternativa a Solidity y Vyper, con la diferencia que escribes toda la lógica usando únicamente emojis.

¿Porqué usar Emojity? Emojity no solo es una manera más creativa y divertida de escribir smart contracts, sino que también tiene como misión ayudar a diversificar a nivel de lenguaje para que Ethereum sea más resiliente.

¿Cómo ganar 1 ETH?

El contrato en cuestión es un staking simple, donde yo stakíe 0.5 ETH y solo yo debería ser capáz de sacarlo. Ahora bién, si por medio de un error (ya sea a nivel de contrato o de compilador) logras romper el contrato y obtener los fondos, esos fondos son tuyos. Y además, si escribes y publicas un artículo post mortem explicando a detalle y de manera replicable cómo realizaste el exploit, que incluya el código o método utilizado, te ganarás un premio de 0.5 ETH.

Actualmente no cuento con un programa de incentivos por desarrollo o de bug bounties general a nivel compilador pero tengo los PR e issues abiertos en github y estaré revisando las contribuciones.

Todo lo que ocupas para empezar

Links clave:

• Address del contrato lanzado en Scroll Mainnet: 0x4Eb6FFa53Ff43EaCdCAcb8813686F19AC1a97bca(Sujeto a cambio cada versión nueva de Emojity)

• Documentación oficial de Emojity

• Remojix, el compilador web

• Repositorio en Github del compilador (¡pull requests e issues bienvenidos!)

Apéndice A: Contrato en Emojity

• 🍇 es una variable de estado. Un hashmap que almacena el staking de cada usuario.

• 🍇🔼 es una función que permite a cualquier caller (o sender) 👤 stakear ETH enviándolo como value 💰.

• 🍇🔽 es una función que devuelve el staking que el caller 👤

• 🍇❓ es una función tipo view. Devuelve el staking del address enviado como párametro 🍓

0️⃣🤗0️⃣

🗺️🍇

🍇🔼📢↩️🔢
🏁
  🍇👤📥🍇👤➕💰
  ↩️1️⃣
🔚

🍇🔽📢↩️🔢
🏁
  🔢🍓
  🍓📥🍇👤
  🍇👤📥0️⃣
  📡👤📍0️⃣💸🍓⛽0️⃣
  ↩️1️⃣
🔚

🍇❓👀#️⃣🍓↩️🔢
🏁
  ↩️🍇🍓
🔚

Apéndice B: Contrato equivalente en Solidity

A pesar que el siguiente contrato no es equivalente a nivel de bytecode, sigue la misma lógica que el contrato en del bug bounty. Puedes usarlo para guiarte y entender la lógica.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract StakingContract {
    mapping(address account => uint balance) stakeBalance;

    function stake() public payable returns(bool success) {
        stakeBalance[msg.sender] += msg.value;
        return true;
    }

    function unstake() public returns(bool success) {
        uint senderStake = stakeBalance[msg.sender];
        stakeBalance[msg.sender] = 0;
        (bool sent, bytes memory data) = msg.sender.call{value: senderStake}("");
        data;
        return sent;
    }

    function getStake(address account) public view returns(uint balance) {
        return stakeBalance[account];
    }
}

Apéndice C: Contrato compilado en Bytecode

Apéndice D: JSON ABI

[   {      "inputs":[               ],
      "name":"grapesUpwardsButton",
      "outputs":[
         {
            "internalType":"uint256",
            "name":"",
            "type":"uint256"
         }
      ],
      "stateMutability":"nonpayable",
      "type":"function"
   },
   {
      "inputs":[
         
      ],
      "name":"grapesDownwardsButton",
      "outputs":[
         {
            "internalType":"uint256",
            "name":"",
            "type":"uint256"
         }
      ],
      "stateMutability":"nonpayable",
      "type":"function"
   },
   {
      "inputs":[
         {
            "name":"strawberry",
            "type":"address"
         }
      ],
      "name":"grapesQuestionMark",
      "outputs":[
         {
            "internalType":"uint256",
            "name":"",
            "type":"uint256"
         }
      ],
      "stateMutability":"view",
      "type":"function"
   }
]

Apéndice E: Interfaz en Solidity

Puedes usar IEmojiContract para interactuar desde Remix, Foundry, Hardhat u otro contrato.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IEmojiContract {
    function grapesUpwardsButton() external returns (uint256);
    function grapesDownwardsButton() external returns (uint256);
    function grapesQuestionMark(address strawberry) external view returns (uint256);
}

¡Ánimo, y a hackear!

Esta competencia se lleva a cabo por parte de Filosofía Código, creador de contenido para desarrolladores en web a través de videos en youtube y artículos. Donde se ponen a disposición 1500$ en stablecoins repartidos en bounties específicos para desarrolladores que quieran compartir sus conocimientos con el resto de la comunidad web3. Esto es posible gracias a la confianza que se ha prestado en Filosofía Código a través de las rondas de financiamiento cuadrático de ETH Latam y Ethereum Honduras.

¿Hacia quién va dirigida esta iniciativa?

Desarrolladores con conocimientos previos en web3. Con deseos de aprender y compartir sobre tecnologías con mucho potencial en etapas iniciales. Específicamente en temas de data availability, zero knowledge, inteligencia artificial, criptografía aplicada y stacks de L2s.

Mecánicas de la competencia

1. Elige un tema marcado como “🙏 Ayuda bienvenida” en mi Pipeline de Github. Dentro de cada tarjeta se encuentran los detalles sobre lo que se espera de cada artículo.

2. (Opcional) Avisa el tema en el que estás trabajando en el discord de Filosofia Código en el canal de #🎯reto-web3 para recibir soporte, ayuda, feedback de manera abierta.

3. Entrega el artículo antes del 7 de mayo en mirror.xyz a través de este form. Los ganadores se anunciarán por mi twitter (@FilosofiaCodigo) el 14 de mayo.

4. Una vez concluida la competencia se repartirán los bounties y usaré los mejores artículos para realizar videos en el canal de Youtube. Si el escritor desea participar en el video ¡también será bienvenido! También me reservo el derecho a no otorgar un premio si no hubo un artículo que no siguió las reglas o que considere que no cumpla con un estándar de calidad mínima.

5. El artículo debe estar en Español, estilo tutorial y siguiendo el formato que explico a continuación.

Formato del artículo

El artículo deberá seguir el siguiente formato:

Uno o dos párrafos que den contexto de la tecnología
  * Qué es
  * Porqué es importante
  * Quizás un poco de historia, quiénes la usan, o números que le den validez
  * Link a repo completo en github en caso que exista

# Establece el entorno de desarrollo

Todo lo que se ocupa instalar para llevar a cabo el tutorial

# 1. Desarrollo del tutorial

...

# 2. Paso a paso

...

# 3. Punto por punto

...

# ¿Qué sigue?

Una área para concluir y motivar a al lector a seguir experimentando y aprendiendo. Puedes agregar cualquiera de los puntos a continuación.

* Links a documentación oficial
* Un ejemplo más avanzado
* Tu opinión personal sobre la tecnología
* El futuro que ves sobre la tecnología

Puedes observar este artículo como referencia. Y siéntete libre de experimentar y cambiar el formato si te hace sentido.

Repasos y conocimientos previos

Las temáticas del pipeline contienen Zero Knowledge, OP Stack y Data Aavailability. Te recomiendo reforzar tus conocimientos con mi lista de recursos recomendados, o con contenido en el que yo he participado a continuación.

Workshops sobre el OP Stack

Workshops sobre ZK

Blogpost sobre Eigen Layer DA

https://dev.to/turupawn/eigenda-empieza-a-desarrollar-en-blobs-hoy-gdl

¿Eres principiante en Web3?

Inicia con este bootcamp en español.

https://chain.link/es/bootcamp

O con este video que resume Solidity.

¡Ánimo y a hackear!

El arte en la era industrial

Antes de adentrarnos en web3 y Ethereum como plataformas para el arte, me gustaría estudiar el arte en la era industrial. Luego, compararemos estas experiencias con las nuevas oportunidades que ofrece web3.

Examinemos esfuerzos concretos que democratizaron el arte gracias a los avances de la época industrial, destacando ejemplos en la arquitectura, el diseño de interiores y el mobiliario.

En arquitectura

El Art Decó en la arquitectura logró combinar las cualidades expresionistas del Art Nouveau con los avances tecnológicos de la industrialización. Este estilo ha dado la oportunidad a numerosas personas de habitar y trabajar en edificios que expresan el optimismo y progreso de la época moderna. Los arquitectos del Art Decó se esfuerzan por crear fachadas e interiores agradables y llenos de significado, todo ello ahora es posible con un menor presupuesto gracias a las innovaciones de las máquinas de la época industrial.

En diseño de interiores

Admiro mucho a Charlotte Perriand, una destacada diseñadora de interiores cuyo enfoque era hacer que una vida hogareña digna fuera accesible para todos y optimizar los espacios reducidos. Su creatividad se reflejaba en diseños de hogares pequeños que permitían a los niños correr y jugar cómodamente dentro de sus casas. Además, sus diseños facilitaban la conexión entre aquellos que estaban cocinando o realizando sus quehaceres con sus familias o huéspedes, fomentando un ambiente acogedor y funcional.

En mobiliario

Herman Miller es un claro ejemplo del impacto de la revolución industrial en el mobiliario. Desde su fundación en los años 20, se ha destacado por ofrecer muebles y sillas ergonómicas con diseños expresivos, siempre dentro del ámbito de lo producible en masa. Entre sus creaciones, destaca la icónica silla Aeron, que aún hoy es exhibida en numerosos museos y exposiciones de arte moderno. Herman Miller es una empresa que aún continúa funcionando y es un ejemplo de cómo la combinación de funcionalidad y estética pudo llegar a más personas con la llegada de la producción en masa.

Las cualidades nuevas de los NFTs

Tanto la época industrial como web3 comparten la similitud de introducir una nueva tecnología capaz de democratizar el arte. ¿Qué nuevas características brinda Ethereum al arte?

Mayor Accesibilidad

El arte como medio de expresión ya no está limitado a un espacio físico, ahora se encuentra ampliamente disponible en internet. A través de NFTs de arte digital, música, blogs, POAPs, etc., podemos expresar nuestra individualidad de manera abierta y accesible.

Cuidado con el medio ambiente

Durante la era industrial, se produjo una acelerada destrucción del medio ambiente, y las consecuencias seguirán afectándonos por mucho tiempo. Ethereum ha tomado en cuenta esto y ha implementado cambios en su protocolo para reducir el consumo energético a través de la transición a PoS (prueba de participación). A diferencia de PoW (prueba de trabajo), PoS no implica una competencia, solo consume la energía necesaria para garantizar la seguridad de la red. Esto significa que ahora podemos escalar nuestro arte y llegar a más personas sin preocuparnos por causar daños adicionales al medio ambiente.

Utilidad + Arte

Así como la industrialización llevó el arte a la vida cotidiana a través de la arquitectura, los interiores y el mobiliario, los NFTs también traen utilidades en el ámbito digital. Estas utilidades pueden extenderse a nivel de criptomonedas (DeFi), gobernanza, propiedad (ENS, Decentraland) y más. Un ejemplo es el uso de NFTs como representación de las pools de liquidez concentradas en Uniswap V3 utilizando el estándar ERC721.

En el futuro, podríamos ver la aplicación de NFTs en otras utilidades, como la identidad (cédula, pasaporte), la propiedad privada (casas, carros), boletos de transporte (bus, avión) o conciertos, entre otros.

La idea de añadir componentes artísticos a estos NFTs de utilidad surge como una forma creativa de enriquecer y personalizar estas utilidades digitales. Agregar elementos artísticos a estos NFTs puede dotarlos de un valor estético y emocional adicional, haciéndolos más atractivos y memorables para sus propietarios y usuarios. Además, esta fusión entre utilidad y arte podría abrir nuevas posibilidades para la expresión creativa y difusión de ideas.

¿Cuál es el futuro del arte en Web3?

La época industrial y el surgimiento de web3 comparten similitudes notables al introducir nuevas tecnologías que hacen posible cambios sociales significativos. Podemos utilizar esta relación como un caso de estudio para anticiparnos a las oportunidades que web3 nos puede ofrecer.

Es esencial tener en cuenta que Ethereum es una tecnología que da lugar a muchos experimentos novedosos. Por lo tanto, debemos permanecer vigilantes ante los posibles fracasos y buscar constantemente formas de corregir y mejorar. Un ejemplo moderno es la invención del cubículo, también creado por Herman Miller, que originalmente buscaba proporcionar a los empleados mayor libertad en su trabajo, pero con el tiempo, tuvo un efecto contrario.

Los NFTs como tecnología han llegado para quedarse. Han tenido una amplia adopción y han servido como plataforma para introducir el arte en el blockchain. A pesar de eso, considero que aún estamos en etapas tempranas y nos queda mucho por descubrir.

El arte es un pilar fundamental en cualquier cambio cultural, y el blockchain no es una excepción. Se encuentra en un nivel de importancia equiparable a la tecnología, filosofía y economía, ya que es la herramienta que nos permite expresarnos y explorar todo lo nuevo que está por venir. A través del arte, podemos comunicar lo que la ciencia no puede capturar, lo que lo convierte en una fuerza vital en el ecosistema de Ethereum.

Les invito a mirar hacia el pasado, a la época industrial y más atrás, para tener una mejor perspectiva del futuro del arte en el blockchain. Potenciar sus oportunidades y no cometer los mismos errores.

En este artículo, me gustaría compartir por qué es importante arrojar luz sobre lo que realmente representan las shitcoins, ya que esto nos permitirá fortalecer la cultura de Ethereum. Espero poder brindarles una perspectiva equilibrada, ya que he tenido experiencias muy diversas en el mundo web3. He recibido apoyo de organizaciones reconocidas, como la Ethereum Foundation y los RetroPFG de Optimism. Actualmente, también trabajo en Scroll, otro proyecto destacado. Sin embargo, también he participado desarrollando y contribuyendo en los ecosistemas más shit y degenerados que se puedan imaginar.

¿Qué hace “shit” a una Shitcoin?

Muchos dirán que las shitcoins atraen a los degens nihilistas, adictos a la dopamina y a las apuestas. Y honestamente, estoy de acuerdo con eso. Al entrar en cualquier grupo de telegram de algún token degenerado podemos observar el comportamiento usual de muchos de los holders.

Además, es común escuchar críticas sobre la falta de sostenibilidad de mecanismos como el Liquidity Farming. Se argumenta que estas economías, o más bien "ponzynomics", solo benefician a los primeros compradores y promueven una mentalidad individualista e hiper-capitalista. Personalmente, también estoy de acuerdo con estas preocupaciones.

También es válido señalar que las "shitcoins" a menudo desvían la atención y la liquidez de los avances significativos en áreas importantes, como ZK, Public Goods, Sharding, entre otros.

Considero que es importante seguir resaltando estos aspectos negativos de las shitcoins. Esto nos permitirá proteger a los nuevos usuarios de caer en estafas y nos brinda la oportunidad de participar en estos proyectos con pleno conocimiento de los riesgos y las implicaciones negativas que conllevan.

Entonces, ¿es malo el Liquidity Farming?

No en su totalidad.

A pesar de los riesgos conocidos, atraen a muchos usuarios. Esto puede ser debido a que son protocolos altamente interactivos, brindan un sentido de comunidad y permiten a los usuarios controlar sus activos de manera transparente a través del código en los contratos inteligentes.

Además, las shitcoins representan una forma fresca de expresar la incomodidad con los sistemas económicos actuales. Son una crítica y una sátira. Al comprar y vender estas monedas, estamos expresando nuestro descontento con el sistema monetario tradicional y mostrando nuestro interés en experimentar con modelos alternativos.

El aspecto positivo de las shitcoins que encuentro más interesante es su contribución a la innovación. Esto se debe a que el ambiente libre de expectativas y de rigidez que proveen las shitcoins es ideal para la innovación. Es difícil tomar en serio proyectos como "Floki Inu", "HarryPotterObamaSonicInu (ticker: BITCOIN)" o colecciones de NFT como “Just Bricks”, esto brinda la oportunidad a los creadores de experimentar con las ideas más locas. Esto es importante porque la innovación que surge en estos entornos puede servir como base para proyectos que realmente ofrecen utilidad a largo plazo. Un ejemplo de esto es Lido, un proyecto revolucionario que actualmente brinda una gran utilidad y que utiliza tecnologías de rebase que se probaron en proyectos extremadamente degenerados como Safemoon.

En conclusión

Es importante ver las shitcoins desde diferentes ángulos y reconocer que no son inherentemente buenas ni malas, sino una combinación de ambas. Esta perspectiva nos permite encontrar un equilibrio en el futuro del ecosistema y en los proyectos en los que decidamos participar.

Es importante aplicar esta mentalidad no solo a las shitcoins, sino también a otros temas complejos dentro de web3, como el MEV (extracción de valor en las transacciones), PoS (prueba de participación) vs PoW (prueba de trabajo), L2 (capa 2) vs Appchains (cadenas de aplicaciones), entre otros.

Al abordar estos temas con una mirada equilibrada, podemos comprender mejor las diversas perspectivas y considerar los beneficios y los desafíos que cada enfoque conlleva. Esto nos permite tomar decisiones más informadas y trabajar hacia soluciones que promuevan un ecosistema web3 más sólido y sostenible en el futuro.

1. Autenticidad

La regla número uno para crear contenido que inspire a los demás es sentirnos nosotros mismos inspirados por el tema. Ya sea a través de videos, textos u otros formatos, el receptor se verá influenciado por nuestro propio entusiasmo. No podemos evitar esto de manera sostenible a largo plazo.

Este aspecto no debe tomarse a la ligera, porque implica encontrar un equilibrio entre nuestra pasión personal, la búsqueda de una audiencia y un modelo económico sustentable en caso que se busque hacerlo de manera profesional. En América Latina, este desafío es más notable debido a las limitadas oportunidades económicas. En la mayoría de las ocasiones, debemos aceptar que tendremos que trabajar más en condiciones menos favorables que en los países del primer mundo. Lo importante es indagar profundo en cuáles son nuestros intereses y entender porqué conectamos más con ellos. Una vez hecho esto, buscar cuales combinan mejor con posibles audiencias e intentarlo varias veces y no desanimarse en el proceso.

2. Consideraciones culturales

Detrás de cada proyecto y comunidad existe una cultura única. Si has enviado pull requests en Github, habrás notado que cada repositorio tiene sus propias reglas, ya sean implícitas o explícitas. Estas reglas abarcan diferentes aspectos, como protocolos de revisión, automatización, expectativas de orden, estructura y optimización del código. Lo mismo ocurre al escribir contenido, donde el tema y la audiencia afectan el formato, densidad y lenguaje utilizados. Por ejemplo, la presentación de un nuevo protocolo de criptografía podría requerir un lenguaje académico y adaptarse mejor a un formato de blog. Por otro lado, un taller introductorio de Solidity podría ser más adecuado para un livestream, permitiendo a los participantes ver el proceso de manera gráfica y realizar preguntas en el momento si surgen problemas.

Considero que es importante mostrar un nivel de respeto hacia las culturas preexistentes. Si viajo al este de Asia, debería utilizar el saludo asiático, al igual que esperaría que los asiáticos me saluden dándome la mano o con un abrazo al visitar América Latina. Sin embargo, esto no significa que el formato sea totalmente rígido. Está muy bien plasmar nuestra personalidad y experimentar con nuevas formas de presentar contenido, siempre y cuando valoremos la identidad de nuestra audiencia.

3. Guías “Parcialmente Completas”

El tipo de contenido que se me dá más es la creación de guías estilo tutorial. En este tipo de contenido prefiero presentar casos de uso que sean lo suficientemente grandes para que la audiencia se sienta motivada a dedicarle tiempo en aprender. Por ejemplo, "Cómo lanzar un Token ERC20 paso a paso" o "Replicando Tornado Cash desde cero". Este tipo de contenido conecta bien con aquellos que han utilizado previamente este tipo de proyectos o que tienen conocimientos sobre su funcionamiento. Es importante ofrecerles una forma rápida y sencilla de reproducir y ejecutar el código, para que puedan tener una experiencia inicial sin demasiados inconvenientes. A menudo, esto implica eliminar la mayoría de las funcionalidades para enfocarse en demostrar la parte más importante de los proyectos.

No solo se debe ofrecer un demo que la audiencia pueda probar, sino que también estimule la imaginación. Esto se puede lograr de dos maneras. Primero, haciendo guías sobre tecnología que se integre con otras tecnologías o con conocimientos previos de la audiencia. El blockchain al ser un protocolo abierto es muy propicio para esto. Segundo, dejando intencionalmente ciertos puntos incompletos o deficientes, para que la audiencia sienta el deseo de completarlos utilizando sus habilidades e imaginación. Por ejemplo, puede tratarse de una dApp con un frontend con una experiencia de usuario deficiente, o tal vez un smart contract que no esté optimizado. Es importante hacerlo de manera evidente, para que los nuevos desarrolladores no consideren todo el contenido como un estándar de calidad.

Gracias por leer este post. Puedes encontrar más sobre mi trabajo en mi linktree.