Skip to main content
Xcapit
Blog
·10 min de lectura·Fernando BoieroFernando Boiero·CTO & Co-Fundador

Construyendo sobre Soroban: Desarrollo en Rust para Stellar

blockchainstellarrust

Stellar ha sido una de las redes más confiables en blockchain durante casi una década. Procesa pagos transfronterizos a escala, liquida transacciones en menos de cinco segundos y cobra fracciones de centavo en fees. Instituciones importantes -- desde MoneyGram hasta Franklin Templeton -- la usan en producción. Pero hasta hace poco, Stellar tenía una limitación notable: sin smart contracts de propósito general. Soroban cambia eso. Lanzado en la mainnet de Stellar a principios de 2024, Soroban es una plataforma de smart contracts construida desde cero con Rust, WebAssembly y las lecciones duras aprendidas de observar la evolución del ecosistema de Ethereum. Nuestro equipo pasó recientemente varias semanas construyendo con ella, y esto es lo que encontramos.

Entorno de desarrollo y arquitectura de Soroban
Arquitectura de Soroban: smart contracts basados en Rust sobre la red Stellar

Este post cubre nuestra experiencia hands-on con Soroban: la arquitectura, el tooling, las diferencias con el desarrollo en Solidity y nuestra evaluación honesta de dónde la plataforma sobresale y dónde todavía tiene brechas. Si estás evaluando Soroban para un proyecto o querés entender cómo se ve la apuesta de smart contracts de Stellar desde la perspectiva de un desarrollador, esta es la guía que nos hubiera gustado tener cuando empezamos.

Por Qué Stellar Necesitaba Smart Contracts

Stellar fue diseñada como una red de pagos, no como una plataforma de computación de propósito general. Su Stellar Consensus Protocol (SCP) prioriza seguridad y liveness para transacciones financieras, y la red ha procesado miles de millones de dólares en remesas y transferencias de stablecoins desde 2015. Pero el panorama crypto evolucionó. DeFi, activos reales tokenizados, lógica de cumplimiento on-chain e instrumentos financieros programables -- todos requieren computación arbitraria que el modelo de transacciones original de Stellar no podía soportar. Los proyectos que querían protocolos de lending o automated market makers tenían que irse a Ethereum.

En vez de agregar smart contracts a la arquitectura existente como algo tardío, la Stellar Development Foundation construyó una plataforma diseñada a propósito que aprovechó todo lo que la industria había aprendido desde 2015. Soroban es un diseño de pizarra limpia que evita el equipaje histórico del EVM mientras se integra nativamente con la infraestructura de Stellar para pagos, emisión de activos y conectividad fiat.

Arquitectura: WASM, Storage y Resource Metering

Los contratos de Soroban se escriben en Rust y se compilan a WebAssembly (WASM). WASM es un formato de ejecución portable y sandboxed que provee velocidad cercana a la nativa, comportamiento determinístico y fuerte aislamiento. Al elegir WASM sobre una VM custom, Soroban hereda una toolchain madura y optimizaciones de compilador extensivas ya soportadas por los principales proveedores cloud.

El modelo de ejecución es deliberadamente restringido. Cada invocación tiene límites de recursos explícitos -- instrucciones de CPU, memoria, lecturas y escrituras de ledger, tamaño de transacción -- todos medidos y precificados antes de la ejecución. Soroban usa simulación preflight: simulás una transacción contra el estado actual del ledger para determinar el consumo exacto de recursos. La transacción o cabe en el envelope declarado o falla antes de la ejecución. Sin sorpresas, sin errores de out-of-gas a mitad de ejecución, sin fees desperdiciados.

El storage diverge de los patrones establecidos. En vez del almacén key-value único de Ethereum, Soroban provee tres tipos. El instance storage está atado a la instancia del contrato -- ideal para configuración que persiste con el contrato. El persistent storage sobrevive independientemente y puede extenderse pagando renta -- adecuado para balances de usuario y datos de larga vida. El temporary storage se auto-elimina después de un TTL configurable -- útil para datos de sesión y caches. Este modelo fuerza a los desarrolladores a pensar en el ciclo de vida de los datos por adelantado, previniendo el crecimiento de estado sin límites que afecta a Ethereum.

