Control de acceso en la red secreta — Llaves de visualización frente a los permisos.
Los contratos inteligentes tienen ahora privacidad nativa gracias a Secret Network. Los usuarios disponen de capacidades de control de acceso a sus datos, activos y NFTs mediante claves de visualización y permisos. ¿En qué se diferencian ambos?
Secret Network puede proporcionar un control de acceso nativo, algo que ninguna blockchain pública por defecto puede hacer, permitiendo a los desarrolladores crear aplicaciones que preserven la privacidad y permitiendo a los usuarios tomar el control de sus datos.
Las claves de visualización y los permisos de consulta son las dos implementaciones de diseño tecnológico actuales para el control de acceso. Vamos a ver con más detalle estos requisitos y cómo se diferencian entre sí.
Las llaves de la vista: Los problemas que resuelven y crean
Los datos del usuario en Secret Network están encriptados por defecto. Un usuario puede ocultar metadatos, como los saldos, a otros usuarios de la red, incluido el usuario propietario de los activos públicos, convirtiendo ETH, BNB y SCRT en sus equivalentes privados (sETH, sBNB y sSCRT). Por tanto, el cifrado supone un problema para la experiencia del usuario, a pesar del beneficio adicional en materia de seguridad.
Si nuestros consumidores no pueden ver cuántos tokens tienen en sus carteras, ¿cómo deberían conectarse con las aplicaciones de la red?
Los tokens secretos, también conocidos como tokens compatibles con SNIP, se basan en las normas actuales del ecosistema Cosmos. Como resultado, es imposible confirmar la identidad de un consultante utilizando criptografía. En otras palabras, es imposible descifrar la información básica del usuario sin una forma de confirmar su identidad. La especificación SNIP-20 incluyó las claves de visualización como solución a este problema.
La aplicación típica de una llave de visualización se representa en el diagrama anterior.
- Alice establece una llave de visualización (contraseña) para un token SNIP específico ya que no puede ver su saldo.
- El contrato inteligente encargado de controlar el token SNIP almacena la contraseña de Alice en el estado del contrato.
- Cualquiera puede solicitar la consulta del saldo de Alice en un momento posterior, incluido Bob. Si Bob ha recibido autorización para utilizar la clave de visualización de Alice, el contrato inteligente le proporcionará con éxito el saldo de la cuenta de Alice.
Las llaves de visualización sirven como contraseñas encriptadas. Las claves de visualización demuestran el alto nivel de control de acceso que se ofrece a los usuarios en Secret Network al permitirles generar e intercambiar estas contraseñas con programas externos. Sin las claves de visualización de Alice, otros no podrían acceder a su información privada.
Desgraciadamente, las llaves de visualización aumentan la fricción de la red de forma significativa y proporcionan un canal para que los problemas técnicos se manifiesten durante los periodos de alto tráfico. La ocultación de información importante de la cuenta a los usuarios sin claves de visualización es una característica que, en el mejor de los casos, provoca una confusión momentánea a los nuevos usuarios y, en el peor, desalienta el uso de la red. Los usuarios deben enviar una transacción y pagar un precio ínfimo para cubrir el coste de la gasolina con el fin de establecer estas claves encriptadas, ya que las claves de visualización se mantienen en el estado de un contrato inteligente. Por lo tanto, existe un coste inicial mínimo para los nuevos clientes que sólo deseen examinar el saldo de su cuenta al utilizar las llaves de visualización.
Este problema de UX se agrava en el caso de los activos públicos puenteados, como BNB (Binance Coin), porque es probable que los nuevos usuarios carezcan de una SCRT con la que pagar el gas. No se puede enviar una transacción, no se puede hacer una clave de visualización, y el usuario no puede comprobar su saldo de sBNB recién puenteado y privado sin utilizar SCRT para pagar el gas.
Además, en épocas de mucho tráfico, la creación de muchas llavesde visualización, a veces innecesarias, en rápida sucesión ha resultado ser una carga para la red. Por ejemplo, la primera colección de NFT privada por defecto en Secret Network, Anons, generó un uso importante para la red. Los usuarios, temerosos de perderse la acuñación pública, corrieron al sitio web de Anons para asegurar sus NFT. El proceso de acuñación de Anons guiaba a los usuarios por una ruta de UX que requería que los usuarios crearan claves de visualización antes de la acuñación. Debido a la naturaleza de una acuñación de NFT, en la que el tiempo es sensible y los tokens son escasos, un montón de usuarios interactuaron con el contrato inteligente de Anons para crear claves de visualización, se generó una avalancha de transacciones, lo que a su vez llevó a la detención de la red y a un retraso en el lanzamiento del proyecto Anons.
La sobrecarga de peticiones hace que los nodos se desincronicen, lo que lleva a transacciones fallidas. Los usuarios que reciben solicitudes infructuosas probablemente tomen represalias realizando más solicitudes, lo que sólo empeorará el problema. Por lo tanto, se puso en marcha un nuevo enfoque para consultar los datos privados de los usuarios con el fin de resolver estos problemas técnicos y de experiencia.
En conclusión, las mayores dificultades para ver las claves son:
- Los nuevos usuarios deben pagar un precio único y por adelantado para ver las llaves con el fin de acceder a los detalles básicos de la cuenta, incluidos los saldos y los historiales de transacciones.
- Cuando hay mucho tráfico, la UI/UX diseñada para visualizar las llaves puede dar lugar a la creación de varias transacciones innecesarias que perjudican el rendimiento del nodo y causan problemas de red en cascada.
Permisos de consulta: El método de consulta alternativo
La especificación de diseño de SNIP-24 incluía permisos de consulta. En comparación con las llaves de visualización, los permisos son una mejor técnica de búsqueda, según la documentación. Podemos entender mejor cómo funcionan los permisos y por qué son una mejora importante para los usuarios de Secret Network utilizando el ejemplo anterior de Alice, una usuaria que desea comprobar el saldo de su cuenta secreta.
Los permisos de consulta utilizan el cifrado de clave pública, un método criptográfico, junto con las firmas digitales. Los permisos son mensajes estructurados. En ellos se definen una serie de argumentos, entre los que se incluye qué fichas están cubiertas por el permiso y los permisos que deben incluirse en él (como, por ejemplo, si el consultante debe poder examinar el historial de transacciones de un usuario, su saldo, etc.). Alice ha firmado este mensaje con la clave privada asociada a su cuenta. Alice transmite su permiso debidamente ejecutado a un contrato inteligente como argumento cada vez que presenta una solicitud. Al recibirlo, la identidad de Alice puede ser verificada por el contrato inteligente utilizando su clave pública y la firma que ha dado. El contrato inteligente devuelve la información solicitada por Alice si su identificación es verificada.
Nótese que, a diferencia de las llaves de visualización, el contrato inteligente nunca muta su estado para guardar la identidad de Alice. Por lo tanto, no hay ninguna transacción asociada con el uso de los permisos de consulta, y no hay ninguna tarifa por solicitar información básica del usuario. Esto supone una importante mejora de la UX para los usuarios finales. Además, como no hay ninguna transacción asociada a los permisos de consulta, no hay riesgo de que los permisos obstaculicen el rendimiento de la red en momentos de mucho tráfico.
Aunque los permisos mejoran significativamente la experiencia del usuario, tienen una contrapartida. Los permisos de consulta consumen más recursos en los nodos que ejecutan la red. Dado que la identidad de un usuario nunca se guarda, siempre hay que validar un permiso con cada solicitud de consulta. Este proceso es más costoso en términos de potencia de cálculo en comparación con la visualización de claves, que sólo requiere una comprobación básica de los datos almacenados en el estado de un contrato inteligente. Sin embargo, la mejora general de la experiencia del usuario y de la estabilidad de la red merece la pena por la presión añadida que se ejerce sobre los nodos para validar los permisos.
Diseñar para la experiencia del usuario
Debido a la novedad de los permisos de consulta, las aplicaciones descentralizadas construidas en Secret Network los han utilizado con diferentes grados de éxito. Si se utilizan de forma inadecuada, los permisos pueden crear una UX más friccionada que la visualización de claves, por lo que es vital que los desarrolladores tengan en cuenta el impacto que los permisos de consulta tienen en el diseño de la UI y la UX. Esta sección tiene como objetivo proporcionar un breve conjunto de recomendaciones para que los desarrolladores sigan al utilizar los permisos de consulta.
Los permisos de consulta deben ser almacenados
Los permisos son mensajes efímeros que deben pasarse a un contrato inteligente cada vez que se realiza una consulta. Obligar a un usuario a regenerar un permiso con cada consulta es, posiblemente, una peor experiencia para el usuario que pagar una cuota única para crear una clave de visualización. Por lo tanto, después de crear un permiso, debería guardarse en el navegador, (por ejemplo, en localStorage), para poder reutilizarlo más adelante. Si los permisos se guardan, los desarrolladores pueden proporcionar una experiencia fluida a los usuarios, enviando futuras consultas sin que el usuario final note que se ha realizado una solicitud.
Los permisos almacenados deben utilizarse para siempre o hasta que sean revocados.
Para reiterar, no es necesario volver a crear un permiso una vez que se ha generado. La interfaz de usuario de una aplicación debe ofrecer a los usuarios una forma sencilla de revocar los permisos. Los permisos pueden ser revocados enviando un mensaje de revocación cuyo único parámetro es el nombre del permiso a revocar.
Los permisos de consulta pueden aplicarse a varios tokens secretos
En lugar de obligar al usuario a crear un nuevo permiso para cada token secreto que pueda utilizar su aplicación, es mejor permitir que se utilicen múltiples tokens bajo el mismo permiso. Se pueden especificar más tokens en la matriz allowed_tokens del mensaje de permiso. Los desarrolladores deben tener en cuenta el dominio de su aplicación y permitir múltiples tokens en consecuencia.
Siguiendo estas sencillas directrices para los permisos de consulta, los desarrolladores pueden proporcionar una experiencia de usuario definitivamente mejor para sus aplicaciones en Secret Network. Para más detalles sobre los permisos y su implementación, eche un vistazo a la documentación de SNIP-24 que se encuentra en el GitHub de la Fundación Secret.
Conclusión
Secret Network es una solución de blockchain de capa 1 que combina la resistencia de la privacidad y la revolución de los contratos inteligentes escalables. Las soluciones de seguridad a menudo vienen a expensas de la experiencia del usuario. Los desarrolladores de Secret Network adoptan una postura activa para desahogar a los nuevos usuarios, de modo que todos puedan acceder a las finanzas privadas descentralizadas con facilidad. Las claves de visualización fueron la primera implementación del control de acceso para los usuarios finales, pero tuvieron un coste, tanto para la experiencia del usuario como para la estabilidad de la red. Los permisos de consulta son una mejora de los tokens que preservan la privacidad de Secret Network. A medida que los desarrolladores construyan nuevas aplicaciones y refactoricen las herramientas existentes de acuerdo con este nuevo estándar, los usuarios finales podrán explorar el ecosistema con la misma facilidad con la que lo harían en una cadena pública por defecto. Al asegurar los datos de los usuarios y proporcionarles herramientas sencillas de control de acceso, como las claves de visualización y los permisos, Secret Network da un paso más hacia un futuro en el que la privacidad está a la vanguardia del movimiento Web3.
