Explorar Circle STARKs

En los últimos años, la tendencia en el diseño del protocolo STARKs ha sido hacia el uso de campos más pequeños. Las primeras implementaciones de producción de STARKs utilizaban campos de 256 bits, pero este diseño era menos eficiente. Para abordar este problema, STARKs ha comenzado a utilizar campos más pequeños, como Goldilocks, Mersenne31 y BabyBear.

Esta transformación ha mejorado la velocidad de pruebas. Por ejemplo, Starkware puede probar 620,000 valores hash de Poseidon2 por segundo en una computadora portátil M3. Esto significa que, siempre que estemos dispuestos a confiar en Poseidon2 como función hash, podemos resolver el problema de desarrollar un ZK-EVM eficiente.

Este artículo explorará el funcionamiento de estas tecnologías, con un enfoque especial en el esquema Circle STARKs. Circle STARKs tiene propiedades únicas compatibles con el campo Mersenne31.

Preguntas frecuentes sobre el uso de campos matemáticos más pequeños

Al crear pruebas basadas en hash, un truco importante es validar indirectamente las propiedades del polinomio mediante la demostración de los resultados de la evaluación del polinomio en puntos aleatorios. Este método puede simplificar considerablemente el proceso de prueba.

Para prevenir ataques, necesitamos seleccionar puntos aleatorios después de que el atacante proporcione el polinomio. En STARKs de campos más pequeños, la cantidad de valores aleatorios seleccionables es limitada, lo que plantea un desafío para la seguridad.

Las soluciones son dos:

1. Realizar múltiples inspecciones aleatorias
2. Campo de extensión

Los campos extendidos son similares a los plurales, pero se basan en un campo finito. Al introducir un nuevo valor α, creamos una nueva estructura matemática que puede realizar operaciones más complejas sobre un campo finito. Esta extensión nos permite tener más opciones de valores, lo que mejora la seguridad.

Circle FRI

Lo ingenioso de Circle STARKs es que, dado un primo p, se puede encontrar un grupo de tamaño p que tiene una propiedad similar a la de uno a dos. Este grupo está compuesto por puntos que cumplen condiciones específicas y sigue una regla de adición.

A partir de la segunda ronda, la asignación cambia:

f_0(2x^2-1) = (F(x) + F(-x))/2

Este mapeo reduce el tamaño del conjunto a la mitad en cada ocasión. Cada x representa dos puntos: (x,y) y (x,-y). (x → 2x^2 - 1) es la ley de duplicación de puntos.

FFTs circulares

El grupo Circle también soporta FFT, y la forma de construcción es similar a FRI. Una diferencia clave es que el objeto que maneja Circle FFT no es estrictamente un polinomio, sino un espacio de Riemann-Roch.

Como desarrollador, casi puede ignorar esto por completo. STARKs nunca le piden que entienda los coeficientes. Solo necesita almacenar el polinomio como un conjunto de valores evaluados en un dominio específico.

Cuotización

En el protocolo STARK del grupo circle, debido a que no hay una función lineal que se pueda aplicar a un solo punto, es necesario utilizar diferentes técnicas para reemplazar el método tradicional de operaciones comerciales. Nos vemos obligados a demostrar evaluando en dos puntos, agregando así un punto virtual que no requiere atención.

Polinomios que desaparecen

En STARK circular, la función polinómica desaparecida es:

Z_1(x,y) = y Z_2(x,y) = x
Z_{n+1}(x,y) = (2 * Z_n(x,y)^2) - 1

Invertir el orden de los bits

Para ajustar el orden inverso y reflejar la estructura de pliegue de Circle STARKs, necesitamos invertir cada dígito excepto el último, y usar el último dígito para decidir si invertir los otros dígitos.

Eficiencia

Circle STARKs es muy eficiente. Un cálculo probado generalmente involucra:

1. Aritmética nativa: utilizada para la lógica de negocio
2. Aritmética nativa: utilizada en criptografía
3. Buscar parámetros

La clave de la eficiencia es aprovechar al máximo todo el espacio en el seguimiento computacional para realizar un trabajo útil. Circle STARKs se desempeña bien en este aspecto.

Conclusión

Circle STARKs no son más complejos para los desarrolladores que los STARKs. Aunque las matemáticas detrás son complejas, esta complejidad en realidad está bien oculta.

Combinando tecnologías como Mersenne31, BabyBear y Binius, estamos acercándonos al límite de eficiencia de la capa base de STARKs. Las direcciones de optimización futuras para STARK podrían incluir:

1. Maximizar la eficiencia aritmética de funciones hash y firmas.
2. Realizar una construcción recursiva para habilitar más paralelización
3. Máquina virtual aritmética para mejorar la experiencia del desarrollador