La Ventaja de Rust

Rust trae seguridad de memoria sin garbage collector, un sistema de tipos fuerte que detecta bugs en compile time, y performance adecuado para un entorno de ejecución blockchain restringido. En Solidity, integer overflows, storage no inicializado y vulnerabilidades de reentrancy han causado miles de millones en pérdidas. Rust elimina muchas de estas categorías por diseño -- su modelo de ownership previene punteros colgantes, su sistema de tipos previene errores de acceso a memoria, y su compilador estricto significa que si el código compila, clases enteras de errores runtime no pueden ocurrir.

La ausencia de garbage collection es igualmente importante. En blockchain, cada operación debe ser determinística y el consumo de recursos precisamente medido. La garbage collection introduce impredecibilidad. La gestión de memoria en compile time de Rust significa que el consumo de recursos es consistente, alineándose perfectamente con el modelo de metering de Soroban. Dicho esto, Rust tiene una curva de aprendizaje empinada. Los desarrolladores que vienen de Solidity o JavaScript deben internalizar ownership, borrowing, lifetimes y polimorfismo basado en traits. El SDK de Soroban abstrae patrones comunes, pero los contratos no triviales requieren entendimiento profundo del lenguaje.

Experiencia de Desarrollo: SDK, CLI y Sandbox

El SDK de Soroban provee macros procedurales que generan boilerplate para entry points de contratos, conversiones de tipos y acceso a storage. Un contrato empieza con #[contract] en un struct y #[contractimpl] en su bloque de implementación. El SDK maneja serialización y acceso al entorno -- suficientemente delgado para entender la mecánica subyacente, suficientemente grueso para evitar escribir interacciones raw de WASM.

El CLI de Stellar gestiona el ciclo de vida completo de deployment: scaffolding de proyecto, compilación WASM, optimización de binarios, deployment en testnet y mainnet, invocación de funciones, gestión de identidades y firma de transacciones. El workflow es stellar contract init, cargo build con el target WASM, stellar contract deploy y stellar contract invoke. Directo y bien documentado.

El sandbox local es donde Soroban realmente se diferencia. El framework de testing te permite escribir tests en Rust que instancian contratos, llaman funciones, hacen assert sobre cambios de estado y verifican errores -- todo corriendo nativamente en milisegundos. Sin nodo blockchain, sin confirmaciones de bloque, sin test tokens. Escribís un test, ejecutás cargo test y obtenés resultados al instante. Después de años con Hardhat y Foundry, la diferencia de velocidad es inmediatamente notable.

Diferencias Clave con el Desarrollo en Solidity

Sin Reentrancy por Diseño

El reentrancy -- la clase de vulnerabilidad más infame de Solidity -- causó el hack del DAO y ha sido explotado docenas de veces desde entonces. Soroban lo elimina completamente. Un contrato no puede ser llamado nuevamente mientras una invocación previa está en ejecución, aplicado en runtime. Una categoría entera de vulnerabilidades críticas no existe.

Storage y Autorización Explícitos

En Solidity, el storage es implícito y persiste para siempre por defecto. El modelo de tres niveles de Soroban fuerza decisiones explícitas sobre cada pieza de dato -- cuánto tiempo vive, quién paga por ello y qué pasa cuando su TTL expira. Para autorización, Solidity depende de msg.sender, lo que crea patrones frágiles en llamadas cross-contract. Soroban usa require_auth, chequeando que una dirección específica autorizó una invocación específica contra el árbol de autorización de la transacción. Ambos cambios hacen los contratos más seguros por defecto.

Construyendo un Contrato de Token: Conceptos Clave

