Saltar al contenido principal

Consideraciones de diseño de la aplicación

Modelos de custodia​

Al construir una aplicación, una de las primeras cosas que tienes que decidir es cómo se asegurarán y almacenarán las claves secretas de tus usuarios. Las aplicaciones Stellar brindan a los usuarios acceso a sus cuentas que están almacenadas en el ledger, y el acceso a estas cuentas está controlado por la clave secreta de la cuenta. Esa clave secreta prueba que el usuario tiene custodia o "posee" la cuenta.

Hay cuatro opciones de custodia a considerar:

  • Servicio no custodial - el usuario de la aplicación almacena su propia clave secreta
  • Servicio custodial - el proveedor de servicios (la aplicación) almacena las claves secretas de los usuarios
  • Una mezcla de ambos - con el uso de multisig, esta opción es útil para mantener el estado no custodial mientras se permite la recuperación de cuentas
  • Servicios de gestión de claves de terceros - integra un servicio custodial de terceros en tu aplicación que pueda almacenar las claves secretas de tus usuarios

Servicio no custodial​

En un servicio no custodial, el usuario de la aplicación almacena la clave secreta de su cuenta y permite que la aplicación envíe solicitudes para delegar la firma de transacciones. Hay algunos problemas de usabilidad potenciales ya que el usuario tiene que saber cómo almacenar de manera segura sus propias credenciales de cuenta y navegar de forma segura en la firma de transacciones por su parte. Si pierden su clave secreta, también perderán el acceso a su cuenta.

Típicamente, las aplicaciones no custodiales crean o importan una cuenta Stellar preexistente para cada usuario.

Servicio custodial​

Con un servicio custodial, el proveedor de servicios (una aplicación como un exchange centralizado) almacena las claves secretas de los usuarios y delega los derechos de uso al usuario.

Muchos servicios custodiales eligen usar una única cuenta Stellar agrupada (llamada cuentas compartidas, omnibus o cuentas agrupadas) para manejar transacciones en nombre de sus usuarios en lugar de crear una nueva cuenta Stellar para cada usuario. Para distinguir entre usuarios individuales en una cuenta agrupada, recomendamos la implementación de cuentas muxed.

Una mezcla de no custodial y custodial​

Construir una aplicación con capacidades de multi-firma te permite tener un servicio no custodial con recuperación de cuentas. Si el usuario pierde su clave secreta, todavía puede firmar transacciones con otras firmas autorizadas, dado que el umbral de firma sea lo suficientemente alto.

Servicios de gestión de claves de terceros​​

Hay varias aplicaciones y servicios que se especializan en agregar capas de seguridad adicionales a las cuentas de los usuarios. Considérelos si estás interesado en integrar un servicio de gestión de claves de terceros:

Seguridad de la aplicación​

A pesar de que las billeteras pueden operar del lado del cliente, manejan las claves secretas de un usuario, que dan acceso directo a su cuenta y a cualquier valor que posean. Por eso, es esencial requerir que todo el tráfico web fluya a través de métodos TLS sólidos. Incluso cuando desarrollas localmente, utiliza un certificado de localhost no firmado para desarrollar hábitos seguros desde el principio. Stellar es un potente software para mover dinero; no escatimes en seguridad.

Para más información, consulta nuestra guía sobre asegurar productos basados en la web.

Servicios de billetera​

Una billetera típicamente tiene estas funciones básicas: almacenamiento de claves, creación de cuentas, firma de transacciones y consultas a la base de datos de Stellar. Hay algunos servicios que se encargan de todas estas funciones por ti, así que puedes construir lo que desees a su alrededor. Consulta algunos de estos servicios de billetera a continuación.

Estrategias de creación de cuentas​

En esta sección, revisaremos el flujo de creación de cuentas para nuevos usuarios entre billeteras no custodiales y anclajes con implementaciones de SEP-24 y/o SEP-6. Una cuenta Stellar se crea con un keypair (una clave pública y una clave privada) y el saldo mínimo de XLM.

Cuando un nuevo cliente descarga la aplicación de billetera y pasa por el flujo de depósito por primera vez, su cuenta Stellar puede ser creada bien por la aplicación de billetera del usuario o por el anclaje que facilita el primer depósito. Esta sección describe cada una de estas estrategias.

Opción 1: el anclaje crea y financia la cuenta Stellar​​

