SEP-30 y la Gestión de Claves Amigable con el Usuario

Si nos has seguido hasta aquí en la serie SEP-30, sabes lo importante que es la experiencia del usuario para impulsar la adopción de la tecnología blockchain, y tienes un mejor entendimiento de las deficiencias en la gestión y recuperación de claves hoy en día.

Ahora, es el momento del resultado: una explicación de cómo SEP-30 proporciona una solución sin problemas y centrada en el usuario para la gestión y recuperación de claves.

Para aquellos que no están familiarizados, las Propuestas del Ecosistema Stellar — SEPs por sus siglas en inglés — son especificaciones abiertas que definen las mejores prácticas para construir productos y servicios en Stellar. Hay todo tipo de SEPs, y se relacionan con todo tipo de casos de uso, pero generalmente, explican cómo los proyectos que se construyen en Stellar establecen infraestructura externa a la red — incluyendo APIs — para maximizar la interoperabilidad con otros participantes de la red.

SEP-30 define un enfoque centrado en hacer la gestión de claves, y específicamente la prevención de pérdidas, lo más amigable posible para el usuario. Está diseñado para:

1. Funcionar sin frases de recuperación.
2. Evitar que un tercero controle la cuenta de un usuario.
3. Asegurar que un usuario no necesite recordar una contraseña.
   

SEP-30 está en vivo y operativo en una billetera, Vibrant, una aplicación de ahorros en dólares estadounidenses no custodia que almacena valor en la red de Stellar. Vibrant, que se lanzó recientemente en versión beta, presenta una experiencia de usuario diseñada para el público general.

Lo único que un usuario necesita para iniciar sesión en Vibrant es su número de teléfono. Eso es todo. Sin clave secreta, sin contraseña, solo un número de teléfono. Esto es porque una billetera SEP-30 como Vibrant no gestiona y respalda una única clave maestra. En cambio, gestiona claves de dispositivo, y utiliza multi-firma y servidores distribuidos para crear nuevas cuando sea necesario. Aún realiza muchas de las mismas cosas que otras billeteras hacen — almacena y protege una clave; ayuda a un usuario a firmar transacciones; previene la pérdida — pero la pérdida que previene es diferente: previene que los usuarios pierdan sus cuentas, no sus claves.

SEP-30 define una API que proporciona dos puntos finales, uno para registrar una cuenta y otro para firmar transacciones. Un tercero configura un servidor de recuperación que aloja esos dos puntos finales, y la billetera SEP-30 configura un cliente para consumirlos. Para que todo funcione, la billetera necesita interactuar con dos servidores de recuperación separados e independientes.

Una billetera utiliza el primer punto final para registrar una cuenta con un servidor de recuperación de terceros. En esa solicitud, la billetera le dice al servidor qué identidades están permitidas para solicitar firmas para la cuenta. Las identidades son generalmente números de teléfono o direcciones de correo electrónico.

La billetera se autentica usando SEP-10, una Propuesta del Ecosistema Stellar que define un flujo de desafío-respuesta. La autenticación permite a la billetera probar al servidor que posee claves que pueden firmar por la cuenta Stellar del usuario, lo que significa que puede definir quién está permitido para firmar transacciones para esa cuenta. En respuesta, la billetera recibe una dirección de firma para el servidor, y hace que esa dirección sea un firmante en la cuenta Stellar del usuario.

El segundo punto final del servidor de recuperación maneja la firma de transacciones. Cuando un usuario pierde acceso a su cuenta, la billetera llama a este punto final con una transacción que quiere que el servidor firme. La billetera se autentica usando una identidad proporcionada durante el registro, y si el teléfono o correo electrónico coincide con una identidad que tiene en archivo para la cuenta, el servidor firma la transacción para la cuenta Stellar y devuelve la firma a la billetera.

Para entender mejor cómo esta configuración permite una experiencia de usuario simple y sin problemas, echemos un vistazo a los flujos SEP-30 para el registro y recuperación de cuenta.

1. Cuando Alice crea una cuenta usando la aplicación de billetera en su teléfono, la aplicación genera una clave maestra, y el servidor de la billetera crea la cuenta asociada. La clave maestra, que es la clave roja en el diagrama, es una de esas grandes direcciones S que vimos en el post anterior. La clave maestra no se comparte con nadie, y nunca sale del dispositivo de Alice.

