Agenda: Discord thread

En la reunión de desarrolladores de esta semana, Jeesun demostró el nuevo Stellar Lab, mostrando sus características mejoradas diseñadas para mejorar la experiencia del desarrollador.

Se discutió la pila tecnológica del nuevo Stellar Lab en la reunión, y se utilizaron las siguientes demostraciones para mostrar la funcionalidad del Lab:

1. Activar el ejercicio MultiSig
2. Stellar Wallets Kit
3. Crear y financiar cuenta
4. Se discutió la pila tecnológica del nuevo Stellar Lab en la reunión, y se utilizaron las siguientes demostraciones para mostrar la funcionalidad del Lab:
5. Guardar función de transacciones
6. Mapeo de XDR a JSON
7. Métodos RPC - incluyendo simulateTransaction

Agenda: Discord thread

El equipo de Plataforma de SDF tuvo un hackathon interno la semana pasada, con el propósito de crear aplicaciones que utilizan la Composable Data Platform (CDP). En la reunión de desarrolladores de esta semana, algunos de los miembros del equipo presentan sus proyectos. Las aplicaciones son muy variadas (aplicación de comercio, detección de fraudes, ingestor basado en navegador JS, etc.), pero la intención aquí es mostrar lo fácil que es usar CDP.

Proyectos presentados en la reunión:

1. Servicio de Agregaciones de Comercio
2. Deceptiscan - detección de fraudes CDP
3. Hackies de Composable Data Platform - indexador de datos, indexador de pagos, alerta de caducidad de contratos, índices de datos en DuckDB, torrents para índices de datos y metadatos de ledger)
4. Ingesta de datos con JS frontend
5. Analíticas en tiempo real

Agenda: Discord thread

Resumen: Hoops Finance, un protocolo DeFi, discutió su plataforma que están desarrollando. https://www.hoops.finance/

1. Abstractan la complejidad de las inversiones DeFi para usuarios normales a través de una serie de indicaciones guiadas.
2. Proporciona acceso simplificado a la abstracción de provisión de liquidez LP
3. API AMM pública para leer/escribir datos en AMMs en Stellar
4. API de Hoops Finance: https://api.v1.xlm.services/#overview

Agenda: hilo de Discord

El miembro del equipo de DevRel de SDF, Carsten Jacobsen, mostró cómo crear una simple dapp Hello World basada en un contrato inteligente Soroban y Next.js a través de estos pasos:

1. Crear el contrato inteligente Hello World predeterminado usando el Stellar CLI
2. Crear enlaces de TypeScript (paquete) usando el Stellar CLI
3. Crear el Next.js predeterminado usando el comando npx create-next-app
4. Agregar y enlazar el paquete de enlace de TypeScript al proyecto Next.js
5. Crear un frontend simple con un formulario para enviar una cadena
6. Importar el paquete en la página de Next.js y configurar un cliente
7. Crear la función de envío para enviar el valor del formulario al contrato inteligente
8. Usar useState para almacenar la respuesta del contrato inteligente y mostrarla

Agenda: Hilo de Discord

El miembro del equipo de Experiencia del Desarrollador, Nando Vieira, presentó las características alias y snapshot del CLI:

1. Alias
   1. Instalación del ejemplo Hello World para mostrar el alias
   2. Se mostraron ejemplos de cómo los IDs de contrato a menudo se pasan como parámetros en comandos del CLI como invoke (copiando la cadena ID o sustitución de comando)
   3. Cómo desplegar un contrato inteligente y crear un alias
   4. Cómo invocar el contrato inteligente con el alias
2. Snapshot
   1. Cómo crear una imagen del ledger
   2. Cómo usar la imagen en un caso de prueba

Hacia el final, Nando revisó la documentación para desarrolladores, centrándose en los ejemplos de línea de comandos añadidos para usuarios de Windows y un útil recetario para comandos del CLI.

Agenda: Discord thread

El equipo de la plataforma demostró Galexie, una parte de CDP (Composable Data Platform):

1. Galexie
   1. Extracción de Datos: Extrae datos brutos del ledger de la red Stellar
   2. Compresión: Comprime los datos brutos para un almacenamiento eficiente
   3. Opciones de Almacenamiento: Admite la configuración en tiempo de ejecución a través de la abstracción del Datastore para utilizar varias capas de almacenamiento físico, comenzando con Google Cloud Storage (GCS)
   4. Modos de Operación: Puede operar en modo por lotes o en modo de transmisión
2. Plataforma de Datos Componible
   1. Datastore Flexible: Múltiples opciones para capas de almacenamiento de datos físicas
   2. Galexie: Se utiliza para extraer, comprimir y exportar datos a tu Datastore elegido
   3. Transformar: Estructura los datos en un modelo adecuado para tu aplicación
