7 publicaciones etiquetadas con "protocol"

Discord agenda thread

Los desarrolladores principales discutieron las últimas propuestas para avanzar en Stellar Core en la reunión de protocolo de esta semana.

1. La propuesta para la adición de un constructor a la variante de Rust de Soroban fue introducida en una reunión de protocolo anterior (reunión anterior), documentada en CAP-58. Un constructor es una función que solo se ejecutará la primera vez que se crea el contrato.
2. En esta reunión, Dima discutió las actualizaciones realizadas desde la última reunión:
   1. Constructor por defecto - si un constructor no se define explícitamente, el contrato se trata como si tuviera un constructor
   2. Semántica del valor de retorno - si la transacción tiene éxito, se requiere que devuelva un valor válido
   3. Interacción del constructor con cuentas personalizadas - las cuentas personalizadas deben ser conscientes del contexto que están autorizando.
3. Graydon discutió la actualización de la máquina virtual Wasmi, documentada en CAP-60. Wasmi funciona traduciendo código WebAssembly a una Representación Interna (IR) y luego ejecutándola. La actualización tiene un impacto de dos maneras.
   1. Traducir de WebAssembly a IR toma más tiempo, pero la ejecución del IR resultante es eficiente.
   2. La actualización introduce compilación perezosa. De todas las funciones en un contrato, solo aquellas que se llaman en una transacción dada serán traducidas, reduciendo así tanto la latencia como las tarifas.
4. Jay discutió la adición de la curva criptográfica BLS12-381, documentada en CAP-59.
   1. La adición de curvas elípticas amigables para el emparejamiento permite aplicaciones basadas en zk. Se han agregado 11 funciones de host para exponer mapeo, emparejamiento y aritmética en la curva BLS12-381.
   2. Se presentó un caso de ejemplo de verificación de firma BLS. Consumió 26M de instrucciones (ejecutándose de forma nativa), lo que es prometedor dado que el límite por transacción es 100M.
   3. Hubo un acuerdo general en que la interfaz es la correcta, ya que permite a un desarrollador de contratos implementar una amplia variedad de casos de uso. La discusión continúa en discord.
   4. Jay solicitó que los desarrolladores construyan aplicaciones contra la función y den su opinión.

Un desarrollador principal, Dima, discutió la propuesta de añadir soporte para constructores a Soroban, el sistema de contratos inteligentes de Stellar.

Enlaces relevantes: Borrador CAP, Discusión en curso, Hilo de Discord motivador

Puntos clave discutidos:

1. La propuesta mejora la usabilidad de Soroban para desarrolladores de contratos y SDK. Un constructor garantiza la inicialización del contrato, reduciendo así el código adicional del contrato que normalmente se añade para asegurar la inicialización.
2. Hubo un acuerdo general con la propuesta, las preguntas se centraron principalmente en la implementación, como si los constructores deben manejar argumentos, qué debe suceder con las actualizaciones, la compatibilidad hacia atrás con las funciones de creación de contratos y el comportamiento en la actualización de wasm.
3. El tema de alto impacto sobre la nomenclatura se somete a votación en el ecosistema, por favor vota aquí.

Piyal de Freighter discutió la propuesta para estandarizar la interfaz de billetera. Los puntos clave de la discusión se capturan a continuación. Para notas completas, por favor ve la grabación; y también consulta la propuesta y la publicación en las discusiones de github.

1. La propuesta borrador
2. Discusión en curso
3. Requerir la frase de paso de la red podría ser una complejidad innecesaria.
4. Tanto WalletConnect como las billeteras móviles probablemente tienen diferencias significativas respecto a la interfaz propuesta (que está dirigida a billeteras de extensiones de navegador); y por lo tanto es probable que requieran un SEP separado. Los SEPs mencionados deberían ser creados por equipos que trabajen en la integración de billeteras con las plataformas mencionadas.
5. ¿Cuál es el papel de Stellar Wallet Kit en el ecosistema y cómo interactúa con el estándar mismo?
6. Como próximos pasos, Piyal incorporará las sugerencias del ecosistema en la propuesta.

Agenda thread

1. El Grupo de Trabajo de Normas propuso cambios al proceso SEP que empoderan al ecosistema al hacer que el proceso actual sea más descentralizado y amigable con el ecosistema.
2. El proceso ya ha sido utilizado para varias propuestas en los últimos tres meses.
3. Esteblock from Soroswap shared their journey of participating in the proposal for Asset List (SEP-42) and implementing the proposed standard
4. La discusión continúa en el documento de propuesta.
5. El siguiente paso es obtener más retroalimentación del ecosistema y luego actualizar el repositorio de SEP de Github con el proceso SEP actualizado.

Discord agenda thread

1. El equipo principal de CAP deliberó sobre las últimas propuestas presentadas por el ecosistema Stellar para avanzar stellar-core.
2. Nicholas y David del equipo principal de CAP escucharon las siguientes propuestas y discutieron las propuestas con los autores. a. El equipo principal de CAP enviará su voto por correo electrónico.
3. Propuestas discutidas:
   a. CAP-51: agregar soporte para la verificación secp256r1; por @leigh
   b. CAP-53: crear funciones separadas para extender el tiempo de vida de la instancia de contrato y del código del contrato; por @tdep
   c. CAP-54: reducir los costos totales refinando el modelo de costos de Soroban utilizado para la creación de instancias de VM en varios costos separados y más precisos; por @graydon
   d. CAP-55: reducir los costos totales al vincular menos funciones host durante la creación de instancias de VM en Soroban; por @graydon
   e. CAP-56: reducir los costos totales almacenando en caché los módulos Wasm analizados dentro de una transacción de Soroban; por @graydon

Discord agenda thread

1. 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.
2. 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
3. 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.
4. 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.
5. 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á.

Discord agenda thread

1. La propuesta es avanzar stellar-core añadiendo una función de host para verificar la firma secp256r1, que es la curva elíptica más común utilizada fuera del espacio blockchain. Es útil para conectar interfaces de autenticación off-chain con funcionalidad on-chain. Es útil en conectar interfaces de autenticación off-chain con funcionalidad on-chain.
2. Nota que la propuesta no es para un nuevo tipo de firmante, sino para una función de host.
3. Leigh investigó añadir la admisión para el caso de uso de WebAuthN, permitiendo a una cuenta / contrato inteligente personalizado firmar entradas de autenticación soroban usando una carga útil firmada por secp256r1.
4. secp256r1 es admitido por teléfonos, claves de acceso, y permite que una app reemplace contraseñas. Este es un gran beneficio para aplicaciones orientadas al usuario como billeteras. Pros y contras de la interfaz: las blockchains generalmente implementan la interfaz de recuperación sobre la interfaz de verificación, pero la verificación es más fácil para los desarrolladores ya que reduce la carga en el cliente y la red.
5. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network.
6. Si bien hay formas ingeniosas de lograr lo último, no es una gran experiencia para el desarrollador y la implementación final es susceptible a fallos en actualizaciones.
7. También es costoso agrupar la decodificación con la verificación en guest.
8. Soroban siempre ha liderado con una mentalidad de que todo viene incluido. Manteniéndose en línea con ese enfoque, tiene sentido investigar más y determinar si una función de host tiene sentido para estos también.
9. La implementación de Leigh puede requerir una evaluación adicional de los crates utilizados para ecdsa y p256. Breve discusión sobre el proceso propuesto para añadir una función de host por un desarrollador no central.
10. La implementación de Leigh puede requerir una evaluación adicional de las crates utilizadas para ecdsa y p256.
11. Breve discusión sobre el proceso propuesto para la adición de una función host por un desarrollador no central.