Limitaciones y Roadmap

Que soporta el frontend de Circom hoy, y que viene despues.

El frontend de Circom aterrizo en beta.20 y aun esta creciendo. Esta pagina es la unica fuente de verdad sobre que funciona ahora y que esta planeado para releases proximos.

Soportado Hoy

Imports

import circuit "file.circom" as Nombre — absorcion completa de circuito.
import { T1, T2 } from "file.circom" — imports selectivos de template con aliases opcionales as.
import "file.circom" as P — imports de libreria con namespace.
Resolucion transitiva de include con deteccion de ciclos y deduplicacion por path canonico.
Flag de busqueda de libreria -l/--lib en ach circom.

Caracteristicas del lenguaje Circom

pragma circom 2.0.x y 2.1.x.
signal input, signal output, y signals intermedios.
<==, ===, y <-- (con analisis completo E100/W101/W102/W103).
template con parametros y arrays de signal.
Instanciacion de component, incluyendo arrays de componente (component muls[n]).
Declaraciones function evaluadas en tiempo de compilacion (imperativas: var, while, for, if/else, return, ++, *=, llamadas anidadas).
Loops for con limites constantes, parametricos y con expresion.
Branching if/else — ambas ramas bajadas, seleccion de rama via mux cuando es necesario.
var de tiempo de compilacion con aritmetica de complemento a dos de 256 bits (BigVal), asi que templates como CompConstant que computan 1 << 128 funcionan correctamente.
Variables de array de tiempo de compilacion 1-D y 2-D, con flattening row-major y resolucion de indice multi-dimensional.
Parametros de template de array (Template(t, C, 0) donde C es un array precomputado).
Constant folding de ternarios para que indices de array de rama muerta como xL[-1] nunca lleguen al lowering.
Los ternarios conocidos en tiempo de compilacion seleccionan su rama en lowering, evitando referencias de rama muerta.

Output del backend

R1CS (Groth16) y Plonkish (halo2 KZG fork de PSE).
Conteos de constraints que coinciden o superan al Circom 2.x de referencia despues de que corre el optimizador O2.
Exports binarios .r1cs + .wtns que permanecen compatibles con snarkjs.
Generacion de verificador Solidity para Groth16.

Call sites

Bloques prove {} llamando templates selectivos o con namespace.
Declaraciones circuit nombre(...) { ... } llamando templates.
Llamadas en modo VM desde codigo .ach top-level (ve Modo VM para restricciones).

Cobertura de Circomlib

Las siguientes primitivas de circomlib han sido compiladas end-to-end, pasadas por generacion R1CS, y verificadas contra implementaciones de referencia. La comparacion completa de conteos de constraints vive en r1cs_optimization_benchmark en circom/tests/e2e.rs; la tabla condensada muestra el output O1 de Achronyme contra circom O2 (el mejor de circom):

Template	Achronyme O1	circom O2	Estado
`Num2Bits(8)`	9	17	✓ Achronyme supera circom O2 por 8
`Bits2Num(8)`	1	—	✓ R1CS verificado
`IsZero()`	2	2	✓ Iguala circom O2
`LessThan(8)`	10	20	✓ Achronyme supera circom O2 por 10
`CompConstant(n)`	✓	✓	✓ R1CS verificado
`Poseidon(2)`	240	240	✓ Iguala circom O2
`Pedersen(8)`	13	13	✓ Iguala circom O2
`MiMC(n, nRounds)`	✓	✓	✓ R1CS verificado
`MiMCSponge(2, 220, 1)`	1317	1320	✓ Achronyme supera circom O2 por 3
`BabyAdd`, `BabyDbl`, `BabyCheck`	48 (combinado)	—	✓ R1CS verificado
`EscalarMulFix(253)`	11	11	✓ Iguala circom O2
`EscalarMulAny(254)`	2310	2310	✓ Iguala circom O2
`EdDSAPoseidonVerifier`	—	—	✓ Compile + instantiate verificados (41,136 nodos IR, 263,709 instrucciones VM); E2E R1CS pendiente de run de test
Mux, gates, bitify, comparadores	—	—	✓ Usados transitivamente por los anteriores

La verificacion end-to-end de pruebas Groth16 se ha hecho on-chain para Num2Bits, IsZero, LessThan, Poseidon(2) y EscalarMulAny(254).

Caracteristicas Circom No Soportadas

Cada caracteristica no soportada abajo es parseada correctamente y rechazada con un error dedicado (E2xx) apuntando a la linea ofensora, en lugar de crashear o miscompilar silenciosamente. La columna de razon explica por que la caracteristica esta restringida hoy y que la desbloquearia.

Parseadas pero rechazadas en lowering

Caracteristica	Error	Razon
Declaraciones `bus` (Circom 2.2.0)	`E205` — “bus types require Circom ≥2.2.0 bus compilation support which is not yet implemented”	Adoptado por circomlib solo de forma dispersa; ningun circuito de circomlib en el benchmark actual requiere buses. El mapeo de lowering esta bien definido; el trabajo se secuencia despues de que emerja demanda de cobertura mas amplia de `circomlib`.
Templates `custom` (Circom 2.1.0)	`E205` — “template `T` is declared as `custom` which generates Plonk custom gates; custom templates are not supported in R1CS mode”	Los templates custom compilan a custom gates Plonk en circom de referencia. El backend Plonkish de Achronyme ya soporta custom gates via halo2, pero el camino de lowering `.circom → Plonkish` aun no esta cableado — para la cobertura actual de circomlib (toda R1CS) la restriccion no tiene costo para el usuario.
Modificador `extern_c` (Circom 2.2.3+)	Parseado como metadata; no existe camino de lowering	Reservado para el escape hatch experimental de FFI de Circom; ningun circuito de circomlib lo usa. Se abordara si aparece una necesidad real.