3. Canalizaciones de Datos Plugables
   1. Flujos de Trabajo: Crea canalizaciones ETL (extraer, transformar, cargar)
   2. Transmisión: Datos de transmisión rápidos y livianos

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.

1. @Soiled y @Robeart de Orbit hablaron sobre usar Blend para crear stablecoins descentralizadas para todas las monedas bajo el Protocolo Orbit, utilizando un pegkeeper descentralizado para mantener su precio y aprovechando estas stablecoins y billeteras inteligentes para crear un exchange perpetuo sin libro de órdenes, llevando Forex a Stellar

2.Enlace a la presentación

Nota: El audio del micrófono del host no está en el video, por lo que hay algo de silencio durante la sesión de preguntas y respuestas. Aquí están las preguntas realizadas durante la sesión de preguntas y respuestas:

1. (De ! markus_0) ¿por qué siempre tienes una cantidad infinita de tokens en el pool? ¿No sería más seguro empezar pequeño y acuñar más a medida que se abra la demanda? 2.(De HunterIonize) ¿Qué propósito sirve esto exactamente? Lo siento por ser directo
2. ¿Cómo ves al Protocolo Orbit contribuyendo a la inclusión financiera a nivel global, particularmente en regiones sub-bancarizadas? ¿Qué desafíos anticipas para lograr esto?
3. En 5-10 años, ¿cómo ves que evolucione el panorama de Forex en blockchain? ¿Qué papel crees que jugará Stellar en esta evolución, y cómo estarán Blend y el Protocolo Orbit a la vanguardia?
4. ¿Hay alguna solicitud de la comunidad de desarrolladores?

1. Tdep discutió sobre Zephyr, un entorno de ejecución desarrollada sobre el indexador Mercury. También explicó ejemplos que demuestran cómo Zephyr puede simplificar el desarrollo de dapps.

1. Piyal demostró que la funcionalidad de intercambio de Freighter ahora se sirve a través de Soroswap. Anteriormente, se servía a través de Stellar Dex.
2. Freighter ha hecho disponibles las instrucciones de integración aquí.
3. Esteban compartió que Palta Labs ha creado un agregado de DEX y lo ha hecho disponible para todos a través del Router SDK.
4. El Router SDK encuentra la ruta óptima para el intercambio en términos de costo de intercambio a través de todos los DEX en Soroban.

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

Nota: la primera parte de la llamada se perdió. El video publicado arriba captura la segunda mitad de la llamada donde varios desarrolladores del ecosistema compartieron sus casos de uso y necesidades para una billetera inteligente en Stellar.

1. Tyler propuso una propuesta para una billetera inteligente como un bien público. Dado que la autenticación nativa puede sobrecargarse al usar __check_auth, la implementación de Stellar de una billetera inteligente es bastante sencilla. La capacidad de personalizar la autenticación ya está desarrollada en el protocolo central.
2. Consulta la propuesta aquí y la implementación aquí
3. La propuesta solo utiliza firmantes basados en WebAuthN, es decir, claves de acceso. No utiliza ed25519, que, quizás debería dado que ~100 % de las cuentas en Stellar utilizan ese esquema. También introduce la noción de firmantes temporales y administradores para ilustrar que la cuenta puede ser gestionada por múltiples firmantes, cada uno con una política de acceso diferente.
4. El mayor desbloqueo con la autenticación personalizada es la capacidad de ejecutar lógica personalizada. Escuchamos de varios miembros del ecosistema sobre cómo podrían usarlo. 4a. Un desarrollador está construyendo un protocolo perpetuo y pensó que las billeteras inteligentes podrían usarse para gestionar automáticamente posiciones de defi, lo que sería una mejora significativa sobre el statu quo donde el usuario tiene que rastrear constantemente los activos para determinar cuándo ejecutar un intercambio. 4b. La gente está entusiasmada por prescindir de la frase semilla para las claves de acceso, lo cual es especialmente significativo al integrar nuevos usuarios a la blockchain. 4c. Autorizar un mensaje entre cadenas desde una cadena diferente, especialmente autorización programática, requiere una implementación de cuentas personalizadas. 4d. Algunas aplicaciones han notado que los usuarios prefieren no tener una billetera, sino simplemente experimentar el valor de la aplicación, especialmente los juegos. Para esto, la aplicación puede asignar una cuenta temporal al usuario y controlar el acceso a través de check_auth. 4c. Las microtransacciones sin necesidad de firma de usuario son también muy interesantes para las aplicaciones.
5. Esta ha sido una reunión muy reveladora y aprendimos sobre cómo el ecosistema Stellar planea aprovechar la billetera inteligente. ¡Continuemos la conversación en Discord!

