Decisiones Técnicas y Aprendizajes de Soroban de Ethereum

Tanto Ethereum como Stellar tienen un token nativo: ETH (éter) para Ethereum y XLM (lumen) para Stellar. Estos tokens nativos se utilizan para pagar las tarifas de transacción y otros servicios (como requisitos de reserva en Stellar o servicios computacionales en Ethereum) en sus respectivas redes. Éter y lumens también pueden usarse de manera similar a otros activos, incluyendo para operar en exchanges, y más.

ETH, sin embargo, no tiene la misma funcionalidad que otros tokens de la red y no se ajusta al estándar de token fungible más aceptado y utilizado de Ethereum, ERC-20. Para usar ETH en un contrato inteligente, primero debes convertirlo a WETH (ETH envuelto) al, lo adivinaste, envolverlo. Envolver un token requiere interactuar con un contrato inteligente WETH, lo que agrega una transacción adicional y una tarifa de gas asociada (las tarifas de transacción de Ethereum promedian, al momento de escribir, $1.273 por transacción).

El XLM de Stellar, por otro lado, interactúa con contratos inteligentes de la misma manera que cualquier otro activo en la red. Una vez que se despliega un Contrato de Activos Stellar (SAC) para cualquier activo Stellar (incluyendo XLM), ese activo es inmediatamente utilizable por todos los contratos inteligentes de Soroban sin pasos adicionales o transacciones. Tratar XLM como cualquier otro activo optimiza su utilidad al mismo tiempo que minimiza las tarifas para los usuarios.

No sé tú, pero a mí me gusta ser notificado cuando las cosas están sucediendo. Si llego a casa del trabajo y mi suegra está sentada en mi sala sin previo aviso, probablemente estaría un poco molesto de que no me haya enviado un mensaje. Quiero decir, amo a mi suegra, pero también me gustaría saber cuándo viene a visitar.

En Ethereum, no se emiten eventos cuando se transfiere el token nativo ETH. Los tokens ERC-20, siendo ellos mismos contratos inteligentes, emiten un evento de transferencia cuando se negocian. Sin embargo, dado que ETH no es un token ERC-20 y no sigue los estándares de tokens, puede aparecer en una billetera o cuenta sin ninguna notificación. Los desarrolladores deben implementar servicios separados para recibir notificaciones de transferencia de ETH, lo que agrega otra capa de complejidad.

Con Soroban, el Contrato de Activos Stellar de XLM emite los mismos eventos que otros contratos de tokens. Los desarrolladores no tienen que hacer un trabajo extra para rastrear las transferencias nativas, una característica que simplifica la experiencia del desarrollador, permite un código más limpio y simple, y optimiza la utilidad de XLM en Soroban.

Los exploits de reentrada pueden ocurrir cuando un contrato inteligente hace una llamada (como un retiro) a un contrato externo y luego actualiza su estado interno (como debitar el valor del retiro de la cuenta). El ataque ocurre cuando el contrato externo hace una llamada recursiva de vuelta al contrato llamante antes de que se termine la primera llamada de función, y el contrato llamante no ha actualizado su estado interno. El contrato externo puede entonces realizar retiros repetidamente, vaciando los fondos del contrato vulnerable.

Consulta una explicación más detallada de los ataques de reentrada y una lista de hacks conocidos aquí.

La reentrada de contrato está permitida en los contratos inteligentes de Solidity y, por lo tanto, proporciona espacio para uno de los tipos de ataque más icónicos en Ethereum — uno de los hacks más famosos fue El hackeo de DAO, que llevó a una pérdida de $60M. Los desarrolladores deben implementar medidas de seguridad adicionales al diseñar sus contratos inteligentes para protegerse contra estas vulnerabilidades.

¿Cuál es una manera infalible de prevenir ataques de reentrada? No permitir la reentrada de contrato — ¡eso es lo que hace Soroban!

Un checksum es una forma de asegurar la seguridad de una dirección verificando que los caracteres de la dirección no hayan sido alterados o mal comunicados. El checksum utiliza el caso de cada letra como un mecanismo de verificación de errores — si la dirección se altera, se reconoce como inválida. Las direcciones sin checksum carecen de esta medida de seguridad, y si cometes un error al ingresar una dirección, podrías enviar fondos al destino equivocado.

Cuando Ethereum se lanzó, sus direcciones no tenían checksum. En 2016, se implementó una propuesta (ERC-55: Codificación de direcciones con checksum de mayúsculas y minúsculas) que proporcionó una solución compatible con versiones anteriores que agregaba y verificaba letras mayúsculas en las direcciones. Aunque este estándar existe, todavía puedes escribir direcciones de Ethereum de dos maneras: una dirección sin checksum con todas las letras minúsculas o una dirección con checksum que incluye letras mayúsculas. Este clásico problema facilita que los desarrolladores cometan errores que podrían costarle a los usuarios.

Alternativamente, todas las representaciones estándar de claves de Stellar (y ahora Soroban) incluyen checksum. Las claves públicas de Stellar están en un formato llamado Strkey, que es una forma de codificación base32 que incluye un CRC16 checksum incorporado, lo que mejora la seguridad y la interoperabilidad.

Con el estándar de token ERC-20, hay dos transacciones separadas necesarias para hacer un intercambio: `approve` y `transferFrom`. La función `approve` no transfiere tokens pero establece una asignación especificando cuántos tokens la dirección aprobada está autorizada a gastar en nombre del propietario del token. La función `transferFrom` luego transfiere los tokens. Este diseño puede plantear algunos desafíos, como riesgos de seguridad (las asignaciones persisten hasta que se cambian o gastan — un usuario puede dejarla abierta inadvertidamente incluso cuando ya no es necesaria) y costos de gas (cada transacción `approve` requiere una tarifa de gas adicional, por lo que tener dos transacciones para la transferencia de un token aumenta significativamente los costos).

El marco de autorización de Soroban está construido para permitir transferencias de tokens en una sola transacción sin necesidad de aprobaciones separadas. Este diseño ayuda a hacer todo más transparente — la asignación y la transferencia están agrupadas juntas en una transacción, lo que facilita su comprensión con menos margen para errores.

Puede parecer que estoy siendo duro con Ethereum aquí. Esa no es mi intención. Ethereum es la plataforma de contratos inteligentes más popular por una razón — tiene un ecosistema vibrante de dApps y una gran comunidad de desarrolladores.

Lo que estoy diciendo es que Ethereum fue el primero de su tipo, y tenemos el lujo de aprender de sus experiencias para mejorar el diseño de Soroban. Muchas de las quejas sobre Ethereum mencionadas anteriormente tienen soluciones, solo requieren un esfuerzo o costos adicionales por parte del desarrollador de contratos inteligentes o del usuario final para implementar.

Soroban está siendo construida para proporcionar una experiencia amigable y completa para el desarrollador, y estos aprendizajes son solo algunas formas de hacer eso una realidad. Por supuesto, nunca se puede garantizar la seguridad, pero el objetivo es proporcionar el marco y las herramientas para que los desarrolladores puedan crear productos más seguros de manera más fácil. El lanzamiento de Soroban en Mainnet está previsto para finales de este año. Asegúrate de mantenerte al tanto de los anuncios relacionados con Soroban en nuestro Discord de Desarrolladores de Stellar y experimenta en la plataforma hoy.