Traducción y revisión: "Comunidad china de StarkNet"
Resumen
Las funciones integradas optimizan el proceso de prueba. Sin embargo, cada prueba se calcula a partir del diseño. Para ciertos trabajos de prueba, las ventajas de las funciones integradas se reducirán considerablemente si el diseño es ineficiente. Actualmente, hay una pequeña lista estática de diseños y cada prueba se calcula en función del diseño más apropiado de esa lista. Esta forma de diseñar listas estáticas tiene dos inconvenientes. Primero, hay una variedad limitada de diseños. Esto es ineficiente para la mayoría de los trabajos de prueba y crea complejos mecanismos de tarifas que imponen costos innecesarios a los usuarios. En segundo lugar, es difícil mantener la lista manualmente. Una vez que la cantidad de elementos integrados es demasiado alta, el mantenimiento manual se vuelve difícil y, de hecho, puede obstaculizar el proceso de probar elementos integrados eficientes que admitan una gran cantidad de matices. Para abordar estos problemas, el equipo de StarkWare está desarrollando un sistema de diseño dinámico en el que los diseños se hacen a medida para cada prueba de trabajo.
La pila de Cairo facilita la computación de propósito general demostrable al compilar el código de Cairo en instrucciones para arquitecturas de CPU compatibles con STARK: la VM de Cairo (en lo sucesivo, CVM). Muchas de las ventajas de las CPU de propósito general tienen un costo inherente y CVM no está optimizado para algunas operaciones comunes. Las funciones hash de Keccak, Pedersen, Poseidon son operaciones comunes, al igual que las operaciones de curva elíptica, la verificación de rango (es decir, verificar si un número particular está dentro de un rango particular de valores) y otras.
Para abordar la ineficiencia relativa de los CVM, la pila de Cairo presenta el concepto de componentes integrados para operaciones críticas: complementos que optimizan dichas operaciones para demostrar la complejidad. Las funciones integradas se pueden comparar con los ASIC: los ASIC son circuitos integrados específicos de la aplicación y las funciones integradas son restricciones algebraicas específicas de la aplicación (AIR). Si no sabe o no recuerda qué es AIR, se trata brevemente más adelante en este artículo; lea este artículo para obtener más detalles.
En resumen, la complejidad de la prueba está relacionada (más o menos lineal) con los recursos llamados unidades de rastreo, y las funciones integradas simplifican las pruebas de operaciones específicas al usar muchas menos unidades de rastreo que Cairo VM.
Ahora que se han explicado los beneficios de las funciones integradas, queda claro por qué se desarrollaron funciones integradas para muchas operaciones comunes. Esto es más fácil dicho que hecho. El proceso actual de introducción de nuevos integrados en Starknet consta de los siguientes pasos:
Escribiendo AIRE
Integre con el probador creando un nuevo diseño (descrito a continuación)
Integre en Starknet, es decir, modifique su base de código y herramientas de desarrollo para usar nuevas funciones integradas
Además de los desafíos de escribir AIR, hay mucho margen de mejora en las dos fases restantes. Este artículo avanzado describirá con más detalle las funciones integradas de AIR como aplicaciones específicas, los problemas anteriores y los planes futuros.
Funciones integradas: AIR específico de la aplicación
AIR es un acrónimo de Representación Intermedia Algebraica. En este y otros artículos de StarkWare, AIR es un sistema polinomial para representar máquinas virtuales. Por ejemplo, Cairo toma su nombre de CPU AIR: un sistema polinomial que representa una arquitectura de CPU específica. Las soluciones de este sistema polinomial representan transiciones de estado eficientes, denominadas trayectorias de ejecución algebraica eficiente (AET).
STARK demuestra que el funcionamiento de la máquina virtual es correcto demostrando que la trayectoria de ejecución correspondiente a un AIR dado es válida. En términos generales, una trayectoria de ejecución es una tabla de números, y el protocolo STARK demuestra que estos números juntos resuelven un sistema polinomial.
La misma operación se puede calcular de muchas maneras, algunas de las cuales son más eficientes. En este documento, la complejidad de la prueba depende básicamente del tamaño de la pista, es decir, el número de celdas de pista en la tabla. Debido a que los seguimientos se generan para AIR, AIR está diseñado para que las aplicaciones reduzcan significativamente los seguimientos de ejecución para cálculos específicos. Las funciones integradas son AIR especializadas optimizadas para la aplicación.
La siguiente tabla muestra las mejoras de eficiencia para funciones integradas específicas (todas en producción).
Trazado de trayectoria: presente y futuro
Como se mencionó anteriormente, AET es aproximadamente una tabla de números que representa la secuencia de pasos en la máquina virtual codificada (es decir, la ejecución del programa). Para calcular la prueba, el probador ejecuta el protocolo STARK en la pista de ejecución del AIR asociado.
Anteriormente, introdujimos funciones integradas como AIR específico de la aplicación diseñado para minimizar la complejidad de las pruebas al reducir la cantidad de unidades de rastreo requeridas para codificar los cálculos. Sin embargo, si las funciones integradas se integran aleatoriamente en Starknet, se pueden desperdiciar muchas unidades de trayectoria y se reducirán los beneficios esperados. Vamos a explicar en detalle a continuación.
En resumen, el diseño de vías es la asignación de celdas de vías a diferentes "componentes". En este artículo, estos componentes son el CVM y las funciones integradas. Específicamente, el diseño especifica el número relativo de celdas de seguimiento que obtiene cada componente. (Las construcciones de diseño siempre se usan para simplificar la validación. Para obtener más información, lea la sección "Simplicidad" de esta publicación).
El punto clave es que la complejidad de la prueba depende del número total de celdas de seguimiento asignadas por el diseño, y la asignación de celdas de seguimiento puede ser mayor de lo que realmente se necesita. Por ejemplo, para demostrar el orden de los pasos de los CVM, un diseño que asigna solo celdas de rastreo a los componentes de CVM es aproximadamente el doble de eficiente que un diseño que asigna la mitad de las celdas de rastreo a las funciones integradas de Poseidon. En conclusión, un diseño adecuado puede reducir en gran medida la complejidad de probar un cálculo en particular.
Actualmente hay una lista de diseños mantenida manualmente que crece con el tiempo por dos razones principales:
Las funciones integradas solo se pueden usar para el diseño de la unidad de vía asignada a ellas. Por lo tanto, agregar elementos integrados requiere al menos un nuevo diseño.
Un diseño diseñado para ejecutar el código Cairo optimiza la asignación de celdas. Por lo tanto, la optimización de casos de uso en celdas a menudo requiere nuevos diseños.
El código para el probador y el validador (validadores Solidity y Cairo) se configura de acuerdo con la lista de diseño.
A medida que se agregaron los elementos integrados de Keccak y Poseidón, se volvió cada vez más difícil mantener las listas de diseño lo suficientemente pequeñas como para acomodar muchos elementos integrados y mantener la ejecución eficiente de la mayoría de los bloques de Starknet. Además, se espera que la eficiencia disminuya significativamente a medida que se introduzcan elementos integrados adicionales, ya que el diseño debe tener en cuenta las muchas combinaciones y proporciones posibles entre los elementos integrados.
El equipo de StarkWare está trabajando actualmente para mejorar el sistema abandonando las listas de diseño prefabricadas en favor de "diseños dinámicos", que son personalizaciones instantáneas para cada ejecución del código de Cairo. Dynamic Layout siempre hará la asignación mejor proporcionada para el trabajo de verificación en cuestión. Desde el punto de vista de la ingeniería, admitir la tipificación dinámica requeriría cambios considerables en el código base. Sin embargo, el equipo de StarkWare espera simplificar la capa de prueba de Starknet aprovechando el diseño dinámico, la utilización mejorada de la unidad de pista y la mejor utilización de los probadores.
Con diseños dinámicos, desaparece la molestia de mantener manualmente muchos elementos integrados, lo que simplifica el proceso de integración de más elementos integrados nuevos en Starknet.
Diseño dinámico y tarifas
Uno de los propósitos de las tarifas de transacción es cobrar a los usuarios el costo marginal del protocolo incurrido por las transacciones. Dado que la unidad de las tarifas de transacción es la moneda, el mecanismo de tarifas implica la conversión de recursos (p. ej., pasos de máquinas virtuales, funciones integradas, datos de llamadas, gas Ethereum) a tokens (p. ej., STRK, ETH).
Actualmente, debido a que los probadores cobran tarifas en función de los rastros totales en lugar de los índices de utilización, los recursos desperdiciados corren a cargo de los usuarios. El diseño dinámico mejorará la utilización de la unidad de vía, reduciendo así el cobro de tarifas de transacción "innecesarias" (incluido el consumo de recursos no causado directamente por las transacciones del usuario).
Integración de funciones incorporadas de Starknet
En este punto, la integración de las funciones integradas no llega al último paso, que consiste en modificar el código base de Starknet para lograr un uso práctico. El alcance de la modificación del código está relacionado con la aplicación de diseño, y es necesario modificar el código para garantizar que el sistema operativo Starknet llame a las funciones integradas cuando sea posible. Por ejemplo, el sistema operativo Starknet llama a la función hash de Poseidón durante la ejecución del código Cairo y, al mismo tiempo, llama a la función integrada de Poseidón.
De manera similar a los diseños, las funciones integradas de Starknet ahora se pueden admitir manualmente. Sin embargo, a diferencia del caso de diseño, este soporte manual no es una barrera para la integración a pesar de que hay muchas funciones integradas. En otras palabras, la compatibilidad con las funciones integradas de Starknet no es una barrera para la integración, el diseño dinámico realmente allanará el camino para crear e integrar funciones adicionales.
Resumir
En este artículo explicamos qué son las funciones integradas, sus beneficios, los desafíos que implican y los planes de StarkWare. El enfoque actual está en el diseño dinámico, que no solo mejorará la eficiencia del proceso de prueba, sino que también facilitará la integración de nuevos elementos integrados.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Beneficios y desafíos de las funciones integradas de Starknet
Original: diseños integrados y dinámicos
Traducción y revisión: "Comunidad china de StarkNet"
Resumen
Las funciones integradas optimizan el proceso de prueba. Sin embargo, cada prueba se calcula a partir del diseño. Para ciertos trabajos de prueba, las ventajas de las funciones integradas se reducirán considerablemente si el diseño es ineficiente. Actualmente, hay una pequeña lista estática de diseños y cada prueba se calcula en función del diseño más apropiado de esa lista. Esta forma de diseñar listas estáticas tiene dos inconvenientes. Primero, hay una variedad limitada de diseños. Esto es ineficiente para la mayoría de los trabajos de prueba y crea complejos mecanismos de tarifas que imponen costos innecesarios a los usuarios. En segundo lugar, es difícil mantener la lista manualmente. Una vez que la cantidad de elementos integrados es demasiado alta, el mantenimiento manual se vuelve difícil y, de hecho, puede obstaculizar el proceso de probar elementos integrados eficientes que admitan una gran cantidad de matices. Para abordar estos problemas, el equipo de StarkWare está desarrollando un sistema de diseño dinámico en el que los diseños se hacen a medida para cada prueba de trabajo.
La pila de Cairo facilita la computación de propósito general demostrable al compilar el código de Cairo en instrucciones para arquitecturas de CPU compatibles con STARK: la VM de Cairo (en lo sucesivo, CVM). Muchas de las ventajas de las CPU de propósito general tienen un costo inherente y CVM no está optimizado para algunas operaciones comunes. Las funciones hash de Keccak, Pedersen, Poseidon son operaciones comunes, al igual que las operaciones de curva elíptica, la verificación de rango (es decir, verificar si un número particular está dentro de un rango particular de valores) y otras.
Para abordar la ineficiencia relativa de los CVM, la pila de Cairo presenta el concepto de componentes integrados para operaciones críticas: complementos que optimizan dichas operaciones para demostrar la complejidad. Las funciones integradas se pueden comparar con los ASIC: los ASIC son circuitos integrados específicos de la aplicación y las funciones integradas son restricciones algebraicas específicas de la aplicación (AIR). Si no sabe o no recuerda qué es AIR, se trata brevemente más adelante en este artículo; lea este artículo para obtener más detalles.
En resumen, la complejidad de la prueba está relacionada (más o menos lineal) con los recursos llamados unidades de rastreo, y las funciones integradas simplifican las pruebas de operaciones específicas al usar muchas menos unidades de rastreo que Cairo VM.
Ahora que se han explicado los beneficios de las funciones integradas, queda claro por qué se desarrollaron funciones integradas para muchas operaciones comunes. Esto es más fácil dicho que hecho. El proceso actual de introducción de nuevos integrados en Starknet consta de los siguientes pasos:
Escribiendo AIRE
Integre con el probador creando un nuevo diseño (descrito a continuación)
Integre en Starknet, es decir, modifique su base de código y herramientas de desarrollo para usar nuevas funciones integradas
Además de los desafíos de escribir AIR, hay mucho margen de mejora en las dos fases restantes. Este artículo avanzado describirá con más detalle las funciones integradas de AIR como aplicaciones específicas, los problemas anteriores y los planes futuros.
Funciones integradas: AIR específico de la aplicación
AIR es un acrónimo de Representación Intermedia Algebraica. En este y otros artículos de StarkWare, AIR es un sistema polinomial para representar máquinas virtuales. Por ejemplo, Cairo toma su nombre de CPU AIR: un sistema polinomial que representa una arquitectura de CPU específica. Las soluciones de este sistema polinomial representan transiciones de estado eficientes, denominadas trayectorias de ejecución algebraica eficiente (AET).
STARK demuestra que el funcionamiento de la máquina virtual es correcto demostrando que la trayectoria de ejecución correspondiente a un AIR dado es válida. En términos generales, una trayectoria de ejecución es una tabla de números, y el protocolo STARK demuestra que estos números juntos resuelven un sistema polinomial.
La misma operación se puede calcular de muchas maneras, algunas de las cuales son más eficientes. En este documento, la complejidad de la prueba depende básicamente del tamaño de la pista, es decir, el número de celdas de pista en la tabla. Debido a que los seguimientos se generan para AIR, AIR está diseñado para que las aplicaciones reduzcan significativamente los seguimientos de ejecución para cálculos específicos. Las funciones integradas son AIR especializadas optimizadas para la aplicación.
La siguiente tabla muestra las mejoras de eficiencia para funciones integradas específicas (todas en producción).
Trazado de trayectoria: presente y futuro
Como se mencionó anteriormente, AET es aproximadamente una tabla de números que representa la secuencia de pasos en la máquina virtual codificada (es decir, la ejecución del programa). Para calcular la prueba, el probador ejecuta el protocolo STARK en la pista de ejecución del AIR asociado.
Anteriormente, introdujimos funciones integradas como AIR específico de la aplicación diseñado para minimizar la complejidad de las pruebas al reducir la cantidad de unidades de rastreo requeridas para codificar los cálculos. Sin embargo, si las funciones integradas se integran aleatoriamente en Starknet, se pueden desperdiciar muchas unidades de trayectoria y se reducirán los beneficios esperados. Vamos a explicar en detalle a continuación.
En resumen, el diseño de vías es la asignación de celdas de vías a diferentes "componentes". En este artículo, estos componentes son el CVM y las funciones integradas. Específicamente, el diseño especifica el número relativo de celdas de seguimiento que obtiene cada componente. (Las construcciones de diseño siempre se usan para simplificar la validación. Para obtener más información, lea la sección "Simplicidad" de esta publicación).
El punto clave es que la complejidad de la prueba depende del número total de celdas de seguimiento asignadas por el diseño, y la asignación de celdas de seguimiento puede ser mayor de lo que realmente se necesita. Por ejemplo, para demostrar el orden de los pasos de los CVM, un diseño que asigna solo celdas de rastreo a los componentes de CVM es aproximadamente el doble de eficiente que un diseño que asigna la mitad de las celdas de rastreo a las funciones integradas de Poseidon. En conclusión, un diseño adecuado puede reducir en gran medida la complejidad de probar un cálculo en particular.
Actualmente hay una lista de diseños mantenida manualmente que crece con el tiempo por dos razones principales:
Las funciones integradas solo se pueden usar para el diseño de la unidad de vía asignada a ellas. Por lo tanto, agregar elementos integrados requiere al menos un nuevo diseño.
Un diseño diseñado para ejecutar el código Cairo optimiza la asignación de celdas. Por lo tanto, la optimización de casos de uso en celdas a menudo requiere nuevos diseños.
El código para el probador y el validador (validadores Solidity y Cairo) se configura de acuerdo con la lista de diseño.
A medida que se agregaron los elementos integrados de Keccak y Poseidón, se volvió cada vez más difícil mantener las listas de diseño lo suficientemente pequeñas como para acomodar muchos elementos integrados y mantener la ejecución eficiente de la mayoría de los bloques de Starknet. Además, se espera que la eficiencia disminuya significativamente a medida que se introduzcan elementos integrados adicionales, ya que el diseño debe tener en cuenta las muchas combinaciones y proporciones posibles entre los elementos integrados.
El equipo de StarkWare está trabajando actualmente para mejorar el sistema abandonando las listas de diseño prefabricadas en favor de "diseños dinámicos", que son personalizaciones instantáneas para cada ejecución del código de Cairo. Dynamic Layout siempre hará la asignación mejor proporcionada para el trabajo de verificación en cuestión. Desde el punto de vista de la ingeniería, admitir la tipificación dinámica requeriría cambios considerables en el código base. Sin embargo, el equipo de StarkWare espera simplificar la capa de prueba de Starknet aprovechando el diseño dinámico, la utilización mejorada de la unidad de pista y la mejor utilización de los probadores.
Con diseños dinámicos, desaparece la molestia de mantener manualmente muchos elementos integrados, lo que simplifica el proceso de integración de más elementos integrados nuevos en Starknet.
Diseño dinámico y tarifas
Uno de los propósitos de las tarifas de transacción es cobrar a los usuarios el costo marginal del protocolo incurrido por las transacciones. Dado que la unidad de las tarifas de transacción es la moneda, el mecanismo de tarifas implica la conversión de recursos (p. ej., pasos de máquinas virtuales, funciones integradas, datos de llamadas, gas Ethereum) a tokens (p. ej., STRK, ETH).
Actualmente, debido a que los probadores cobran tarifas en función de los rastros totales en lugar de los índices de utilización, los recursos desperdiciados corren a cargo de los usuarios. El diseño dinámico mejorará la utilización de la unidad de vía, reduciendo así el cobro de tarifas de transacción "innecesarias" (incluido el consumo de recursos no causado directamente por las transacciones del usuario).
Integración de funciones incorporadas de Starknet
En este punto, la integración de las funciones integradas no llega al último paso, que consiste en modificar el código base de Starknet para lograr un uso práctico. El alcance de la modificación del código está relacionado con la aplicación de diseño, y es necesario modificar el código para garantizar que el sistema operativo Starknet llame a las funciones integradas cuando sea posible. Por ejemplo, el sistema operativo Starknet llama a la función hash de Poseidón durante la ejecución del código Cairo y, al mismo tiempo, llama a la función integrada de Poseidón.
De manera similar a los diseños, las funciones integradas de Starknet ahora se pueden admitir manualmente. Sin embargo, a diferencia del caso de diseño, este soporte manual no es una barrera para la integración a pesar de que hay muchas funciones integradas. En otras palabras, la compatibilidad con las funciones integradas de Starknet no es una barrera para la integración, el diseño dinámico realmente allanará el camino para crear e integrar funciones adicionales.
Resumir
En este artículo explicamos qué son las funciones integradas, sus beneficios, los desafíos que implican y los planes de StarkWare. El enfoque actual está en el diseño dinámico, que no solo mejorará la eficiencia del proceso de prueba, sino que también facilitará la integración de nuevos elementos integrados.