1. 2. Las diapositivas están disponibles públicamente y son legibles de forma asíncrona.
2. 4. Comparte tus consultas y publica preguntas en #hubble en discord de Stellar, que es un canal dedicado a temas relacionados con datos.
3. Los consejos para el análisis de datos también se cubren en la documentación
4. Comparte tus consultas y publica preguntas en #hubble en el Discord de Stellar, que es un canal dedicado a temas relacionados con datos.

1. Chad y Willem de Aha Labs discuten las actualizaciones del nuevo y mejorado stellar-cli
2. Algunos aspectos destacados incluyen el cambio del nombre 'soroban' a 'stellar' al usar la herramienta CLI y la adición de nuevos comandos.
3. They cover some cool functions like local network setup, account creation, and transaction signing. con los siguientes comandos:
   • stellar network container [start|logs]
   • stellar keys [generate|fund|ls]
   • stellar contract init para obtener un nuevo proyecto de Soroban
   • ¡y mucho más!
4. They also discuss expected future updates including support for more Stellar operations and integration with Stellar Lab V2!

1. Kirckz discute Meru, una aplicación de servicios financieros para freelancers y trabajadores remotos en América Latina.
2. Él comparte su experiencia integrando Meru con Blend, un protocolo de liquidez primitiva para Stellar.
3. Kirckz comparte los desafíos enfrentados durante la integración y cómo fueron superados.
4. Él comparte los sdks y bibliotecas que su equipo utilizó para facilitar la integración.

Sigue a Meru en X (anteriormente Twitter) para mantenerte actualizado: https://x.com/getmeru

1. Tyler creó Super Peach, una aplicación web3 que utiliza claves de acceso para firmar transacciones. Demostró cómo se pueden usar las claves de acceso en flujos de autorización y cómo se pueden usar para firmar transacciones.
   • Código: https://github.com/kalepail/superpeach
   • Demostración: https://superpeach.vercel.app
2. Se presentó passkey-kit. Un SDK de TypeScript para crear y gestionar billeteras inteligentes a través de claves de acceso (incluye la interfaz de billetera inteligente)
   • Código: https://github.com/kalepail/passkey-kit
   • Demostración: https://passkey-kit-demo.pages.dev
3. Se presentó Launchtube, un servicio para enviar transacciones en cadena cubriendo tanto la tarifa de transacción COMO el número de secuencia. ¡Increíble!
   • Código: https://github.com/kalepail/launchtube (pregunta en el canal #passkeys en Discord por un token de testnet)
4. Compartió su visión para impulsar la implementación de las claves de acceso hasta convertirse en un estándar para el ecosistema.

Únete al canal #passkeys en Discord para continuar la discusión

1. Tyler desarrolló una aplicación de votación utilizando claves de acceso para firmar la transacción, que es una implementación de la función de verificación secp256r1.
2. Mostró una implementación multiplataforma (web y móvil) y demostró que las claves de acceso son la interfaz perfecta entre los contratos web3 y los mecanismos de autenticación web2 a los que la mayoría de los usuarios finales están acostumbrados.
3. Los miembros del ecosistema discutieron el uso de billeteras inteligentes que utilizarían claves de acceso como firmantes. Se identificaron desafíos en torno a las tarifas requeridas para las billeteras inteligentes, la necesidad de una implementación común para una billetera inteligente, así como cómo podría interactuar con los administradores de contraseñas existentes.
4. La aplicación de votación se puede probar en passkey.sorobanbyexample.org/
5. El código para la demo está aquí github.com/kalepail/soroban-passkey

Hilo de Agenda de Discord

1. Fifo presentó Stellar Plus, que es una biblioteca de Javascript para simplificar el desarrollo de Stellar y Soroban.
2. Los miembros del ecosistema encontraron el diseño de Stellar Plus como composable e inclusivo de toda la funcionalidad relacionada con Stellar, incluyendo la gestión de activos, cuentas, operaciones relacionadas con wasm, así como utilidades RPC.
3. Los enlaces a la presentación de Fifo y Stellar Plus son:
   • Tablero de Miro mostrando la arquitectura de Stellar Plus
   • Repositorio de Stellar Plus
   • Repositorio de Ejemplos
   • Documentos

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.

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

Hilo de la agenda de Discord

1. Lo último y lo mejor sobre las vinculaciones de TypeScript con @chadoh
2. Proveedores RPC disponibles
3. Implementar un contenedor de 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.