Hilo de agenda de Discord

1. Herramienta Sorobill
2. Desplegar contratos y probar invocaciones contra el quickstart ilimitado.
3. Utilizando el paquete Sorobil como una herramienta para obtener una imagen de todos los límites que el contrato está tocando. Publicación de blog relevante
4. Cómo medir los costos del contrato y qué límites estás tocando
5. Utilizando la herramienta Sorobil para decodificar XDR y entender las transacciones fallidas.

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

Hilo de la agenda de Discord

1. Lo último y lo mejor sobre las vinculaciones de TypeScript con @chadoh
2. Proveedores RPC disponibles
3. Configurar un contenedor Docker stellar-rpc
4. Instalar e invocar un contrato de activo Stellar en mainnet en la Fase 0

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

Hilo de agenda de Discord

1. Presentación en borrador de la Lista de Activos Stellar (SEP-0042) por OrbitLens
   1. Borrador de SEP
   2. Discusión en Discord
2. Encuesta sobre la documentación de Stellar + Soroban
   1. Realiza la encuesta

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. Planificar y programar estas reuniones
   1. Reuniones de protocolo cada dos jueves a las 4pm ET
   2. Reuniones de desarrollador cada dos viernes a la 1pm ET
   3. Continuaremos ajustando según sea necesario
2. Error de ajuste de tarifas - anuncio | hilo de discusión
   1. Error de patrocinio de tarifas: la tarifa no utilizada se reembolsa a la fuente de transacción interna en lugar de a la fuente del patrocinador.
   2. Corregir en nueva versión. Depende del ecosistema y de los validadores actualizar. La corrección probablemente se implementará antes de la Fase 2.
   3. Depende de los validadores decidir si quieren posponer la fecha de actualización v20 para esperar la corrección; o actualizar con la versión actual.
3. Deprecación de TxMeta en Horizon - anuncio
4. Ideas sobre pruebas contra imágenes de ledger - solicitud
   1. Definir las necesidades un poco más claramente
   2. Definitivamente hay algo aquí que deberíamos abordar para facilitar las pruebas contra el estado del ledger específico
5. ¿Cómo obtienes una lista de contratos inteligentes? - hilo
   1. Observar operaciones de creación de contratos a medida que los ledgers se cierran
   2. Usar un servicio de indexación
6. ¿Cuál es el estado del soporte de caché de contratos? - pregunta
   1. respuesta

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.