No parseadas aun

Caracteristica	Razon
Declaraciones `tag` de signal con significado semantico	`signal s {tagName}` parsea como signal con metadata; los tags en si no influyen en la generacion de constraints aun. Los tags raramente cargan significado en circomlib.
Componentes anonimos (llamada inline `Template()(...)` sin binding a nombre)	Raramente usado; la forma con nombre explicito siempre funciona.
Literal de array como asignacion de signal (`signal z <== [a, b, c]`)	La asignacion elemento por elemento es el workaround documentado.

Estructurales — por diseno

Estas restricciones vienen del modelo de lowering de Achronyme (IR totalmente desenrollado, R1CS primero), no de trabajo faltante:

Cuerpos function recursivos — las funciones son evaluadores imperativos de tiempo de compilacion. Recursion no terminante y recursion cuya profundidad el lowerer no puede probar acotada son rechazadas en tiempo de evaluacion.
Dimensiones de array no constantes fuera de contextos de unrolling de for-loop — el IR tiene forma estatica.
Indices de array con variables de runtime en modo circuito — el IR se desenrolla completamente, asi que los indices de array deben ser conocidos en tiempo de compilacion. Esto refleja la restriccion que circom mismo aplica; circomlib sigue la misma disciplina.

Si alguna de estas esta bloqueando un circuito real para ti, por favor abre un issue con el fuente .circom — la mayoria de los casos se resuelven con un workaround estructural en lugar de una extension de lenguaje.

Limitaciones del Modo VM

El modo VM (llamar templates desde codigo no-prove bajo ach run) es mas angosto que el modo circuito. Restricciones de Phase 4:

Los template arguments deben ser literales enteros. let N = 8; Num2Bits(N)(x) es rechazado — usa Num2Bits(8)(x) directamente hasta que aterrice el constant folder de tiempo de compilacion para el modo VM.
Solo signal inputs escalares. Templates con signal input in[n] no pueden llamarse desde modo VM.
Sin persistencia cross-process de .achb. Los handles y librerias de circom aun no se serializan al archivo de bytecode, asi que ach run file.ach funciona pero ach compile file.ach && ach run file.achb no carga el estado circom entre procesos.
Sin carga de libreria en runtime. El registro circom se congela en tiempo de compilacion. ach run no puede ingerir un nuevo archivo .circom en runtime.

Ve Modo VM para la semantica de llamada y por que existen estas restricciones.

Roadmap

Trabajo planeado, en orden de prioridad aproximado:

Phase 5 — Integracion con el manifest (enviado)

La seccion [circom] en achronyme.toml ya esta en produccion:

[circom]
libs = ["vendor/circomlib/circuits"]

ach run, ach circuit y ach circom consumen [circom].libs automaticamente, y las banderas CLI -l/--lib se suman a la lista en lugar de reemplazarla. Ver Configuracion del Proyecto.

Phase 6 — Docs y ejemplos (en progreso)

Enviado:

Guia de Interop con Circom de seis capitulos en la documentacion principal (lo que estas leyendo).
Tabla completa de benchmark de constraint-count de circomlib (ver arriba).

Pendiente:

Tutoriales trabajados (inclusion Merkle con Poseidon importado, verificacion de firma EdDSA).
Benchmarks cross-tool comparando Achronyme + circomlib importado vs circom plano.
Guia de migracion para equipos moviendo proyectos circom existentes.

Follow-ups de Phase 4 (modo VM)

Constant folding de tiempo de compilacion para que los template args del modo VM puedan ser variables mientras pleguen.
Signal inputs de array extendiendo el opcode CallCircomTemplate para aceptar arrays de input.
.achb cross-process serializando CircomHandle y el registro de librerias al archivo de bytecode.

Investigacion abierta

Soporte de bus y tag — mayormente un problema de parser + lowering; el backend no deberia necesitar cambios.
custom_templates — estos compilan a custom gates de halo2 en circom de referencia; el backend Plonkish de Achronyme ya soporta custom gates, asi que es mayormente un mapeo de lowering.
Cobertura mas amplia de O2/DEDUCE para que templates que actualmente igualan O1 de circom puedan bajar mas cuando la eliminacion gaussiana de DEDUCE encuentre constraints lineales adicionales para plegar.

Largo plazo

Frontend Noir. El mismo approach de dual-frontend (parse → lower → ProveIR) que hace que el interop con Circom funcione dejaria a Achronyme absorber programas Noir tambien. Sin compromiso aun — trackeado como investigacion.
Backend STARK para Goldilocks. No especifico de Circom, pero relevante ya que algunos templates de circomlib (variantes MiMC, Poseidon con α=7) calzan naturalmente en Goldilocks una vez exista un backend STARK.

La pagina del roadmap del proyecto trackea los mismos items a nivel mas alto; la integracion con el manifest del proyecto sera actualizada una vez que aterrice la seccion [circom].