11 publicaciones etiquetadas con "protocol"

Agenda: Discord thread

El equipo central de CAP deliberó sobre los CAPs propuestos:

1. Adición de un constructor a la variante de Rust de Soroban. CAP
   1. La preocupación del equipo era sobre una posible ruptura en la compatibilidad, lo cual Dima había abordado. No hubo más preocupaciones.
2. Adición de la curva BLS12-381 y la aritmética de campo requerida - CAP
   1. La preocupación del equipo era sobre proporcionar funciones para verificar entradas no válidas. Es demasiado costoso computacionalmente hacer la verificación en la capa del contrato, por lo que puede que necesite implementarse como una función de host. Jay está buscando la opinión del ecosistema sobre los casos de uso que requieren validación estricta de entradas.
   2. No hubo más preocupaciones.
3. Incrementar el rendimiento mejorando la VM de Soroban. Discusión sobre CAP
   1. Los comentarios del equipo eran sobre la precisión del método de medición, pero los beneficios demostrados del tiempo de reloj se consideraron prometedores.
   2. Se sugirió exponer las mejoras de rendimiento a los desarrolladores de contratos, creando así el incentivo para optimizar contratos y aprovechar las mejoras.
   3. No hubo más preocupaciones.

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í.

1. Garand discussed changes to the State Archival proposal based on feedback received at Meridian 2023. Los cambios propuestos son:

• Anteriormente, un sistema de downstream llamado el ESS (Almacenamiento de Estado Caducado) almacenaba entradas caducadas. En la nueva propuesta, no hay ESS. En la nueva propuesta, no hay ESS. Todas las entradas archivadas, así como toda la información requerida para generar pruebas de restauración para esas entradas, se almacena directamente en el Archivo de Historia.
• Los nodos RPC pueden generar pruebas para el estado archivado durante el pre-vuelo
• Captive-core puede ser consultado directamente para el estado archivado, lo que significa que las instancias RPC/Horizon pueden potencialmente atender consultas para el estado de archivo

2. La propuesta de borrador
3. Discusión en curso
4. El tamaño de la imagen está por determinar; es una función del tamaño de la lista de cubos, así como de la memoria y las demandas históricas impuestas al RPC.
5. Los filtros de Bloom son la solución probable para la prueba de inexistencia, aunque vienen con compensaciones. Permiten una búsqueda rápida y económica, pero son probabilísticos, no deterministas.
6. Se agradecen más comentarios.

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

Hilo de agenda en Discord

1. Tommaso (@tdep) propuso un cambio central para permitir extender el TTL de instancia y código con valores separados en el entorno de host para permitir diseños más eficientes en costos. La propuesta y la discusión están registradas en las discusiones de GitHub stellar-core#1447
2. Tommaso recibió comentarios sobre la propuesta así como sobre la implementación. Como no requería un cambio de medición, los desarrolladores centrales pensaron que sería un cambio rápido.
3. El ecosistema votó a favor de la propuesta al votar a favor del post en las Discusiones de GitHub. Se registraron 13 votos grabados.
4. Como próximos pasos, se redactará un CAP para capturar la propuesta y presentarla para su aprobación por parte del Equipo Central de CAP.

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.

Hilo de agenda de Discord

1. La necesidad de curvas de cifrado que habilitan zk como BLS12-381. Hilo de Github.
2. Los casos de uso en los que el ecosistema está interesado:
   1. Excellar, es decir, personas que iniciaron esta conversación al enviar un PR para BLS12-381, quiere añadir un oráculo controlado por DAO donde la curva elíptica proporciona la capacidad de añadir nuevos votantes de DAO
   2. Zkbricks quiere crear un sistema L2 que habilite el estado secreto para contratos inteligentes arbitrarios
   3. Skyhitz quiere utilizar Stellar para computación eficiente, costo y escalabilidad mientras usa zk para probar la propiedad de activos de alto valor en otra cadena
   4. La enumeración de casos de uso continúa en el hilo de discord.
3. Consideraciones para la implementación de funciones de host
   1. Los desarrolladores principales cuestionaron si BLS12-381 era la curva correcta y también destacaron la necesidad de determinar el nivel adecuado de abstracción dado que hay un compromiso entre flexibilidad y eficiencia. Un nivel inferior de abstracción permitirá más flexibilidad pero resultará en más bucles activos en el wasm, mientras que un nivel más alto de abstracción será altamente eficiente pero restringirá la generalidad.
   2. ZkBricks pensó que hay una necesidad de exponer directamente combinaciones y operaciones de grupo sin ningún nivel de abstracción. El espacio está en desarrollo activo y se necesita flexibilidad para probar nuevos enfoques y sistemas de prueba. Desde el punto de vista de la agilidad criptográfica, sería bueno exponer una interfaz genérica que admita una variedad de curvas en el backend.
4. Ruta a seguir
   1. Los desarrolladores principales mencionaron que las curvas criptográficas pueden ser experimentadas localmente al vincular crates de Rust, lo cual, resulta que fallaron en el pasado. Esto será explorado y corregido.
   2. ZkBricks y otros prototiparán localmente y proporcionarán retroalimentación.
5. Cuáles son las prácticas recomendadas para gestionar transacciones en el frontend, con respecto al orden de transacciones.
6. Los desarrolladores principales confirmaron que el orden es intencionalmente arbitrario.
7. Solicitud de una API para la versión actual del entorno/sdk
8. Problema de Github presentado para que el RPC devuelva versiones del nodo actual.