Desarrollando en Scroll (Ethereum México)
Participar en Ethereum México (ETH MX) como speaker, mentor y judge me permitió profundizar en una realidad del desarrollo Web3: la infraestructura determina la arquitectura. Impartir el workshop “Desarrollando en Scroll” expuso la brecha entre la teoría de los zk-rollups y la experiencia práctica de construcción, un desafío común al trabajar con ecosistemas como Scroll, Arbitrum y Celo.
El reto central no es la compatibilidad técnica, sino formar criterio de diseño. Scroll, siendo una zkEVM, exige pensar más allá del contrato inteligente y considerar cómo las decisiones de código, tooling y UX impactan en costos, latencia y la experiencia final en un entorno con pruebas de conocimiento cero.
Scroll como capa de ejecución con propiedades únicas
El primer aprendizaje fue dejar de tratar a Scroll como "otra L2". Es una infraestructura con características propias:
- Finalidad asegurada por pruebas zk, no solo por consenso.
- Costos de transacción vinculados al uso de calldata y la complejidad computacional.
- Un modelo de seguridad que traslada parte de la complejidad al diseño del sistema.
Esto obliga a un cambio de mentalidad: no se migra una dApp, se rediseña para un entorno zk.
Smart Contracts: Compatible ≠ Óptimo
Aunque Scroll ejecuta Solidity, el workshop enfatizó que el código debe escribirse con conciencia de la capa subyacente:
- Operaciones de almacenamiento (SSTOREs) son críticas por su impacto en el costo y el tamaño de la prueba zk.
- Los eventos deben usarse de forma estratégica, no como log arbitrario.
- La lógica debe segmentarse, separando núcleo crítico de funciones auxiliares, para optimizar la generación de pruebas.
La lección es clara: en zkEVM, la eficiencia del contrato es una función directa de la experiencia de usuario.
Tooling y UX: La abstracción tiene un costo
Un hallazgo transversal al trabajar con Scroll, Celo y Arbitrum es que el tooling define los límites del builder. En el workshop se cubrió:
- Cómo configurar entornos de desarrollo (Hardhat/Foundry) para reflejar las particularidades de Scroll.
- Estrategias de debugging cuando las transacciones se procesan en una capa con finalidad diferida.
- La importancia de comunicar claramente los estados (enviado, probado, finalizado) al usuario final.
En Web3, el frontend y las herramientas no son una capa separada; son componentes de infraestructura que gestionan confianza y costo.
Conclusión: La arquitectura precede al código
La experiencia en Ethereum México, sumada al trabajo con otros ecosistemas, refuerza un principio: el reto de zk (y de Web3 en general) no es criptográfico, es de diseño.
Las tecnologías como Scroll ofrecen escalabilidad, pero su valor real se captura solo cuando los builders piensan en sistemas completos: desde la optimización del bytecode hasta la claridad de la interfaz de usuario. No se trata de aprender un nuevo SDK, sino de desarrollar un criterio técnico que pregunte constantemente: ¿cómo se comporta esta decisión en esta infraestructura?
Construir en Scroll, o en cualquier stack Web3, significa aceptar que no existe un estándar universal. La solidez de una aplicación nace de comprender en profundidad los trade-offs de la capa base y traducirlos en una arquitectura coherente y eficiente.