Decisiones de diseño técnico de Soroban y aprendizajes 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. El éter y los lúmenes también se pueden usar de manera similar a otros activos, incluido el comercio en intercambios, y más.

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

Por otro lado, el XLM de Stellar interactúa con los 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 de Stellar (incluido XLM), ese activo es inmediatamente utilizable por todos los contratos inteligentes de Soroban sin pasos o transacciones adicionales. Tratar XLM como cualquier otro activo optimiza su utilidad y también minimiza las tarifas para el usuario.

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

En Ethereum, no se emiten eventos cuando se transfiere el token nativo ETH. Los tokens ERC-20, al ser contratos inteligentes en sí mismos, emiten un evento de transferencia al ser intercambiados. Sin embargo, como ETH no es un token ERC-20 y no sigue los estándares de token, 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 trabajar más para rastrear las transferencias nativas, una característica que agiliza la experiencia del desarrollador, permite un código más limpio y sencillo, y optimiza la utilidad de XLM en Soroban.

Los exploits de re-entrada pueden ocurrir cuando un contrato inteligente realiza una llamada (como una retirada) a un contrato externo y luego actualiza su estado interno (como debitar el valor de la retirada de la cuenta). El ataque ocurre cuando el contrato externo realiza una llamada recursiva de vuelta al contrato llamante antes de que se haya completado la primera llamada de función, y el contrato llamante no ha actualizado su estado interno. El contrato externo puede luego realizar retiradas repetidamente, agotando los fondos del contrato vulnerable.

Consulta una explicación más detallada de los ataques de re-entrada 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 hack de The 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 forma segura de prevenir los ataques de re-entrada? ¡No permitir la reentrada de contrato — que es lo que hace Soroban!

Un checksum es una forma de garantizar la seguridad de una dirección verificando que los caracteres de la dirección no se hayan alterado o comunicado de manera incorrecta. El checksum utiliza el caso de cada letra para servir 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 incorrecto.

Cuando Ethereum se lanzó, sus direcciones no tenían checksum. En 2016, se propuso (ERC-55: La codificación de direcciones de checksum de mayúsculas y minúsculas) se implementó, lo que proporcionó una solución compatible con versiones anteriores que agregó y verificó letras mayúsculas en direcciones. Aunque este estándar existe, aún puedes escribir direcciones de Ethereum de dos formas: una dirección sin checksum con todas las letras en minúsculas o una dirección con checksum que incluye letras mayúsculas. Esta clásica trampa de pie facilita que los desarrolladores cometan errores que podrían costarles a los usuarios.

Alternativamente, todas las representaciones de claves estándar 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 checksum CRC16 integrado, lo que mejora la seguridad y la interoperabilidad.

Con el estándar de tokens ERC-20, se requieren dos transacciones separadas para realizar un intercambio: 'aprobar' y 'transferirDesde'. La función 'aprobar' no transfiere tokens, sino que establece un permiso especificando cuántos tokens la dirección aprobada puede gastar en nombre del propietario del token. La función 'transferirDesde' luego transfiere los tokens. Este diseño puede plantear algunos desafíos, como riesgos de seguridad (los permisos persisten hasta que se cambian o se gastan, un usuario puede dejarlo inadvertidamente abierto incluso cuando ya no es necesario) y costos de gas (cada transacción de 'aprobar' requiere una tarifa de gas adicional, por lo que tener dos transacciones para una transferencia de token aumenta significativamente los costos).

El marco de autorización de Soroban está diseñado para permitir transferencias de tokens en una sola transacción sin la necesidad de aprobaciones separadas. Este diseño ayuda a que todo sea más transparente: la aprobación y la transferencia se agrupan en una sola transacción, lo que facilita la comprensión y reduce las posibilidades de errores.

Puede parecer que estoy criticando a 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 en 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 esfuerzo adicional o costos por parte del desarrollador de contratos inteligentes o del usuario final para implementarlas.

Soroban se está construyendo para proporcionar una experiencia incluyente y amigable para los desarrolladores, y estas lecciones son solo algunas formas de hacer que eso sea una realidad. Por supuesto, no 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 con mayor facilidad. El lanzamiento de Soroban en Mainnet está programado para más adelante este año. Asegúrate de mantenerte al tanto de los anuncios relacionados con Soroban en nuestro Stellar Developer Discord y experimentar en la plataforma hoy.