← Back

Desarrollando con Scroll (Ethereum México)

Reflexiones desde adentro de un hackathon: qué funciona, qué falla, y cómo guié a equipos para desplegar su primer smart contract en Scroll.

6 min read

Ethereum México 2025 fue la primera vez que estuve en los tres roles al mismo tiempo: mentor, jurado y speaker. Eso te da una perspectiva rara; ves los proyectos desde que son una idea confusa hasta que alguien los está presentando frente a jueces con diapositivas hechas a las 3am.

Impartí un workshop llamado "Desarrollando en Scroll", y el objetivo era simple: que cualquier asistente, sin importar su nivel, pudiera desplegar un smart contract real en una red de segunda capa y entender por qué importa la red que eliges.

Por qué Scroll y no "cualquier L2"

Scroll me pidió que apoyara en este hackathon técnicamente y me pareció una buena elección pedagógica justamente porque tiene propiedades concretas que se pueden explicar sin entrar en criptografía avanzada:

  • Es compatible con EVM, así que el código que ya sabes escribir funciona.
  • Usa zkEVM para generar pruebas de validez, lo que le da una seguridad diferente a otras L2.
  • Tiene un faucet accesible y una red de pruebas funcional (clave para un hackathon donde nadie quiere gastar ETH real aprendiendo).

No necesitas entender completamente cómo funcionan las pruebas zk para construir en Scroll. Lo que sí necesitas es saber que la red que eliges afecta el costo, la velocidad y la seguridad de tu app (y eso sí lo puedes tomar en cuenta desde el diseño).

El workshop: de cero a contrato desplegado

El stack fue deliberadamente minimalista: Remix IDE, el faucet de Scroll Sepolia, y Rabby Wallet. Sin instalaciones, sin configuración de entorno, sin npm. Eso importa cuando tienes 45 minutos y gente que nunca ha escrito Solidity.

El contrato que desplegamos fue un PriceConsumer usando Chainlink Price Feeds:

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

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract PriceConsumer {
    AggregatorV3Interface internal priceFeed;

    constructor(address _priceFeedAddress) {
        priceFeed = AggregatorV3Interface(_priceFeedAddress);
    }

    function getLatestPrice() public view returns (int) {
        (, int price,,,) = priceFeed.latestRoundData();
        return price;
    }

    function getPriceInUSD() public view returns (uint256) {
        int price = getLatestPrice();
        return uint256(price) / 1e8;
    }

    function getPriceDetails() public view returns (
        int256 price,
        uint8 decimals,
        string memory description
    ) {
        price = getLatestPrice();
        decimals = priceFeed.decimals();
        description = priceFeed.description();
    }
}

¿Por qué este contrato? Porque conecta Web3 con algo tangible: el precio de ETH en tiempo real, consultado on-chain. No es un "Hello World" vacío, pero tampoco es complejo. Es suficiente para que alguien vea el ciclo completo: escribir → compilar → desplegar → interactuar → verificar en el explorador.

El flujo que seguimos:

  1. Abrir Remix IDE en el navegador
  2. Instalar Rabby Wallet y configurar Scroll Sepolia
  3. Pedir ETH de prueba en el faucet oficial de Scroll
  4. Compilar el contrato en Remix
  5. Desplegar pasando la dirección del Price Feed de Chainlink para Sepolia
  6. Llamar getPriceInUSD() y ver el resultado on-chain

Eso es todo. Nada más. Y funcionó.

Lo que vi como mentor

Pasé horas sentado con equipos ayudándolos a destrabar sus proyectos. Algunos patrones que se repiten:

Empiezan por el contrato, no por la idea. El smart contract no es el producto, es una pieza de infraestructura. Si no sabes qué problema resuelves, no importa qué tan elegante sea tu Solidity.

Subestiman el frontend. Varios equipos llegaron al demo day con un contrato impecable y una interfaz que nadie podía usar. En Web3, el usuario interactúa con tu app a través de su wallet (esa UX importa tanto como la lógica on-chain, en mi opinión).

La IA ayuda, pero necesita dirección. El consejo que más repetí: antes de pedirle código a una IA, construye un PRD (Product Requirements Document) aunque sea de una página. Qué resuelve, para quién, qué hace el contrato, qué hace el frontend. Con eso, la IA genera código útil. Sin eso, genera código que compila pero no hace lo que necesitas.

Lo que vi como jurado

Evaluar proyectos desde el otro lado te hace más honesto sobre qué importa realmente. Algunos criterios que usé:

  • ¿El problema es real? No "tokenizamos X" sin contexto —¿quién tiene ese problema hoy?
  • ¿El demo funciona? No importa qué tan buena sea la presentación si el contrato no se puede llamar en vivo.
  • ¿Entienden lo que construyeron? Hay una diferencia enorme entre un equipo que explica sus decisiones técnicas y uno que repite el pitch que la IA les generó.

Los proyectos que más me impresionaron no eran los más ambiciosos (eran los más claros y fáciles de entender). Sabían exactamente qué hacía su contrato, por qué lo desplegaron en esa red, y quién lo iba a usar.

Conclusión

Ethereum México me recordó por qué vale la pena estar en estos espacios. No por las ideas (hay ideas en todos lados) sino por la densidad de personas que están construyendo en serio, aprendiendo en público, y empujando el ecosistema en México.

Si vas a un hackathon de Web3, mi recomendación es simple: elige el stack más simple que resuelva el problema. Remix, un faucet, Rabby, y un contrato que hagas tú. Eso vale más que un repo lleno de dependencias que nadie entiende (y sí puedes explicar el smart contract, mejor).

Desarrollando con Scroll (Ethereum México) · Irwing Duran