Discord agenda thread

1. Justin de ortege.ai hizo una demostración de Ortege, una plataforma de análisis de datos para Stellar y Soroban.
2. Ortege permite que cualquier persona en el ecosistema Stellar cree paneles de control para rastrear cualquier métrica deseada. Las consultas, widgets y paneles de control de Ortege son compartibles, lo que lo convierte en la plataforma perfecta para mostrar
3. Justin lanzará pronto una IA y habilitará la consulta y los conocimientos a través del lenguaje natural.
4. Todos están invitados a crear una cuenta gratuita y rastrear las métricas de éxito para su panel de control.

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.

La grabación de hoy tiene dos partes. Los primeros 12 minutos son solo audio. Los próximos 45 minutos también tienen video. Ten en cuenta que las diapositivas se compartieron en el chat de discord mediante la pantalla compartida, debido a dificultades técnicas.

Parte 1 (solo audio):

Parte 2 (video):

Hilo de Agenda de Discord

1. Piyal propuso un Estándar de Billetera y solicitó retroalimentación.
2. Cubist, un proyecto del ecosistema, discutió CubeSigner, una API de baja latencia para generar claves y firmar transacciones dentro de hardware seguro.
3. Un ejemplo de CubeSigner basado en Stellar está disponible en el repositorio de Cubist Labs en Github
4. Los desarrolladores de Cubist pueden ser contactados a través del discord de Stellar o del formulario web.

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.

Hilo de agenda de Discord

1. Hay una discusión sobre un cambio de meta TX que aumenta la visibilidad y los análisis dentro de la red Stellar. (https://github.com/stellar/stellar-xdr/pull/175)
2. Se explica que las invocaciones de solo lectura para contratos garantizan que ciertas funciones sigan siendo de solo lectura sin efectos secundarios. (https://github.com/stellar/stellar-protocol/discussions/1454) (https://github.com/stellar/stellar-protocol/discussions/1456) (https://github.com/stellar/stellar-protocol/discussions/1464)
3. Se introduce la habilitación del descubrimiento de contratos para mejorar la visibilidad y autenticidad de los contratos inteligentes dentro del ecosistema Stellar.
4. Se propone la implementación de un esquema de metadatos estándar de contrato para vincular contratos con código fuente y mejorar la capacidad de descubrimiento de contratos.(https://docs.rs/soroban-sdk/latest/soroban_sdk/macro.contractmeta.html)
5. Las incidencias relacionadas con las tarifas de inclusión en la red Stellar destacan la importancia de monitorear las tarifas de cerca y comprender las implicaciones de los precios de aumento. (https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#inclusion-fee)
6. Se discuten planes para diseñar un nuevo punto final RPC que brinde a los desarrolladores mejor visibilidad e información sobre el establecimiento de tarifas de inclusión, con el objetivo de mejorar la transparencia y la toma de decisiones respecto a las compensaciones de tarifas.

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