Stacks-wallet-web: Método Expose para firmar mensajes arbitrarios.

¡Gracias por publicar esto! Creo que esa característica es crucial.

¡Gracias por publicar esto! Creo que esa característica es crucial.

Estoy de acuerdo, y creo que muchos en el equipo también estarían de acuerdo 👍 Trabajaré para actualizar este problema a medida que lo analicemos.

@MarvinJanssen ¿Te importa indicar los casos de uso que te gustaría construir a corto plazo con esto para ayudar a sopesar las prioridades?

@markmhx hablando a corto plazo, en realidad solo hay una razón por la que lo necesito.

Estoy creando un componente del lado del servidor que rastrea las URL del depósito de la aplicación del usuario (para archivos de zona). Para proteger esta API, el usuario debe firmar la URL de su depósito con Connect. Luego, el servidor resuelve el nombre BNS informado del usuario a través del contrato BNS y utiliza el principal correspondiente para verificar la firma. Básicamente, necesito verificar que un mensaje específico realmente provenga de un director que posee un nombre en BNS. Si tiene soluciones alternativas, hágamelo saber. Mi plan de respaldo era presentar un contrato de Clarity simple y hacer que el usuario enviara una prueba a través de una llamada de contrato, pero eso lo convierte en una solución alternativa para una solución alternativa para una solución alternativa...

hay otros 2 casos de uso principales que he visto que se usan firmas en Eth:

• demuestre que posee una dirección y el sitio revelará análisis sobre su dirección que solo usted puede ver (lo cual es bueno)
• vote (a diferencia de uniswap, por ejemplo, que requiere el pago de una tarifa de gas, synthetix solo requiere una firma por voto, lo que no le cuesta nada, lo que suena correcto para la votación de gobierno)

@psq sí, a largo plazo lo necesitamos para DeFi y DeX, y plataformas que hacen coincidencias del lado del servidor que requieren firmas de usuario. (Como 0x Protocol y Wyvern en Ethereum).

Gracias por el contexto adicional 🙏 Le estoy asignando a Jasper para que pueda diseñar.

Veo que esto está en la nevera @markmhx , ¿eso significa que se considerará en un sprint posterior? @MarvinJanssen está esperando actualizaciones 🙂

He movido este problema de vuelta al trabajo pendiente de Kanban .

Tenga en cuenta que ya no estamos trabajando en sprints de 2 semanas, sino en una entrega incremental de prioridades como se refleja en la acumulación de arriba a abajo.

Estoy totalmente de acuerdo con la evaluación de un sistema para estructuras de datos tipeadas firmadas, pero esa es una tarea de ingeniería mucho más grande que no creo que debamos asumir primero. El principal beneficio de los datos estructurados son las transacciones en cadena sin cargo con lógica vinculada a los datos en esa firma. Sin embargo, dos cosas:

• Las transacciones patrocinadas hacen que cualquier llamada de contrato pueda ser gratuita. El único inconveniente aquí es que no puede hacer firmas por lotes
• La especificación ETH está muy ligada a cómo este formato de datos se puede codificar RLP y usar en EVM. Tendríamos que trabajar mucho para determinar cómo podría funcionar eso con Clarity, y luego podemos hacer una especificación a partir de eso, y luego podemos agregarlo a la billetera.

Las cadenas son el caso de uso más obvio para Stacks en este momento. Permitiría el caso de uso muy común de proporcionar acceso fuera de la cadena a un usuario que pueda demostrar que posee una dirección STX. Por ejemplo, una aplicación web que brinda una funcionalidad específica si posee un NFT.

Para ser más concretos sobre los casos de uso:

• Inicie sesión en la aplicación web y demuestre que posee una dirección STX
  
  
  
  • técnicamente no está resuelto por autenticación en este momento, porque firma con una clave diferente a la anterior a la 2.0, pero podemos/debemos cambiar eso
  
  
• Comparta un mensaje específico para fuera de la cadena que demuestre que posee una dirección STX
  
  
  
  • firmar una cadena, la versión "fácil" de este problema
  
  
• Aprobaciones de tokens sin cargo
  
  
  
  • resuelto por condiciones posteriores
  
  
• Voto DAO sin cargo
  
  
  
  • resuelto por transacciones patrocinadas
  
  
• Votación DAO sin cargo por lotes u otras cosas complejas sin cargo por lotes en cadena
  
  
  
  • necesita equivalente ERC712
  
  

Durante una conversación con @MarvinJanssen y @GinaAbrams ayer, se determinó que la aplicación .BTC no tendrá una necesidad urgente de firmar mensajes arbitrarios a menos que sucedan dos cosas secuencialmente:

1. No podemos implementar correcciones de Atlas en la red principal en las próximas dos semanas.
2. No puede implementar el mecanismo de informes de archivos de zona que necesita como solución alternativa mediante un contrato inteligente personalizado de Clarity y la firma y transmisión de transacciones con la extensión Stacks Wallet.

La ruta de firma de mensajes arbitrarios es básicamente una alternativa a las rutas anteriores, que son preferibles en el orden indicado. Implicaría enviar mensajes firmados con datos de archivo de zona a un servidor centralizado, lo que ahorraría al usuario final el costo de tener que firmar una transacción, pero también incurriría en la participación no deseada de una parte centralizada.

@agraebe @diwakergupta Me comunicaré con splat la próxima semana para ver cómo van los planes de implementación de Atlas para que podamos brindarle a @MarvinJanssen una actualización aquí con respecto al tiempo y cómo afecta sus opciones.

Está feliz de esperar una o dos semanas para ver si podemos obtener las correcciones en vivo en la red principal y ahorrarle el trabajo de cualquiera de las soluciones.

Esto es algo invaluable, el uso de firmas de la identidad probaría la propiedad de un nombre y muchas cosas, especialmente cuando se trata de operaciones fuera de la cadena, 100% para esto.