El ecosistema Stellar provee una interfaz de token estándar (SEP-41) análoga a ERC-20. Un token en Soroban almacena balances en persistent storage indexado por dirección. La función transfer lee el balance del sender, verifica suficiencia, lo decrementa e incrementa el del destinatario. Antes de cualquier cambio de estado, require_auth verifica la autorización del sender. Los allowances usan temporary storage con un TTL, así que las aprobaciones expiradas se limpian automáticamente -- a diferencia de ERC-20 donde persisten para siempre.

Las piezas componen naturalmente. La macro #[contracttype] genera serialización para tipos custom. Los tiers de storage se acceden vía env.storage().persistent() y env.storage().temporary(). Los eventos se emiten a través de env.events().publish(). El manejo de errores usa el tipo Result de Rust con enums custom que mapean a códigos de error on-chain. Tenés todo el poder de Rust -- pattern matching, iterators, generics -- no un subconjunto definido por un lenguaje de dominio específico.

Testing y Debugging

El soroban-sdk incluye un entorno de test que simula el runtime completo del contrato -- storage, autorización, eventos y llamadas cross-contract. Escribís tests estándar de Rust con #[test], creás un entorno mock con Env::default() y llamás funciones del contrato directamente. Las features avanzadas incluyen env.mock_all_auths() para bypasear autorización en tests, manipulación de secuencia de ledger para lógica dependiente del tiempo, y testing de interacción multi-contrato -- todo con soporte completo de debugging en IDE incluyendo breakpoints.

La simulación de transacciones a través del CLI de Stellar agrega confianza para producción. Antes de enviar a la red, simulás contra el estado actual del ledger y obtenés consumo exacto de recursos, cambios de estado y valores de retorno. Si la simulación pasa, la transacción on-chain tiene éxito con uso determinístico de recursos. Encontramos esto invaluable durante el deployment, donde las transacciones fallidas en mainnet cuestan dinero real.

Integración con el Ecosistema Stellar

Los contratos de Soroban interactúan con los activos nativos de Stellar (incluyendo USDC), el DEX de la red y el ecosistema de anchors, wallets y on-ramps fiat. La API de Horizon provee acceso REST para consultar estado, enviar transacciones y transmitir eventos. Los SDKs de Stellar en JavaScript, Python, Go y Java permiten que frontends y backends interactúen con contratos Soroban sin dependencias de Rust. Los anchors -- proveedores de on/off-ramp fiat de Stellar operando en docenas de países -- proveen conectividad fiat directa que la mayoría de las plataformas de smart contracts no tienen. Un protocolo DeFi en Soroban puede ofrecer conversión real de fiat a stablecoin, reduciendo la fricción que previene la adopción masiva.

Performance y Costo

Las transacciones finalizan en cinco a siete segundos con fees típicamente debajo de un centavo, haciendo viables las microtransacciones. El resource metering es más granular que el gas del EVM -- pagás por separado por CPU, memoria, I/O de ledger, tamaño de transacción y renta de estado. En nuestros benchmarks, un contrato de token estándar en Soroban costó aproximadamente 90% menos que Ethereum L1 y fue comparable a Arbitrum u Optimism -- pero en una red L1 con su propio consenso, no un rollup dependiente de Ethereum para seguridad.

Dónde Soroban Brilla

  • Activos tokenizados e instrumentos financieros: Soroban hereda la arquitectura regulatory-friendly de Stellar. Emitir y gestionar securities tokenizados, bonos o activos reales es un fit natural.
  • Aplicaciones de pagos: los anchors de Stellar, soporte de stablecoins (USDC, EURC) y finalidad rápida lo hacen ideal para escrow, pagos condicionales, splitting de pagos y desembolsos programables.
  • Productos financieros transfronterizos: Stellar ya procesa remesas internacionales a escala. Soroban agrega lógica programable -- conversión FX automatizada, chequeos de cumplimiento, aprobación multi-parte.
  • Protocolos de lending y crédito: el modelo de storage explícito con renta de estado se alinea bien con protocolos donde las posiciones tienen vidas naturales y los datos dormidos no deberían persistir indefinidamente.
  • Aplicaciones financieras empresariales: organizaciones que necesitan lógica on-chain con conectividad fiat, tooling de cumplimiento e infraestructura de grado institucional encontrarán el ecosistema de Stellar más completo que la mayoría de las alternativas.