Debido a la forma en que funciona SEP-30, no hay necesidad de que esta clave maestra se respalde en ningún lugar.

2. La billetera de Alice también genera una segunda clave, a la que llamaremos una clave de dispositivo. Es una clave que solo usa el dispositivo — en este caso el teléfono de Alice — para firmar transacciones. La clave de dispositivo, al igual que la clave maestra, no se comparte con nadie.

3. La billetera de Alice envía una transacción a la red Stellar haciendo que esa clave de dispositivo sea un firmante en la cuenta y eliminando la clave maestra como firmante. Luego elimina la clave maestra: ya no es útil.

4. La billetera luego registra la cuenta con dos servidores de recuperación. Cada servidor está alojado y controlado por una entidad separada e independiente, y cada uno tiene su propia clave autogenerada. La billetera demuestra a cada servidor que tiene autoridad sobre la cuenta de Alice firmando una transacción SEP-10, y le dice a cada servidor de recuperación que cualquiera que pueda probar posesión del número de teléfono o correo electrónico de Alice debería poder solicitar que se firmen transacciones.

5. La billetera envía una transacción a la red Stellar agregando ambos servidores de recuperación como firmantes en la cuenta, pero limitando el peso de sus firmas para que ninguno tenga control independiente sobre el valor en la cuenta. Cada servidor de recuperación ahora puede firmar una transacción a solicitud del usuario, pero la transacción solo será autorizada si está firmada por ambas partes independientes.

La única persona con control independiente de la cuenta es Alice.

Imaginemos que Alice perdió su teléfono y tuvo que conseguir uno nuevo. El teléfono perdido de Alice todavía tiene su clave de dispositivo en él, y su nuevo teléfono no tiene ninguna clave para la cuenta.

1. El nuevo teléfono de Alice pasa por el mismo proceso que su teléfono anterior cuando se registró con el servidor de la billetera: genera una clave de dispositivo, y se registra en la billetera.

La nueva clave de dispositivo no es un firmante de su cuenta Stellar, por lo que su dispositivo no puede autorizar transacciones. Al menos no todavía.

2. La billetera contacta al primer servidor de recuperación y le pide que firme una transacción que hace que la nueva clave de dispositivo de Alice sea un firmante en la cuenta. Esta primera firma añade un peso de 10 a la transacción.

3. Alice luego continúa la recuperación con el segundo servidor de recuperación. El segundo servidor de recuperación es operado por un tercero independiente, así que Alice se autentica con ellos independientemente usando un código SMS enviado a su teléfono, o un enlace o código enviado a su dirección de correo electrónico. Una vez que Alice se ha autenticado, el servidor firma la transacción y devuelve la firma a la billetera. Esta firma añade un peso adicional de 10 a la transacción.

4. La transacción ahora tiene un peso de 20, lo cual es suficiente para autorizarla, así que la billetera la envía a la red. La transacción elimina la clave de firma que se perdió con el viejo teléfono de Alice, y añade la nueva clave de firma que vive en el nuevo teléfono de Alice.

Alice ahora vuelve a tener control de su cuenta Stellar.

En los ejemplos anteriores, Alice registró y recuperó acceso a su cuenta usando solo su número de teléfono. Nunca le dio a un tercero control total de su cuenta, y todo sucedió a través de API detrás de escena. No tuvo que pensar en ello o entender cómo funciona la recuperación de claves: solo aceptó los términos de servicio como lo haría con cualquier otro producto, y la billetera se encargó del resto. Esa es la misma experiencia de usuario que Alice — y todos nosotros, realmente — esperamos de una aplicación de consumo.

Una gran experiencia de usuario impulsa la adopción, y apoyar la recuperación de cuenta a través de teléfono, correo electrónico y otras formas de autenticación significa que realmente puedes construir una billetera no custodia amigable con el usuario. Bastante genial.

Sin embargo, lo que pasa con SEP-30, es que depende de una cierta cantidad de infraestructura del ecosistema: para que funcione, necesitan haber tanto billeteras SEP-30 como servidores de recuperación independientes. Así que si has llegado hasta aquí, y estás emocionado por los beneficios que este enfoque de gestión de claves puede traer a la experiencia del consumidor cripto, nos encantaría escuchar de ti. Todos podemos trabajar juntos para construir la infraestructura de gestión de claves que el ecosistema necesita.

Si estás interesado en construir una billetera SEP-30 o en ejecutar un servidor de recuperación — háznoslo saber!