Thu Feb 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
· 3 min de lectura
Gerente de Producto
- La reunión se centró en el proceso de añadir funciones de host, utilizando WebAuthN como caso de uso de ejemplo; continuó de la reunión anterior.
- Discusión sobre las preocupaciones restantes con la adición de la función de host de verificación secp256r1 de la reunión anterior.
- ¿Qué significa que secp256r1 se agregue como una función de host versus como un tipo de firmante?
- Como función de host, el usuario puede firmar entradas de autenticación de soroban. Necesito otra cuenta stellar para financiar y enviar tx a la cadena. Este último puede ser realizado por una cuenta stellar que puede ser operada por una billetera o un contrato. Need another stellar account to fund and submit tx to the chain. El último se puede hacer mediante una cuenta stellar que puede ser operada por una billetera o un contrato.
- __check_auth se invoca cuando el contrato con el que se está interactuando llama a require_auth
- ¿Qué significa que secp256r1 se agregue como una función de host versus como un tipo de firmante?
- CAP-52 fue redactado para introducir funciones de codificación/decodificación para Base64, que es necesario para WebAuthN. Consideraciones discutidas en la reunión:
- Rendimiento: 1066 bytes que cuestan 1M instr para codificar un hash de 32bytes; así que el costo es muy bajo y es cuestionable si se necesita una función de host.
- La interfaz requiere dos funciones (codificar/decodificar)
- Implementation wise, WebAuthN requires url alphabet and padding, which decoder likely needs to support. ¿Deberíamos usar símbolos o enteros? ¿Necesitamos alfabetos personalizados?
- ¿Realmente necesitamos más esquemas de codificación? ¿No es suficiente XDR?
- Los mecanismos de autenticación costosos, es decir, webauthn, no pueden estar acoplados con contratos con lógica comercial pesada (que podrían ser muchos contratos), lo que hace que la adopción sea problemática.
- Probablemente deberíamos agregar bloques de construcción para permitir que el ecosistema agregue nuevos casos de uso.
- CAP-53 was drafted to introduce encoding/decoding functions for JSON, which is needed by WebAuthN. Considerations discussed in the meeting:
- Rendimiento: 3.9Kb, 2.5M instrucciones de CPU.
- Si el tamaño del blob de entrada es desconocido, el tiempo de ejecución aumentará.
- Es valioso tener tal función ligera que se utilizará en varios lugares.
- Interfaz: 11 funciones
- ¿Qué hacer con números y decimales? ¿Agregar decimales y flotantes?
- Solo tenemos que extraer un campo para WebAuthN, pero ¿qué pasa con el caso general?
- El tipo de número en JSON es decimal, pero soroban no lo soporta. ¿Cómo debería manejarse esto?
- Discusión sobre una interfaz alternativa e implementaciones.
- Preocupaciones de los desarrolladores principales
- Mantenibilidad: si agregas una función de host, debes mantenerla para siempre. Si hay más versiones, tenemos que mantenerlo.
- Superficie expandida para errores de seguridad.
- Debería definirse un camino donde los desarrolladores principales no estén en el bucle de implementación, ya que sus horarios están llenos de trabajo de estabilidad. How to prioritize against stability work, which may get derailed due to new functionality such as what’s being currently discussed.
- Próximos pasos:
- El equipo principal debe elaborar un plan para agregar Base64. Este es un ejercicio importante que ayuda a determinar aún más desafíos al hacerlo. El resultado de este ejercicio puede ser que Base64 no debería de hecho ser implementado en este momento.
- La discusión sobre la interfaz JSON continuará.