Nuestra Evaluación: Fortalezas y Debilidades

Soroban no intenta competir con Ethereum como una computadora mundial de propósito general. Está construido a propósito para aplicaciones financieras, y evaluarlo requiere entender ese alcance.

Fortalezas

  • Rust y WASM proveen un entorno de ejecución fundamentalmente más seguro. Categorías enteras de vulnerabilidad se eliminan por el lenguaje mismo.
  • La experiencia de desarrollo es fuerte -- SDK, CLI, testing local y documentación están bien diseñados. El ciclo de desarrollo es rápido.
  • El modelo de storage de tres niveles resuelve el crecimiento de estado sin límites, un problema que afecta a Ethereum y otras chains.
  • La integración con la infraestructura de pagos de Stellar, on-ramps fiat y relaciones institucionales provee utilidad real que las plataformas crypto-nativas no pueden igualar.
  • El resource metering determinístico y la simulación de transacciones eliminan las conjeturas y fees desperdiciados que son fricción constante en el desarrollo EVM.

Debilidades

  • El ecosistema es joven. Herramientas de auditoría, librerías battle-tested y ejemplos de contratos verificados todavía están madurando comparados con Ethereum.
  • La curva de aprendizaje de Rust es real. Los equipos sin experiencia van a necesitar inversión significativa, y contratar desarrolladores Rust es más difícil que contratar desarrolladores Solidity.
  • La composabilidad DeFi es limitada -- menos protocolos, oráculos y pools de liquidez. Si la composabilidad profunda es crítica, los L2s de Ethereum siguen siendo más fuertes.
  • La comunidad y mindshare de desarrolladores es más pequeño. Tutoriales, respuestas en Stack Overflow y repositorios de ejemplo son menos abundantes.
  • La renta de estado agrega complejidad operacional. Los TTLs deben gestionarse activamente, requiriendo infraestructura de monitoreo a la que los desarrolladores EVM no están acostumbrados.

Cuándo Recomendaríamos Soroban

Recomendaríamos Soroban para proyectos que involucren transacciones financieras, tokenización de activos o infraestructura de pagos -- donde el equipo tenga experiencia en Rust. Si tu producto necesita conectividad fiat, compatibilidad regulatoria y costos bajos más que composabilidad DeFi profunda, Soroban es una elección convincente. No lo recomendaríamos hoy para dApps de propósito general, gaming o aplicaciones dependientes de protocolos DeFi existentes. Para esos, el ecosistema L2 de Ethereum sigue siendo la elección práctica. Esto podría cambiar a medida que Soroban madure, pero a principios de 2025, los efectos de red todavía favorecen a las chains EVM-compatible para casos de uso no financieros.

Soroban Stellar Contract Architecture

En Xcapit, venimos construyendo soluciones blockchain desde 2017 -- desde wallets de auto-custodia hasta integraciones DeFi y auditorías de smart contracts en múltiples chains. Si estás evaluando Soroban para un producto financiero, necesitás ayuda diseñando una estrategia multi-chain que incluya Stellar, o querés un equipo con experiencia hands-on en Rust y smart contracts, estaremos encantados de ayudar. Conocé más sobre nuestros servicios de desarrollo blockchain.

Share
Fernando Boiero

Fernando Boiero

CTO & Co-Fundador

Más de 20 años en la industria tecnológica. Fundador y director de Blockchain Lab, profesor universitario y PMP certificado. Experto y líder de pensamiento en ciberseguridad, blockchain e inteligencia artificial.

Construyamos algo grande juntos

IA, blockchain y software a medida — pensado para tu negocio.

Contactanos

¿Construyendo sobre blockchain?

Tokenización, smart contracts, DeFi — lo hemos implementado todo.

Artículos Relacionados