Para esta opción, la billetera necesita permitir que los usuarios inicien su primer depósito sin tener que agregar un activo/establecer una línea de confianza. La billetera luego solicita al usuario que agregue la línea de confianza una vez que los fondos sean recibidos por el anclaje. El flujo se ve así:

  1. La billetera registra un nuevo usuario y emite un keypair.
  2. La billetera inicia el primer depósito en nombre del usuario sin requerir que el usuario agregue el activo/cree la línea de confianza.
  3. El anclaje proporciona instrucciones de depósito al cliente.
  4. El usuario transfiere dinero de su cuenta bancaria a la cuenta bancaria del anclaje.
  5. Una vez que el anclaje recibe la transferencia, el anclaje crea y financia la cuenta Stellar para el cliente.
  6. La billetera detecta que la cuenta ha sido creada y que se debe establecer una línea de confianza.
  7. La billetera solicita al usuario que agregue el activo/cree la línea de confianza.
  8. Finalmente, el anclaje envía los fondos del depósito a la cuenta Stellar del usuario.
información

Un anclaje siempre debe mantener una cantidad saludable de XLM en su cuenta de distribución para soportar nuevas creaciones de cuentas. Si hacerlo se vuelve insostenible, se recomienda que el anclaje colabore con billeteras para determinar una estrategia basada en el número de solicitudes de creación de cuentas. La cantidad recomendada es 2XLM por usuario para la creación de cuentas (1XLM para cumplir con el requisito de saldo mínimo, y 1XLM para establecer líneas de confianza y cubrir tarifas de transacción).

Con el flujo descrito arriba, la billetera y el anclaje deben facilitar la escucha y la respuesta al estado de la línea de confianza, lo que puede crear fricciones en la experiencia del usuario al esperar que se establezca la línea de confianza. Para abordar este problema, el Protocolo 15 introdujo saldos reclamables, que mejoran el flujo al permitir que los usuarios empiecen a usar la billetera sin tener que asegurar XLM. Tanto la billetera como el anclaje deben implementar el soporte para saldos reclamables para que este flujo funcione.

El flujo con Saldos Reclamables se ve así:

  1. La billetera registra un nuevo usuario y genera un keypair.
  2. La billetera inicia un depósito en nombre de un usuario.
  3. El anclaje proporciona instrucciones de depósito a la billetera.
  4. El usuario transfiere dinero de una cuenta bancaria a la cuenta del anclaje.
  5. El anclaje crea y financia la cuenta Stellar del usuario más la cantidad requerida para líneas de confianza y tarifas de transacción. Nuevamente, sugerimos 2 XLM para comenzar.
  6. El anclaje crea un Saldo Reclamable.
  7. La billetera detecta el Saldo Reclamable para la cuenta, reclama los fondos y los publica en la billetera.

Opción 2: la billetera crea y financia la cuenta Stellar al registrarse el usuario​​

Para esta opción, la billetera crea y financia la cuenta Stellar al registrarse cada nuevo usuario con el requisito mínimo de 1XLM, más el 0.5XLM de reserva para establecer la primera línea de confianza, además de un poco más para cubrir tarifas de transacción. Para más información sobre los saldos mínimos, consulta la sección de Lumens.

El flujo se ve así:

  1. Al registrarse un nuevo usuario, la billetera emite un keypair, luego crea y financia la cuenta Stellar del usuario con 2XLM.
  2. Luego, la billetera crea una línea de confianza e inicia el primer depósito.
  3. Una vez que la solicitud de depósito se envía al anclaje, el anclaje proporciona instrucciones para el depósito.
  4. El cliente transfiere fondos desde una cuenta bancaria personal a la cuenta del anclaje.
  5. El anclaje recibe los fondos y luego los envía a la cuenta Stellar del usuario.
  6. La billetera detecta que se enviaron fondos y notifica al usuario.
nota

En los ejemplos anteriores, sugerimos que el anclaje o la billetera cubran los requisitos de saldo mínimo y de línea de confianza en XLM depositando fondos directamente en la cuenta de un usuario. Hicimos esa sugerencia por simplicidad, pero en todos los casos, el anclaje o la billetera podrían en su lugar usar reservas patrocinadas para asegurar que cuando un usuario cierra una línea de confianza o fusiona su cuenta, la reserva regrese a la cuenta patrocinadora en lugar de a la cuenta del usuario.