4 publicaciones etiquetadas con "protocolo"

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.

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.

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