VeriFire — Resumen ejecutivo

Versión corta · 5 minutos de lectura · Alex Agustín Hernando · Dir. Dr. David Petrocelli

Universidad Nacional de Córdoba · FCEFyN · Ingeniería en Computación · Mayo 2026


Autor	Alex Agustín Hernando
Director	Dr. David Petrocelli — LICDIA UNLu / Caylent USA
Duración	12 meses (part-time 20–25 hs/semana)
Presupuesto	~$240–310 USD (RPis del laboratorio · K8s on-prem reutilizable)
Versión completa	propuesta-I4-edge-ai-zkml-v2.html

1. Qué propone

Diseñar e implementar VeriFire, una plataforma SaaS multi-tenant donde cualquier nodo IoT puede demostrar criptográficamente que ejecutó correctamente un modelo de machine learning sobre datos reales — sin revelar el dato crudo en la cadena pública; en backends cloud/K8s el witness viaja cifrado a un worker autorizado. La prueba se verifica en una blockchain (Base L2) y dispara un reward económico al operador.

Caso de uso ancla: detección temprana de incendios en las Sierras de Córdoba mediante una red de cámaras de bajo costo (Raspberry Pi 4 + cámara). En 2024 se quemaron ~70.000 ha; los sistemas actuales (satélites) tienen latencia de 35–60 min — una red densa edge puede detectar humo en minutos.

Aporte académico real: no es el clasificador de incendios. Es la plataforma multi-backend que permite que el mismo protocolo zkML corra en tres clases de hardware (Edge ARM · K8s CPU · Cloud GPU) verificadas por un único contrato on-chain.

2. Por qué es novedoso

Cada uno de los 5 campos involucrados (Blockchain, zkML, AI/Cloud-native, SaaS multi-tenant, Edge IoT) tiene literatura madura por separado. La novedad está en la intersección de los cinco, donde no hay implementación académica publicada.

Trabajo cercano	Qué hace bien	Qué le falta
Helium, Hivemapper (DePIN)	Sensing distribuido con incentivos	Sin verificabilidad criptográfica del cómputo
Inference Labs (Bittensor)	zkML a escala (160M+ proofs)	Datacenter only, sin edge, sin SaaS multi-tenant
ForestGuard, Edge MobileNet	Detección de incendios en RPi	Sin blockchain, sin verificabilidad
zkVerify	Diseño ZK para IoT/DePIN	Sin implementación de campo, sin K8s

VeriFire = los 5 campos cruzados + caso de uso real + benchmark cross-platform.

3. Aporte distribuido (ficha técnica)

Área	%	Foco
Blockchain	25 %	Smart contract multi-class, reward por clase de nodo, EZKL Verifier on-chain
AI · Arquitectura escalable Cloud-Native + SaaS	45 %	Jobs K8s nativos (un Job por inferencia); Deployment para model serving; KEDA + HPA; GPU-accelerated proving; control plane multi-tenant; model registry on-chain
Edge AI / IoT	15 %	TinyML cuantizado INT8, firmware RPi 4, light client
zkML / Criptografía	15 %	Circuito SNARK via EZKL, doble firma input + worker, benchmark cross-platform

4. Tres backends, un contrato

#	Backend	Clase	Hardware
1	Edge ARM	CPU on-device	Raspberry Pi 4 (proving local, máxima privacidad)
2	K8s managed	x86 CPU paralelo	k3s on-prem, 3 pods con KEDA
3	Cloud GPU VM	GPU (CUDA)	Vast.ai · EZKL CUDA (sin infraestructura K8s)

Los tres backends son cualitativamente distintos entre sí: cómputo en el dispositivo edge, cluster CPU paralelo escalable, y aceleración GPU. El benchmark cross-platform compara EZKL en estos tres casos — reproducible a bajo costo (~$30 en Vast.ai para el GPU), con K8s como baseline x86 cloud.

5. Hipótesis falsables principales

#	Hipótesis	Métrica esperada
H1	Speedup EZKL CUDA vs CPU en proof generation (modelos ≤ 5 M params)	2×–8×
H2	Knee-point edge para RPi 4	~2–5 M params
H4	Costo on-chain por verificación en Base L2	< $0.005 USD
H6	Auto-scaling K8s frente a 100× pico de carga	< 60 s a estabilizar
H8	Falsos negativos del clasificador en humo	< 5 %

10 hipótesis totales en la versión completa (§11.6).

6. Cronograma 12 meses

Mes	Hito
1	PoC: proof EZKL en RPi y K8s, ambos verificados on-chain
4	Benchmark cross-platform (3 backends × 1 modelo) + workshop paper submited
7	Protocolo VeriFire v1.0 + worker K8s + control plane SaaS en testnet
10	Red piloto operacional 8 semanas con 2 tenants ficticios
11	Paper completo submited (IEEE IoT Journal o ACM SenSys)
12	Defensa

Alcance mínimo defendible cabe en 8–9 meses si fuera necesario adelantar.

7. Recursos clave

3 Raspberry Pi 4 (acceso gratuito, laboratorio de Sistemas Embebidos) + cámaras (~$120 USD).
Cluster k3s on-prem sobre hardware reutilizado del laboratorio ($0).
Vast.ai GPU on-demand para experimentos GPU (~$30 USD).
Total: ~$240–310 USD

10. ¿Querés más detalle?

Necesito…	Vista recomendada
Una idea general en 5 minutos	Este resumen
Trabajos relacionados con tablas comparativas	Versión completa §8
Diseño experimental detallado	Versión completa §9
Smart contract con código Solidity	Versión completa Anexo A
Plan de difusión open-source	Versión completa Anexo D
Diagramas (Venn 5 campos · Arquitectura · Pareto · Gantt)	Versión completa

Resumen ejecutivo · Mayo 2026 · 1 página de lectura.

VeriFire — Propuesta de Tesis (v2)

Plataforma full-edge de inferencia verificable con zkML y web pública de monitoreo georreferenciado — benchmark Edge (Raspberry Pi) vs Cloud GPU (Vast.ai) para redes DePIN de monitoreo ambiental — Alex Agustín Hernando, Dir. Dr. David Petrocelli

Universidad Nacional de Córdoba · FCEFyN · Ingeniería en Computación · Mayo 2026


Autor	Alex Agustín Hernando
Director	Dr. David Petrocelli — LICDIA UNLu / Caylent USA
Codirector (edge / embedded)	Cátedra de Sistemas Embebidos — FCEFyN UNC
Espacio curricular	Trabajo Final / Tesis de grado
Fecha	Mayo 2026

1. Título

VeriFire: Plataforma full-edge de inferencia verificable con zkML y web pública de monitoreo georreferenciado — benchmark Edge (Raspberry Pi) vs Cloud GPU (Vast.ai) para redes DePIN de monitoreo ambiental

2. Resumen

Esta tesis propone el diseño, implementación y evaluación de VeriFire, una plataforma full-edge de inferencia verificable con pruebas zkML (Zero-Knowledge Machine Learning) para habilitar redes DePIN (Decentralized Physical Infrastructure Networks) de monitoreo ambiental. En estas redes cada nodo edge puede demostrar criptográficamente que ejecutó correctamente una inferencia sobre datos reales —sin revelar el dato crudo—, la prueba se verifica en cadena y activa un reward económico.

El aporte central tiene dos componentes complementarios: (i) un protocolo de Proof-of-Inference con input-binding criptográfico verificado on-chain en una red EVM (Base L2), independiente del hardware donde se ejecute el cómputo; y (ii) una caracterización empírica del trade-off privacidad / latencia / costo entre dos clases de backend extremas y representativas: edge ARM (Raspberry Pi 4, proof on-device, privacidad máxima) y cloud GPU (VM con EZKL CUDA en Vast.ai, máximo throughput). La comparación lado a lado responde cuándo el edge es viable y cuándo conviene delegar el proof a una GPU.

El caso de uso ancla es la detección temprana de incendios en las Sierras de Córdoba mediante una red de cámaras de bajo costo, problema socialmente relevante (~70.000 hectáreas quemadas en 2024). El aporte académico, sin embargo, no es el sistema de detección sino el protocolo + benchmark + plataforma de visualización, transferibles a cualquier DePIN de sensing.

La operación de la red piloto se acompaña de una web pública que actúa como dashboard de monitoreo: un mapa georreferenciado (basado en OpenStreetMap) muestra el estado y geolocalización de cada nodo, el historial de mensajes e inferencias firmadas por nodo, las alertas emitidas y los eventos verificados on-chain en tiempo real. La web es de solo lectura, sin multi-tenant ni autenticación: cualquier ciudadano u organismo (ETAC, Defensa Civil) puede auditar el estado de la red.

La metodología incluye benchmark experimental cross-platform (ARM edge vs GPU Vast.ai) del trade-off accuracy / latencia / RAM / costo de gas; implementación end-to-end (firmware RPi, cloud worker GPU, web pública, smart contracts); análisis de seguridad del mecanismo y modelado económico del reward. La extensión a una plataforma SaaS multi-tenant con backend Kubernetes y reward diferenciado por clase de nodo queda documentada como trabajo futuro (§11.5).

3. Área temática

Área principal

Blockchain y aplicaciones descentralizadas (DApps).

Subáreas

DePIN — Decentralized Physical Infrastructure Networks.
Inferencia verificable on-chain (zkML) — Zero-Knowledge Machine Learning aplicado a redes con incentivo económico.
Smart contracts y tokenomics — Solidity, Foundry, EVM, contratos verificadores de proofs.
Edge AI / IoT — TinyML cuantizado, firmware en hardware resource-constrained.
Criptografía aplicada — Zero-Knowledge Proofs, SNARKs, protocolos de input-binding.
Visualización geoespacial y dashboards públicos — mapas interactivos sobre OpenStreetMap, exposición read-only del estado de la red para auditoría ciudadana.

Clasificación IEEE Taxonomy 2024 (v1.03)

Computers and information processing
- Computer security
  - Data integrity → Non-repudiation — pruebas zkML on-chain
  - Application security — protocolo VeriFire full-edge, replay protection
- Distributed computing
  - Blockchains — Base L2, smart contract EZKL Verifier
  - Decentralized applications — DePIN, rewards ERC-20
- Software → Software engineering → Formal verification — verificabilidad criptográfica del cómputo
Computational and artificial intelligence
- Machine learning → Deep learning → Convolutional neural networks — modelo CNN de detección
Communications technology
- Wireless sensor networks → Event detection — red de nodos Raspberry Pi

4. Palabras clave (5)

zkML · Blockchains · Decentralized applications · Non-repudiation · Formal verification

5. Fundamentación de la investigación

Las sierras de Córdoba concentran uno de los problemas ambientales más graves de la Argentina central:

2024: ~70.000 hectáreas de bosque nativo quemadas — más del triple de la superficie de CABA. El incendio en la zona de Capilla del Monte / San Marcos Sierras alcanzó 42.046 ha en un solo evento.
2025: mejora significativa (~21.000 ha afectadas, 80 % menos que 2024), atribuida a detección más temprana y coordinación mejorada del ETAC.
La detección temprana es el factor diferencial crítico: un incendio detectado en sus primeros 5 minutos puede controlarse con recursos mínimos; uno detectado tarde requiere decenas de dotaciones y aviones hidrantes.

Los sistemas actuales de detección presentan limitaciones: la detección satelital (NASA FIRMS, Copernicus, Satellites on Fire) tiene latencia de 35–60 minutos; las cámaras 360° fijas en torres ETAC tienen cobertura limitada y costo alto; los drones requieren operador y no son autónomos 24/7. No existe en Córdoba una red de sensores de bajo costo, densa, que opere 24/7 con latencia de minutos y que sea privacy-preserving.

5.2 Interés científico: el problema de la confianza en redes distribuidas de sensores

Una red de sensores distribuida con incentivos económicos requiere resolver un problema fundamental: ¿cómo saber que el nodo realmente ejecutó el modelo sobre datos reales y no simplemente mintió el resultado para cobrar el reward?

Las soluciones existentes —oráculos centralizados, multi-witness al estilo Helium, TEEs (Intel SGX / ARM TrustZone)— tienen limitaciones de privacidad, requerimiento de hardware específico, o vulnerabilidades documentadas. zkML es la única solución que preserva privacidad y provee verificabilidad sin terceros, pero hasta 2025–2026 no existe ninguna implementación pública evaluada en hardware edge IoT resource-constrained y benchmarkeada contra GPU CUDA bajo el mismo protocolo y dataset.

5.3 Interés técnico: cómputo edge verificable y plataformas DePIN

La mayoría de los DePINs actuales asumen una clase única de hardware (Helium = hotspots; Filecoin = storage nodes; Hivemapper = dashcams). Esto los hace rígidos: no pueden absorber operadores con capacidad de cómputo distinta ni escalar a modelos grandes. Demostrar empíricamente cuándo un edge resource-constrained alcanza para ejecutar zkML on-device y cuándo conviene delegar a un GPU cloud, con un protocolo que mantiene la verificabilidad uniforme, sería un patrón de diseño reutilizable para la próxima generación de DePINs.

5.4 Interés personal y formativo

La tesis articula los cuatro ejes técnicos del autor: blockchain (smart contracts, tokenomics), edge AI / firmware embebido (TinyML cuantizado en ARM), criptografía aplicada (zkML, EZKL, doble firma) y visualización geoespacial pública (mapas + indexers on-chain). La extensión cloud-native / SaaS multi-tenant queda como trabajo futuro (§11.5). Es un trabajo de tesis con riesgo técnico medio-alto pero alto potencial de impacto académico (publicaciones tier A) y social (transferencia al ETAC / Defensa Civil CBA).

6. Descripción del tema de estudio

6.1 Definición del tema

El tema central es el diseño y validación experimental de un protocolo de inferencia verificable on-chain en hardware edge, complementado por un benchmark contra un backend GPU cloud y por una web pública de monitoreo georreferenciado, aplicado a redes DePIN de sensing ambiental. Se ubica en la intersección de cuatro áreas:

Área	Aporte específico al tema
Blockchain	Smart contract verificador agnóstico al backend, registro inmutable de inferencias y eventos, replay protection
Edge AI / IoT	TinyML cuantizado (MobileNetV3-Small INT8), firmware RPi 4 (captura → inferencia → proof → submit), métricas accuracy / F1 / AUC-ROC
zkML / criptografía	Circuitos SNARK (EZKL/Halo2), input-binding (hash entrada → proof), doble firma capture + worker; benchmark cross-platform ARM edge vs GPU CUDA
Web de monitoreo georreferenciado	Dashboard público read-only con mapa interactivo (Leaflet/OpenStreetMap), geolocalización de nodos, historial de mensajes e inferencias firmadas por nodo, alertas y eventos verificados on-chain en tiempo real

Nota sobre datos on-chain: el contrato registra el hash del input, la salida del modelo, la verificación de la proof y el reward; estos datos quedan en cadena como fuente inmutable que la web pública consume vía un indexer. La extensión del contrato a capability attestation con clase de nodo y reward diferenciado para soportar múltiples backends de cómputo queda como trabajo futuro (§11.5).

6.2 Distribución porcentual del aporte

Área	%	Descripción del aporte
Blockchain	20 %	Smart contract verificador (Solidity + Foundry + Base L2) agnóstico al backend; contrato EZKL Verifier auto-generado; protocolo on-chain (replay protection, input-binding, event emission); reward ERC-20 plano en testnet (sin valor económico).
Edge AI / IoT	30 %	TinyML (MobileNetV3-Small INT8); firmware RPi 4 (captura → inferencia → proof → submit on-chain); pipeline de cuantización ONNX → EZKL; métricas accuracy / F1 / AUC-ROC; light client de verificación.
zkML / Criptografía	35 %	Circuito SNARK de inferencia via EZKL (Halo2); protocolo de input-signing (hash binding entrada → proof); doble firma capture + worker para el caso de delegación a cloud GPU; benchmark cross-platform ARM edge vs Cloud GPU VM (Vast.ai) sobre proof time, peak RAM, proof size y gas cost; análisis del threat model.
Web pública de monitoreo	15 %	Dashboard read-only sin autenticación: mapa georreferenciado de nodos (Leaflet + OpenStreetMap), estado y geolocalización en tiempo real, historial de mensajes e inferencias firmadas por nodo, panel de alertas, vista de eventos on-chain (indexer subgraph). Backend FastAPI + indexer.

6.3 Límites del tema

Está incluido en el alcance: - Diseño formal del protocolo VeriFire (input-binding, doble firma capture + worker, contrato verificador agnóstico al backend). - Implementación de referencia open-source: light client edge (firmware RPi), cloud worker GPU (FastAPI + EZKL CUDA en Vast.ai), web pública de monitoreo (mapa + historial), smart contracts. - Benchmark experimental cross-platform en dos backends: edge ARM (Raspberry Pi 4) vs cloud GPU VM (Vast.ai). - Red piloto operacional: 3 nodos RPi + 1 VM GPU on-demand, con la web pública conectada al indexer on-chain. - Análisis de seguridad del mecanismo y modelado económico básico del reward. - Caso de uso ancla: clasificación binaria humo / no-humo.

Queda fuera del alcance (documentado como trabajo futuro en §11.5): - Tercer backend Kubernetes (Jobs nativos + Helm + KEDA/HPA) y benchmark CPU-pods vs GPU. - Plataforma SaaS multi-tenant con Postgres RLS, namespace isolation, onboarding permissioned, SLOs por tenant. - Reward diferenciado por clase de nodo (EDGE > CLOUD/K8S) y capability attestation on-chain. - Despliegue provincial a producción coordinado con ETAC / Defensa Civil CBA. - Descentralización del onboarding: stake o reputación on-chain para registro permissionless. - Análisis legal/regulatorio del token. Aclaración explícita: el VeriFireToken es un ERC-20 de testnet (Base Sepolia), sin valor económico, sin distribución pública, sin oferta a terceros. La tesis no genera ningún instrumento financiero regulable bajo MICA, SEC ni la CNV argentina; el token es un constructo de laboratorio análogo a una “red privada” en una tesis de redes. - Hardware custom: la tesis usa RPi 4 estándar, no diseña placas propias. - Modelos generativos o LLMs de visión: el trabajo se enfoca en clasificadores binarios cuantizados. - Multi-cadena: el contrato corre solo en Base (EVM); portar a Solana/Polkadot es trabajo futuro. - Política de upgrade en producción del modelo y del verifier: se documenta en la tesis (qué pasa cuando se reentrena el modelo y cambia el IEZKLVerifier, qué grace period existe), pero no se ejercita en operación real porque el modelo no se reentrena durante el piloto.

6.5 Justificación cuantitativa de la red piloto

La elección de 3 nodos edge RPi + 1 VM GPU Vast.ai on-demand no es arbitraria: es el mínimo capaz de validar las propiedades centrales del sistema sin sobre-dimensionar.

Propiedad a validar	Por qué 3 RPi + 1 VM GPU alcanzan
Tolerancia a fallos del data plane	Con 3 nodos podemos simular caída del 33 % (1 nodo offline) y verificar que la red sigue operativa y la web pública refleja correctamente el cambio de estado.
Multi-witness mínimo para alertas	3 cámaras geo-distribuidas en el campus permiten implementar el quórum básico “≥ 2 nodos coinciden en humo” para descartar input-fraud (un solo nodo gritando “fuego”).
Heterogeneidad operacional del benchmark	Todas las RPi corren el mismo clasificador (MobileNetV3-Small INT8) y la misma VM GPU repite los mismos inputs: así se aísla el efecto del backend de cómputo en el benchmark de proof generation (ARM Cortex-A72 vs CUDA).
Caso de delegación capture → worker	Con 3 capture nodes y una VM GPU compartida, el protocolo se ejercita en sus dos modos: (a) full-edge (proof on-device) y (b) split (capture firma, worker GPU prueba). La doble firma se valida en operación real, no solo en simulación.
Visualización geoespacial sustantiva	3 nodos georreferenciados en el campus son suficientes para que el mapa público muestre un layout no trivial (≥ 3 marcadores, ≥ 2 áreas de cobertura), con historial de mensajes diferenciado por nodo.

Escalar a 5 o 10 nodos no agrega propiedades nuevas que validar — solo agrega más datos a las mismas mediciones. Por eso la red piloto se acota a 3 RPi + 1 VM GPU y el escalamiento provincial se documenta como trabajo futuro.

6.7 Deep dive del aporte: dónde está la novedad

Cada uno de los cinco campos involucrados (Blockchain, AI/Cloud-native, SaaS, Edge AI/IoT, zkML) tiene literatura madura por separado. La novedad de esta tesis no está dentro de ningún campo individual sino en la intersección de los cinco, donde no hay implementación académica publicada.

Diagrama de intersecciones (Venn de cinco campos)

Lectura del diagrama: cada bolita es un campo con literatura propia y madura. La estrella ★ central marca el espacio de los cinco simultáneamente — donde no hay implementación académica publicada y donde se ubica el aporte de esta tesis.

Lo que ya existe (y no es el aporte)

Intersección	Quién la ocupa	Por qué no alcanza
Blockchain ∩ zkML	Inference Labs (Bittensor), zkVerify, Modulus Labs	Datacenter only, no edge, no multi-backend, no SaaS multi-tenant
Blockchain ∩ DePIN ∩ IoT	Helium, Hivemapper, Geodnet	Sin verificabilidad criptográfica del cómputo (multi-witness ≠ zkML)
AI ∩ Cloud-native ∩ K8s	KServe, Kubeflow, Ray Operator	No hay integración con verificación on-chain ni proof generation pipelines
Edge AI ∩ IoT ∩ TinyML	ForestGuard, MobileNetV2 fire detection	Sin blockchain, sin verificabilidad, sin compute heterogéneo
zkML ∩ Edge	(literatura agnóstica)	Surveys identifican explícitamente la ausencia de evaluaciones edge IoT resource-constrained

Lo que esta tesis ocupa por primera vez

La intersección ★ donde se cruzan los cinco campos, materializada en cinco contribuciones (C1–C5) que se detallan en §11.1:

Protocolo zkML full-edge con doble firma: proof on-device en ARM + modo split al GPU manteniendo binding criptográfico (Blockchain ∩ zkML ∩ Edge).
Benchmark Edge vs GPU CUDA sobre el mismo circuito y dataset (zkML ∩ Edge ∩ AI).
Plataforma + web pública auditable open-source con mapa georreferenciado de la red (Edge ∩ Blockchain ∩ Visualización pública).
Metodología de circuitos zkML “edge-aware” (zkML ∩ AI ∩ Edge).
Patrón “DePIN auditable”: red verificable on-chain con dashboard ciudadano sin login (Blockchain ∩ Edge ∩ Transparencia).

Por qué esta intersección es difícil (y por qué nadie la ocupó todavía)

Cross-disciplinar: requiere dominar varios campos que normalmente viven en silos académicos distintos (criptografía, sistemas embebidos, ML cuantizado, blockchain, visualización geoespacial).
Hardware-in-the-loop: la mayoría de los papers de zkML no tocan hardware real; los que lo hacen no benchmarkean lado a lado contra GPU CUDA bajo el mismo protocolo.
Costo experimental: correr 2 backends × 30 réplicas (Edge ARM y GPU CUDA Vast.ai) + red piloto operacional 2–3 meses + web pública desplegada requiere una inversión coordinada que rara vez se justifica para un solo paper.
Caso de uso anclado en realidad: muchas propuestas teóricas no se molestan en validar contra un dominio social concreto (incendios CBA), lo cual deja la novedad sin “pegada” práctica.

Riesgo controlado del aporte

Si por motivos técnicos no se logra la versión completa, el aporte se preserva con dos backends (alcance mínimo defendible §9.8) — sigue siendo la primera intersección publicada de los campos. La granularidad del benchmark se reduce, pero la categoría de aporte sobrevive.

7. Planteamiento del problema de estudio y objetivos

7.1 Pregunta central de investigación

¿Es viable diseñar un protocolo de inferencia verificable on-chain (Proof-of-Inference) ejecutable en hardware edge resource-constrained (Raspberry Pi 4) preservando privacidad del dato crudo; cuál es el trade-off cuantificable contra un backend GPU (Vast.ai, EZKL CUDA) en términos de accuracy, latencia de generación del proof, consumo de recursos y costo on-chain; y cómo se complementa con una web pública de monitoreo georreferenciado que audite la red sin terceros de confianza?

7.2 Preguntas secundarias

Q1 — Edge: ¿Qué arquitecturas de modelo TinyML son proving-friendly en EZKL sobre ARM Cortex-A72?
Q2 — Cross-platform: ¿Cómo escala el proof time entre ARM edge y GPU CUDA para el mismo modelo y dataset? ¿Hay un knee-point donde edge deja de ser viable?
Q3 — Privacidad y delegación: ¿El binding criptográfico extendido (input-sig + worker-sig) es suficiente para sostener el threat model cuando el proof se delega del edge al worker GPU?
Q4 — Tokenomics: ¿Qué rango de precios del token y de reward son necesarios para que un operador edge tenga incentivo positivo dado su costo operacional real?
Q5 — Visualización pública: ¿Qué información mínima debe exponer la web de monitoreo (estado de nodos, historial de mensajes, eventos on-chain) para que un auditor externo pueda verificar la integridad operacional de la red sin acceso privilegiado?

7.3 Objetivo general

Diseñar, implementar y evaluar empíricamente una plataforma full-edge de inferencia verificable on-chain con un benchmark contra GPU cloud y una web pública de monitoreo georreferenciado, validando un caso de uso real de detección temprana de incendios en las Sierras de Córdoba, y produciendo una metodología y un patrón arquitectónico transferibles a otras redes DePIN de sensing ambiental.

7.4 Objetivos específicos

OE1 — Formalizar el protocolo VeriFire (input-binding, doble firma capture + worker, contrato verificador agnóstico al backend) y su threat model.
OE2 — Realizar el primer benchmark cross-platform ARM edge (Raspberry Pi 4) vs Cloud GPU VM (Vast.ai, EZKL CUDA) de proof generation con EZKL para clasificadores binarios cuantizados.
OE3 — Implementar la plataforma de referencia open-source: light client edge (firmware RPi), cloud worker GPU (FastAPI), web pública de monitoreo (mapa + historial), smart contracts.
OE4 — Desplegar y operar una red piloto (3 RPi + 1 VM GPU on-demand) durante 2–3 meses, con la web pública conectada al indexer on-chain.
OE5 — Analizar la seguridad del mecanismo (Sybil, replay, worker malicioso) y modelar las condiciones económicas para que el operador edge tenga incentivo positivo.
OE6 — Producir dos publicaciones académicas: workshop zkML cross-platform (Edge vs GPU) y paper completo de la red DePIN con su web de auditoría pública.

7.5 Justificación del problema

¿Qué se va a investigar? Cómo construir y evaluar un protocolo de inferencia verificable on-chain ejecutable en hardware edge real, complementado con benchmark GPU y auditoría pública vía web georreferenciada.
¿Por qué? Porque no existe a la fecha una evaluación pública de zkML sobre ARM Cortex-A72 con EZKL para detección de incendios, ni una red DePIN de sensing con dashboard read-only que cualquier ciudadano pueda auditar sin login.
¿Para qué? Para producir un patrón de diseño reutilizable y un benchmark empírico que sirva de referencia a futuras redes DePIN, y para validar el modelo en un caso socialmente relevante.
¿A quiénes va dirigida la solución? A operadores de redes DePIN (técnico), a la comunidad académica (zkML, edge AI), y a organismos como ETAC / Defensa Civil CBA y al público general (impacto social — la web es pública y auditable).

8. Trabajos relacionados

Esta sección hace un deep dive en los campos relevantes para la tesis full-edge. Para cada trabajo: ficha técnica concreta (año, hardware, métricas), qué sí resuelve y, sobre todo, qué gap deja abierto respecto a la propuesta de esta tesis.

8.1 Edge AI para detección de incendios

La literatura de detección de incendios en edge es madura pero no verificable. Los sistemas existentes optimizan accuracy y latencia de inferencia local, pero asumen que el operador del nodo es honesto y no exponen auditoría pública on-chain.

Sistema	Año	Hardware	Modelo	Accuracy	Latencia	Verificable on-chain
Edge MobileNetV2 (PMC 2025)	2025	RPi 5	MobileNetV2 cuantizado	97.98 %	0.77 s	❌
ForestGuard (IJSRA 2025)	2025	RPi 4B + cámara	Fusión acústico-óptica	~93 %	tiempo real	❌
YOLOv8 + BM688	2024	RPi 4	YOLOv8 nano	~95 %	1–2 s	❌
ForestProtector (arXiv 2501.09926)	2025	Jetson Nano + RPi	RL + CNN	Alta	variable	❌
TinyML Real-Time Bench (arXiv 2509.04721)	2025	múltiples MCUs	varios	n/a	3.47–14.98 ms/frame	❌

Lo que estos sistemas resuelven:

Detección rápida y precisa en hardware barato (RPi 4 / Jetson Nano).
Footprint del modelo de 286–536 KB post-cuantización INT8, lo cual hace viable el despliegue masivo.
Operación 24/7 con latencia sub-segundo de inferencia.

Lo que dejan abierto (gap específico):

Sin verificabilidad criptográfica del cómputo: un nodo malicioso puede hardcodear resultado = 1 durante una ola de calor para cobrar reward, o nunca correr el modelo y devolver ruido — y nadie puede detectarlo.
Sin integración blockchain: las alertas viven en un servidor central; no hay incentivo económico distribuido.
Sin auditoría pública: no exponen un canal read-only para que ciudadanos u organismos verifiquen el estado de la red sin pedir acceso al operador.

VeriFire suma exactamente esas tres dimensiones (verificabilidad ZK on-device, blockchain con reward, web pública auditable con benchmark contra GPU CUDA) sobre el mismo problema base — full-edge.

8.2 zkML: Zero-Knowledge Machine Learning

Frameworks principales en 2025–2026:

Framework	Backend ZK	Velocidad relativa	RAM típica	Edge-friendly	Estado
EZKL	Halo2 (Plonkish)	Baseline	Media (1–8 GB)	Sí (con modelos chicos)	Producción, MIT
zkPyTorch	Custom (Marzo 2025)	VGG-16 en 2.2 s	Alta (32+ GB)	No	Research
Lagrange DeepProve-1	Custom (Agosto 2025)	LLM completo (GPT-2)	Muy alta (128+ GB)	No	Producción datacenter
RISC Zero zkVM	RISC-V	65.88× más lento que EZKL	Muy alta	No	Producción
Circom + Groth16	R1CS	Lento	Media	Marginal	Maduro

Por qué EZKL es la elección de la tesis:

Convierte modelos ONNX directamente a circuitos Halo2; no requiere reescribir el modelo.
Genera el contrato verificador en Solidity automáticamente (ezkl create-evm-verifier), lo cual cierra el loop on-chain sin código manual.
Existen builds tanto para ARM (RPi) como para CUDA (GPU), lo cual habilita el benchmark cross-platform que es el aporte C2 de esta tesis.
Es 65.88× más rápido que RISC Zero zkVM y 2.92× más rápido que Orion (medido en benchmarks oficiales del equipo EZKL, 2025).
License MIT, comunidad activa, releases mensuales.

Limitación reportada en la literatura zkML:

Modelos grandes (>10 M params) pueden requerir 128 GB+ RAM para generar el proof. Esto hace obligatorio el uso de TinyML cuantizado para on-device proving — o bien delegar al GPU cloud (Vast.ai con EZKL CUDA), que es justamente el modo split de VeriFire.
El survey de Springer Nature (2026) y arXiv 2502.18535 (Feb 2025) identifican explícitamente la ausencia de evaluaciones hardware-in-the-loop en dispositivos edge IoT resource-constrained. Citando textualmente: “all current zkML benchmarks assume datacenter or desktop x86 hardware”.

Caso de referencia: Inference Labs (Bittensor Subnet 2).

Métricas reportadas: 160M+ pruebas zkML generadas en producción durante 2024–2025.
Hardware: GPUs de datacenter (A100/H100).
Caso de uso: validar inferencias de modelos de Bittensor sobre prompts de usuarios.
Gap respecto a VeriFire: Inference Labs no toca edge ni IoT, no tiene un caso de uso ambiental, y no maneja multi-tenancy SaaS. Demuestra que zkML escala, pero no en el régimen resource-constrained.

Caso de referencia: zkVerify (2025).

Primer protocolo orientado específicamente a verificación ZK para IoT/DePIN.
Roadmap incluye chains de soporte y un Verifier modular.
Gap: sin implementaciones de campo, sin backend K8s funcional, sin benchmark cross-platform. Es un blueprint, no un sistema validado.

8.3 DePIN: Redes de infraestructura física descentralizada

DePIN coordinó en 2025–2026 la construcción de infraestructura física mediante incentivos tokenizados: ~$19B market cap, 250+ proyectos en CoinGecko, $1.6M/mes de revenue real en proyectos top de Solana (Frontiers in Blockchain, 2025).

Mecanismos de verificación de trabajo físico (PoPW) por proyecto

Proyecto	Mecanismo	Hardware	Verificabilidad del cómputo	Gap respecto a VeriFire
Helium	Proof-of-Coverage (multi-witness RF)	Hotspots LoRaWAN	Multi-testigo geográfico — no verifica cómputo, solo presencia	Sin inferencia; sin zkML
Filecoin	Proof-of-Replication + Proof-of-Spacetime	Storage nodes	Verifica que los datos están almacenados, no que se computó algo	Aplicable solo a storage, no a sensing
Geodnet / Wingbits	Location Oracle (GPS + multi-testigo)	Receptores GNSS / ADS-B	Verifica posición, no cómputo	Sin inferencia; sin verificabilidad criptográfica
Hivemapper	Multi-witness + verificación off-chain por humanos	Dashcams	Crowd verification — no criptográfica	Centralizado en el verificador
Quakecore (peaq)	Sensores sísmicos + aggregation	Acelerómetros IoT	Multi-testigo + ML server-side	Sin zkML, sin edge AI verificable
Inference Labs (Bittensor)	zkML server-side	GPUs datacenter	✅ Verifica cómputo con ZK	Datacenter only, sin edge, sin multi-tenant
zkVerify	Verificación ZK genérica	Agnóstico	✅ Diseño	Sin implementación de campo, sin K8s

Lectura del cuadro: los DePINs maduros (Helium, Filecoin, Hivemapper) usan multi-witness, no zkML — porque zkML es muy reciente. Los que sí usan zkML (Inference Labs) están en datacenter. Nadie cruza zkML on-device en edge + benchmark contra GPU + auditoría pública con mapa, que es el espacio de VeriFire.

8.4 Kubernetes cloud-native y plataformas multi-tenant (background para trabajos futuros)

Esta sección se conserva como background del trabajo futuro (§11.5): la extensión natural de VeriFire a una plataforma SaaS multi-tenant con backend K8s. La tesis actual no implementa esta capa, pero la revisión es relevante para fundamentar el roadmap.

Operadores K8s consolidados para AI workloads (KServe/KFServing para serving; Kubeflow Pipelines para training; Ray Operator para distributed compute; KEDA + NVIDIA GPU Operator + OPA Gatekeeper como dependencias reutilizables). Patrones de multi-tenancy SaaS sobre K8s (Burns 2023, Dobies 2020): namespace-per-tenant + NetworkPolicies + ResourceQuotas; RLS en Postgres + tenant_id propagado en headers; métricas Prometheus etiquetadas por tenant.

Gap que el trabajo futuro abordará: ningún despliegue K8s público integra proof generation zkML con verificación on-chain ni aplica multi-tenancy SaaS a un DePIN con incentivo económico on-chain.

8.5 Cuadro consolidado de proyectos más cercanos

Resumen comparativo de los cinco proyectos individuales más cercanos al espacio de VeriFire, dimensión por dimensión:

Proyecto	Edge IoT	zkML	Benchmark Edge↔GPU	Web pública auditable	Blockchain	Caso de uso real
Helium	✅	❌	❌	⚠️ parcial	✅	✅
Inference Labs (Bittensor)	❌	✅	⚠️ solo GPU	❌	✅	⚠️
ForestGuard / Edge MobileNet	✅	❌	❌	❌	❌	✅
zkVerify	⚠️ blueprint	✅	❌	❌	✅	❌
Satellites on Fire (AR)	❌	❌	❌	⚠️ mapa, sin proofs	❌	✅
VeriFire (esta tesis)	✅	✅	✅	✅	✅	✅

Conclusión del estado del arte:

El espacio en el que cae esta tesis — zkML on-device en edge IoT + benchmark cross-platform contra GPU + DePIN con web pública auditable + caso de uso real validado — no tiene implementación académica publicada. Cada eje existe individualmente (y bien) en la literatura; ningún trabajo combina edge ARM verificable, benchmark contra GPU CUDA y exposición pública georreferenciada. Esa intersección es el aporte (C1–C5, §11.1).

9. Propuesta metodológica

9.1 Enfoque general

Investigación aplicada de tipo design science: se construye un artefacto (protocolo + plataforma full-edge + web pública), se evalúa empíricamente con métricas cuantitativas, y se generaliza el resultado en forma de patrón arquitectónico y benchmark publicable. La metodología combina:

Fase de diseño formal (protocolo, threat model, contrato).
Fase experimental (benchmark cross-platform Edge vs Cloud GPU de proof generation y accuracy).
Fase de implementación (firmware RPi, cloud worker GPU, web pública con mapa, contratos).
Fase de validación operacional (red piloto 3 RPi + 1 VM GPU + web pública).
Fase analítica (seguridad del mecanismo, modelado económico).

9.2 Arquitectura técnica de la solución

Dos backends, un protocolo, un contrato. Los dos backends representan los extremos del espacio de cómputo verificable: por un lado el edge con privacidad máxima (proof on-device en ARM), por el otro la GPU cloud con throughput máximo (CUDA en Vast.ai). El espacio intermedio (clusters K8s CPU paralelizados) queda fuera del scope actual y se documenta en §11.5 como trabajo futuro. La comparación lado a lado de los dos extremos es suficiente para responder la pregunta central — cuándo es viable el edge y cuándo conviene delegar al GPU — y mantiene el alcance manejable.

#	Backend	Clase de cómputo	Hardware típico	Rol	Privacidad
1	Edge (ARM)	CPU ARM (proof on-device)	Raspberry Pi 4B 4 GB	Captura + inferencia + proof on-device + submit on-chain	Máxima — el frame nunca sale del dispositivo
2	Cloud GPU VM	GPU (CUDA)	Vast.ai · 1 instancia con EZKL CUDA habilitado (RTX 3090 o equivalente)	Worker remoto: recibe witness firmado del edge, ejecuta el proof con aceleración GPU y devuelve la prueba firmada (`sigWorker`). Habilita el modo split del protocolo cuando un modelo no es proving-friendly en ARM	Reducida — el worker ve el witness (pero no el frame crudo si se envía solo el embedding/hash)

La web pública (§9.3) consume el indexer del contrato on-chain y muestra el estado de los nodos sobre un mapa geo-referenciado. El contrato verificador on-chain es agnóstico al backend: rechaza cualquier proof inválido y registra el evento InferenceVerified independientemente de si el proof se generó en RPi o en GPU.

9.3 Arquitectura de servicios y escalabilidad

La plataforma VeriFire se organiza en cuatro planos de servicio ligeros y desacoplados. La separación responde al principio de loose coupling: cualquier plano puede actualizarse o reemplazarse sin tocar a los otros, y el on-chain plane (Base L2) es la fuente de verdad final.

9.3.1 Planos de servicio

Plano	Servicios principales	Responsabilidad	Modelo de escalabilidad
1. Data plane (edge)	Light client (firmware RPi 4)	Captura, firma del input, inferencia local, generación de proof on-device (modo full-edge) o envío del witness firmado al GPU worker (modo split), submit on-chain	Horizontal por adición de dispositivos físicos. Cada nodo se registra con su par de claves y geolocalización.
2. Compute plane (GPU worker remoto)	FastAPI service con EZKL CUDA en VM Vast.ai · Cola HTTP simple	Recibe witness firmado, genera proof acelerado por GPU, firma con `sigWorker` y devuelve la prueba al nodo edge (o submitea directo on-chain según el modo)	Vertical (instancia bajo demanda en Vast.ai). El benchmark se ejecuta en una única VM; el escalamiento horizontal con K8s queda como trabajo futuro (§11.5).
3. Web pública de monitoreo	Backend FastAPI read-only · Indexer subgraph (The Graph o propio) · Frontend estático con mapa Leaflet/OpenStreetMap	Dashboard georreferenciado y auditoría pública sin autenticación: mapa de nodos con marcador por estado, popup con últimas inferencias firmadas y su tx on-chain, historial paginado de mensajes por nodo, panel de alertas activas, vista de eventos verificados en tiempo real, contadores agregados (proofs/día, gas consumido, accuracy histórica)	Stateless detrás de CDN. El indexer cachea los eventos `InferenceVerified` y `AlertEmitted`; el frontend nunca consulta el RPC directamente.
4. On-chain plane (blockchain)	Smart contract `VeriFireNetwork` (Base L2) · Verifier EZKL · Indexer	Verificación criptográfica final del proof, emisión del reward, registro inmutable de eventos, fuente de verdad para la web pública	Escala con el L2: Base soporta ~1000 TPS y fees << 1 cent. El indexer cachea eventos para que la web no consulte el RPC en cada request.

9.3.2 Diagrama de servicios

9.3.3 Estrategias de escalabilidad por plano

Data plane (edge)

Escala linealmente con el número de nodos físicos sin coordinación centralizada: cada RPi firma su input con su clave propia y submitea directo al contrato (modo full-edge) o al GPU worker (modo split).
Cada nodo opera en push mode: no necesita polling.
Tolerancia a fallos: los witnesses y proofs no enviados se persisten en SD local hasta que la conectividad se restaura; al volver, el nodo replays contra el contrato.

Compute plane (GPU worker remoto)

Cloud GPU VM (Vast.ai): única instancia bajo demanda con EZKL CUDA. Sin autoscaling: la VM se activa para el benchmark y para el modo split cuando un modelo no es proving-friendly en ARM. La capacidad se dimensiona para absorber la carga del piloto (3 RPi); el escalamiento horizontal con K8s queda como trabajo futuro (§11.5).
Modo del protocolo: el nodo edge decide si genera el proof on-device (full-edge) o lo delega al GPU (split) según un umbral local de tamaño de modelo y disponibilidad del worker.

Web pública de monitoreo

Stateless: el backend FastAPI sirve el frontend y proxiea queries al indexer. Cualquier réplica responde igual.
Indexer (subgraph propio o The Graph hosted) cachea todos los eventos InferenceVerified y AlertEmitted; la web consulta el indexer, no el nodo RPC. Esto desacopla el TPS de lectura del TPS de escritura.
CDN: assets estáticos y tiles del mapa van por CDN (OpenStreetMap tile providers o self-hosted con caching).

On-chain plane

Escala con la capacidad de Base L2 (~1000 TPS, fees sub-cent). En picos de eventos (humo simultáneo en muchos nodos), el contrato relayer para batchear submissions queda documentado como trabajo futuro.
El contrato es la fuente de verdad: la web pública y cualquier auditor externo pueden reconstruir el estado completo de la red leyendo los eventos.

9.3.4 SLOs del sistema

La plataforma define SLOs internos auditables desde la web pública (no hay tenants, así que los SLOs son globales del piloto).

SLO	SLI	Target default
Latencia end-to-end (alerta)	Tiempo desde captura hasta evento `AlertEmitted` on-chain	P95 < 90 s en modo full-edge; < 60 s en modo split GPU
Disponibilidad de la web pública	Uptime del frontend + indexer	99.5 % mensual
Throughput de proofs	Proofs verificados / hora en la red piloto	≥ 3 proofs/hora (1 por nodo) durante operación normal
Tasa de error de verificación	Proofs rechazados on-chain / proofs submitted	< 0.1 %
Frescura del mapa público	Retraso entre evento on-chain y su aparición en la web	< 30 s

9.3.5 Failure modes y resiliencia

Falla	Impacto	Mitigación
Nodo edge offline	Pierde inferencias durante el outage; la web lo muestra como “sin contacto”	Buffer local en SD; reenvío al volver. Los otros 2 nodos siguen operando independientemente.
GPU worker Vast.ai caído	Modo split degrada a full-edge; modelos grandes no se pueden probar mientras dure	El edge detecta timeout y, si el modelo cabe localmente, genera el proof on-device. Si no cabe, queda en cola.
Indexer / web pública caídos	Solo lectura degradada (no afecta operación de nodos)	Cualquiera puede reconstruir el estado desde el contrato on-chain; el dashboard es read-only y reemplazable.
Base L2 RPC lento o fuera	No se publican proofs hasta que vuelva	Reintentos con backoff; los proofs quedan en queue local del edge/worker hasta que el RPC vuelve.
Worker GPU malicioso	Genera proofs falsos	El verifier on-chain rechaza; sin reward. La doble firma (`sigInput` + `sigWorker`) lo asocia y permite invalidar su autorización.

9.3.6 Observabilidad

Métricas: Prometheus en el GPU worker y en la web pública; exporters básicos del RPi (cpu/temp/ram). Etiquetadas por node_id y model_id.
Logs: stdout estructurado (JSON) → Loki. Correlación por inferenceId end-to-end.
Trazas: OpenTelemetry desde el edge (light client) hasta el contrato on-chain (transaction hash como span attribute).
Dashboards Grafana: dashboard interno operacional para el tesista; la web pública (§9.3.1) cubre la visión externa.
Alerting: SLO burn-rate alerts vía webhook (Telegram / email del tesista) durante el piloto.

9.4 Stack tecnológico

Capa	Tecnología	Componente
Captura	PiCamera2	Edge (RPi)
Signing entrada	`cryptography` + secp256k1	Edge (siempre)
Inference	ONNX Runtime (ARM / CUDA)	Edge + GPU worker
zkML Prover	EZKL (Halo2) — binario ARM + binario CUDA	Edge + GPU worker
Signing worker	secp256k1	GPU worker
GPU worker service	FastAPI (Python) + cola HTTP simple	Vast.ai VM
Web pública (backend)	FastAPI (Python) read-only + indexer client	Web pública
Web pública (frontend)	HTML/JS estático + Leaflet + tiles OpenStreetMap	Web pública
Indexer on-chain	The Graph subgraph (o indexer propio con web3.py + Postgres)	Web pública
On-chain submitter	web3.py	Edge / GPU worker
Smart Contract	Solidity 0.8.x + Foundry	On-chain
L2 Chain	Base (OP Stack)	On-chain
Observabilidad	Prometheus + Grafana + OpenTelemetry + Loki	Todos

9.5 Diseño experimental

Experimento 1 — Benchmark de Proving Edge vs Cloud GPU (OE2)

Variable independiente: plataforma (2 backends: Edge ARM / Cloud GPU VM).
Variables dependientes: proof time, peak RAM, proof size, gas cost, costo monetario por proof, speed-up ARM↔GPU.
Réplicas: 30 pruebas por backend. Total: 2 backends × 30 = 60 mediciones.
Plataformas:
- Edge ARM: RPi 4B 4 GB, Raspbian 64-bit, EZKL build ARM.
- Cloud GPU VM: Vast.ai, 1 instancia con EZKL CUDA habilitado (RTX 3090 o equivalente).
Métrica: proof time por backend + curva de speed-up ARM→GPU en función del tamaño del modelo.
Aporte: primera comparación pública lado-a-lado de EZKL on-device en ARM Cortex-A72 contra GPU CUDA para el mismo circuito y dataset.

Experimento 2 — Accuracy del clasificador

Train/val/test split: 70/15/15 sobre dataset combinado (D-Fire + Kaggle Fire Detection + imágenes propias de Sierras Chicas).
Métricas: Accuracy, Precision, Recall, F1, AUC-ROC.
Ablation: INT8 vs FP32; énfasis en minimizar falsos negativos.

Experimento 3 — Integración end-to-end de la red piloto (OE4)

Topología: 3 nodos RPi edge + 1 VM GPU Vast.ai on-demand + web pública de monitoreo + smart contracts en Base Sepolia.
Modos del protocolo: los nodos rotan entre full-edge (proof on-device) y split (witness al GPU worker) durante el período de operación.
Período: 2–3 meses de operación continua en campus UNC.
Métricas: uptime por nodo, latencia end-to-end por modo, costo de gas mensual, distribución de proofs full-edge vs split, frescura del mapa público (Δt entre evento on-chain y aparición en la web), accesos a la web pública.

Experimento 4 — Seguridad del mecanismo DePIN (OE5)

Modelado económico: ¿qué reward mínimo cubre el costo operacional de un nodo edge?
Simulación de ataques: Sybil, replay, worker-malicioso, edge-impostor.
Análisis de degenerate cases: reuso de proofs, colusión edge↔worker, censura del indexer público.

9.6 Modelo a evaluar

Se utiliza un único modelo en ambos backends: MobileNetV3-Small INT8. La elección permite aislar el efecto del backend de cómputo sin confundir la variable con cambios de arquitectura de modelo. El mismo modelo corre en Edge ARM (RPi 4) y en Cloud GPU VM (Vast.ai) y los proof times resultantes son la métrica principal del Experimento 1.

Modelo	Params	Accuracy target	Edge ARM (RPi 4)	Cloud GPU VM (Vast.ai, RTX 3090)
MobileNetV3-Small INT8	~2.5M	~94 %	~10–20 min	~10–20 s

Justificación del modelo: MobileNetV3-Small es la evolución directa de MobileNetV2, para el cual existe evidencia publicada de detección de incendios y humo en hardware edge (ForestGuard, Edge MobileNet, PMC 2025). Con ~2.5M parámetros (vs ~25M de ResNet), la cuantización INT8 reduce el footprint a menos de 1 MB y permite inferencia sub-segundo en RPi 4. El proof time de 10–20 min en ARM es el caso más exigente del benchmark y el que hace visible el trade-off edge vs cloud — que es justamente el resultado que se quiere publicar.

Mitigación: si el proof time en RPi 4 supera 30 min o genera OOM, se activa la Mitigación A (§9.9): CNN custom ultra-pequeña (~100K params) que preserva la demostración end-to-end del protocolo en edge, aunque con menor accuracy.

9.7 Criterios de éxito

Criterio	Mínimo viable	Objetivo
Proof time edge ARM (RPi 4)	< 30 min para algún modelo	< 5 min para al menos un modelo
Proof time Cloud GPU VM (Vast.ai)	< 1 min para modelo edge-tier	< 20 s para MobileNetV3-Small INT8
Speedup EZKL CUDA vs ARM (mismo modelo)	≥ 10×	≥ 50×
Accuracy clasificador	F1 ≥ 0.85	F1 ≥ 0.92
RAM pico proving edge	< 3.5 GB	< 2 GB
Gas verificación	< 500k gas	< 200k gas
Uptime red piloto	≥ 90 %	≥ 95 %
Web pública	Mapa con 3 nodos + historial básico + vista on-chain online	Frescura < 30 s · 100 % de eventos del piloto reflejados

9.8 Alcance mínimo defendible

Si por restricciones de tiempo o técnicas no se alcanza la versión completa, el alcance mínimo defendible exige: los dos backends funcionando (Edge ARM con proof on-device + GPU worker Vast.ai operativo), web pública con al menos el mapa y la vista de eventos on-chain, contrato verificador deployado en Base Sepolia con al menos una transacción exitosa por cada modo (full-edge y split), y benchmark cross-platform Edge vs GPU sobre MobileNetV3-Small INT8 con ≥ 30 réplicas por backend. Esa configuración mínima sigue produciendo el primer benchmark público de EZKL en ARM Cortex-A72 contra GPU CUDA y la web pública auditable, suficiente para CACIC o un workshop internacional.

9.9 Estrategias de mitigación técnica

Dos estrategias de respaldo se documentan explícitamente para preservar el aporte aún si el camino preferido falla. Cada una mantiene la verificabilidad on-chain (que es el aporte criptográfico) aunque sacrifique alguna otra propiedad (privacidad o accuracy).

Mitigación A — Modelo ultra-pequeño custom para preservar viabilidad edge

Cuándo se activa: si el benchmark muestra que MobileNetV3-Small INT8 genera proof en RPi 4 en más de 30 minutos o produce OOM, hay riesgo de que el caso full-edge quede sin demostración funcional. Esa es justamente la propiedad de privacidad máxima que diferencia el edge del backend GPU; perderla diluye el aporte.

Qué hacemos: diseñar y entrenar una CNN custom ultra-pequeña:

Input: 64×64 pixels (grayscale o RGB reducido)
Conv2D(8 filters, 3×3) → BatchNorm → ReLU
Conv2D(16 filters, 3×3) → BatchNorm → ReLU → MaxPool
Flatten → Dense(32) → Dense(2) → Softmax

Parámetros: ~100K.
Proof time target en RPi 4: < 3 minutos.
Trade-off: accuracy cae a ~80–85 % (vs ~94 % de MobileNetV3-Small). Suficiente para PoC del protocolo, no para producción.

Por qué es válido como mitigación y no como solución principal: un accuracy de 80 % es bajo para detección de incendios en producción (alto falso negativo). Pero el aporte de la tesis no es el clasificador — es el protocolo, el benchmark y la web pública. Mostrar que incluso un modelo ultra-liviano funciona end-to-end refuerza el patrón arquitectónico, sin pretender que ese modelo sea desplegable.

Mitigación B — Arquitectura split (ya integrada en el protocolo)

Cuándo se activa: automáticamente, en operación normal. No es un fallback de emergencia: es el segundo modo natural del protocolo cuando el modelo a ejecutar no es proving-friendly on-device.

Qué hacemos: el nodo edge genera el witness firmado y lo envía al GPU worker (Vast.ai), que produce el proof y firma el resultado. La doble firma (sigInput del capture node + sigWorker del GPU) preserva el binding criptográfico entrada → cómputo → reward; el verifier on-chain es el mismo y rechaza cualquier proof inválido independientemente de dónde se generó.

Trade-off explícito:

✅ Verificabilidad on-chain íntegra.
✅ Binding criptográfico preservado (el worker no puede falsificar sigInput).
⚠️ Privacidad reducida: el worker ve el witness (no el frame crudo si se envía solo el embedding, pero sí información derivada).
⚠️ El reward diferenciado por clase de nodo (full-edge > split) queda como trabajo futuro (§11.5); en el piloto el reward es plano.

Conclusión: el modo split es un ciudadano de primera clase del protocolo, no un fallback reactivo. Eso convierte la limitación técnica del edge en una propiedad arquitectónica medible.

Nota de seguridad — Sybil resistance

Un vector no cubierto por las mitigaciones A y B es el ataque Sybil: un operador registra muchos nodos legítimos (con proofs válidas) para drenar desproporcionadamente la treasury de rewards. El mecanismo de defensa actual es authorizeWorker(), que requiere aprobación explícita del owner del contrato para cada dirección de nodo; sin esa autorización, el contrato no emite reward. Este diseño permissioned es suficiente para el piloto pero no escala sin intervención manual. La introducción de stake obligatorio o reputación acumulada como barrera de entrada queda documentada como trabajo futuro (§11.5).

10. Recursos involucrados y cronograma de trabajo

10.1 Recursos de hardware

Recurso	Cantidad	¿Se cuenta con él?
Raspberry Pi 4B 4 GB	3	Acceso gratuito (laboratorio de Sistemas Embebidos)
Raspberry Pi Camera Module v3	3	A adquirir (~$120 USD)
MicroSD 64 GB + case + PSU	3	A adquirir

10.2 Recursos de cómputo en la nube

Recurso	Costo	¿Se cuenta con él?
Vast.ai GPU on-demand (RTX 3090 o equiv.) para benchmark + modo split del piloto (~30–60 hs)	~$30–60 USD	Créditos existentes
Hosting de la web pública (VPS pequeño o Fly.io free tier)	~$0–5 USD/mes	Free tier disponible
Base Sepolia (testnet)	$0	Pública
Base mainnet (gas fees deploy + experimentos)	< $60 USD	Wallet personal

10.3 Recursos de software

EZKL (MIT, build ARM y CUDA), Foundry, ONNX Runtime, FastAPI, Leaflet + OpenStreetMap tiles, The Graph (subgraph) o indexer propio, Prometheus, Grafana, OpenTelemetry, Loki, web3.py, Pillow, scikit-learn, PyTorch + ONNX export. Todos open-source, sin costo de licencia.

10.4 Datasets

D-Fire dataset (público, Kaggle), Fire Detection Dataset (Kaggle), imágenes propias etiquetadas de Sierras Chicas (a recolectar).

10.5 Recursos humanos

Tesista (autor): dedicación part-time de 20–25 hs/semana durante 12 meses (compatible con el cursado de los últimos años).
Director: revisión técnica quincenal y aprobación de hitos.
Codirector embedded: validación del firmware y benchmark de hardware ARM.
Colaboraciones potenciales (no bloqueantes): CONICET Córdoba / Defensa Civil CBA para validación del caso de uso, Satellites on Fire (startup CBA) para acceso a imágenes históricas etiquetadas.

10.7 Cronograma de trabajo

Duración total: 12 meses distribuidos en 5 fases comprimidas. Asumiendo dedicación part-time de 20–25 hs/semana (compatible con el cursado de los últimos años de Ing. en Computación), las 5 fases caben en un año calendario. La versión mínima defendible (§9.8) cabe en 8–9 meses si fuera necesario adelantar la defensa.

Fase	Meses	Entregables
Fase 0 — Preparación	1	Revisión bibliográfica focal (~30 papers core, no exhaustiva); setup de hardware (2 RPi de prueba + acceso a Vast.ai); toolchain (EZKL ARM y CUDA, ONNX Runtime, Foundry, FastAPI); PoC: modelo toy de 3 capas → EZKL → proof generado en RPi y en GPU Vast.ai, ambos verificados por el mismo verifier en Base Sepolia.
Fase 1 — Benchmark Edge vs GPU	2–4	Curación y etiquetado del dataset; entrenamiento y cuantización de MobileNetV3-Small INT8; ejecución de Experimentos 1 + 2 sobre los 2 backends (RPi 4 y Vast.ai); paper parcial (workshop): “Cross-platform Benchmarking of EZKL on ARM Edge vs GPU CUDA”; diseño formal del protocolo VeriFire.
Fase 2 — Protocolo, contratos y web pública	5–7	Light client edge (firmware RPi con modos full-edge y split); GPU worker (FastAPI + EZKL CUDA en Vast.ai); smart contracts (Solidity/Foundry) deployados en Base Sepolia; web pública de monitoreo (FastAPI + Leaflet + indexer subgraph); testing unitario + integración + Experimento 4 (seguridad).
Fase 3 — Red piloto operacional	8–10	Despliegue: 3 RPi en campus UNC + VM Vast.ai on-demand + web pública online; operación continua 8 semanas (Experimento 3); recolección y análisis de datos operacionales; iteración del protocolo y de la UI del mapa.
Fase 4 — Escritura y defensa	11–12	Escritura de la tesis completa (en paralelo con Fase 3 desde mes 9); submisión paper completo a IEEE IoT Journal o ACM SenSys; preparación de la defensa y defensa final (full-edge run).

Margen de seguridad: las fases 1 y 2 solapan parcialmente (el diseño formal del protocolo se puede empezar mientras corre el benchmark). Si una fase se retrasa 2–3 semanas, el cronograma absorbe el corrimiento sin tocar la defensa, recortando del alcance opcional definido en §9.8.

Diagrama de Gantt

10.8 Hitos críticos

Hito	Mes	Entregable
H1	1	PoC: proof funcional en RPi y en GPU Vast.ai, ambos verificados on-chain
H2	4	Benchmark cross-platform completo (Edge ARM vs GPU CUDA × 1 modelo) + workshop paper submited
H3	7	Protocolo VeriFire v1.0 + GPU worker + web pública desplegados en testnet
H4	10	Red piloto (3 RPi + GPU + web pública) operacional 8 semanas — full-edge
H5	11	Paper completo submited a venue primario
H6	12	Defensa

10.9 Gestión de riesgos

Riesgo	Probabilidad	Impacto	Mitigación
EZKL demasiado lento en RPi 4 (> 60 min/proof para todos los modelos)	Media	Medio	El GPU worker absorbe la carga vía modo split; edge lento no es bloqueante — pasa a ser un dato más del benchmark. Mitigación A (§9.9) prepara un modelo ultra-pequeño para preservar la demostración full-edge.
RAM insuficiente edge (OOM durante proving)	Media	Bajo	El GPU worker asume el job; el edge decide local vs split por umbral configurable.
Degradación de accuracy por cuantización extrema	Baja	Medio	Mixed-precision (INT8 convoluciones, FP16 capas críticas).
Costo de gas demasiado alto	Baja	Medio	Base tiene fees << 1 cent. Fallback: off-chain verification + on-chain commitment.
Logística outdoor	Alta	Bajo	Fase 3 empieza en campus UNC; Sierras Chicas opcional.
EZKL introduce breaking changes	Baja	Medio	Pin de versión. El protocolo es prover-agnostic.
Disponibilidad de Vast.ai (instancias on-demand intermitentes)	Media	Medio	El benchmark se planifica en bloques cortos (~2–4 h); para el piloto el modo split degrada a full-edge si la VM no está disponible.
Costo cloud excede presupuesto	Baja	Bajo	Spot instances en Vast.ai; sesiones de benchmark agendadas y acotadas (presupuesto total < $60 USD).
Encryption del witness añade latencia	Baja	Bajo	Hybrid encryption (RSA-OAEP + AES-GCM); medición y reporte explícito.
Web pública con baja frescura (delay del indexer > 1 min)	Media	Bajo	Fallback a polling directo del RPC para el panel de alertas; el resto se sirve desde indexer cacheado.

11. Aportes esperados

11.1 Aporte académico

Cinco contribuciones originales (C1–C5):

C1 — Protocolo VeriFire full-edge: diseño formal de un protocolo de Proof-of-Inference verificable on-chain ejecutable on-device en hardware ARM resource-constrained, con un modo split que permite delegar el proof a un worker GPU preservando el binding criptográfico vía doble firma (sigInput capture + sigWorker GPU). El contrato verificador es agnóstico al backend y se establece como base extensible a clases adicionales (Kubernetes) en trabajo futuro.
C2 — Benchmark empírico Edge vs Cloud GPU: primera evaluación pública sistemática (que se sepa) del trade-off zkML entre ARM Cortex-A72 (Raspberry Pi 4) y GPU CUDA (Vast.ai) para el mismo circuito EZKL y el mismo dataset — proof time, peak RAM, proof size, gas cost, costo monetario por proof, curva de speed-up GPU vs ARM en función del tamaño del modelo.
C3 — Plataforma VeriFire de referencia (open-source): prototipo funcional end-to-end con light client edge (firmware RPi), GPU worker (FastAPI + EZKL CUDA en Vast.ai), web pública de monitoreo georreferenciado (mapa Leaflet/OpenStreetMap + historial de mensajes por nodo + panel de alertas + vista on-chain), smart contracts en Base Sepolia/mainnet, observabilidad Prometheus + Grafana + OpenTelemetry, dataset público de imágenes humo/fuego.
C4 — Metodología de diseño de circuitos zkML “edge-aware”: guía con reglas prácticas derivadas del benchmark — qué arquitecturas de modelo son proving-friendly en RPi 4, dónde está el knee-point del edge, qué nivel de cuantización preserva la viabilidad del circuito, en qué condiciones conviene delegar al GPU.
C5 — Patrón “DePIN auditable”: patrón de diseño reutilizable que combina (a) verificabilidad criptográfica on-chain, (b) cómputo on-device con privacidad máxima y (c) auditoría pública sin login vía web georreferenciada que cualquier ciudadano u organismo puede inspeccionar. La intersección de estos tres ejes no está documentada en la literatura DePIN actual.

11.2 Aporte técnico

Repositorio open-source con la implementación completa (license MIT/Apache-2): firmware RPi, GPU worker, web pública (backend + frontend), contratos, scripts de despliegue y subgraph del indexer.
Una web pública desplegada (capturable como caso de estudio) con mapa de nodos del piloto en Córdoba.
Dataset público de imágenes etiquetadas de humo/fuego de la zona Sierras Chicas.

Caso de uso transferible al ETAC / Defensa Civil de Córdoba para detección temprana de incendios, reduciendo la latencia de detección de 35–60 min (satelital) a minutos (red densa edge).
Transparencia ciudadana: cualquier persona u organismo puede auditar el estado de la red, ver dónde están los nodos, qué inferencias firmaron y qué eventos quedaron on-chain — sin pedir permiso a un operador centralizado.
Modelo de negocio compatible con financiamiento público (un municipio o Defensa Civil paga un fee por acceso a alertas) o financiamiento descentralizado (DePIN puro), cuyas condiciones de sustentabilidad la tesis modela formalmente.

11.4 Aporte económico y de mercado

Habilitación de cómputo verificable para sensing con costo de entrada bajo (una Raspberry Pi alcanza para operar un nodo, sin necesidad de GPU propia ni cluster).
Validación de una arquitectura full-edge auditable para DePIN, replicable a otros dominios de sensing (calidad de aire, ruido, tráfico, plagas agrícolas, monitoreo de fauna).

11.5 Trabajos futuros

Los siguientes ejes se documentaron como fuera del alcance de la tesis pero ya tienen sustento bibliográfico (§8.4 los referencia como literatura base). Constituyen la extensión natural de VeriFire y se publicarán como roadmap post-defensa:

F1 — Tercer backend Kubernetes (CPU paralelo): incorporación de un cluster K8s como tercer backend, con Jobs nativos para proof generation, Deployment para model serving, Helm chart distribuible, auto-scaling con KEDA/HPA por queue depth, NVIDIA GPU Operator para nodos GPU. Benchmark CPU-pods paralelizados vs GPU CUDA single-node para cuantificar el trade-off costo-latencia en cluster real.
F2 — Plataforma SaaS multi-tenant: control plane con FastAPI + Postgres con Row-Level Security, namespace isolation en K8s, onboarding permissioned de tenants, SLOs por tenant, rate-limiting, métricas Prometheus etiquetadas por tenant_id. Mantendría la web pública actual como vista “global del operador” y agregaría dashboards privados por tenant.
F3 — Reward diferenciado por clase de nodo y capability attestation on-chain: extensión del contrato verificador para emitir reward más alto a EDGE (proof on-device, máxima privacidad) que a CLOUD/K8S (modo split, privacidad reducida); modelado tokenomic completo y simulaciones de incentivo.
F4 — Orquestación avanzada: Job Router que decide CPU vs GPU vs Edge según resource hints del modelo, SLA del tenant y costo operacional; auto-scaling reactivo a picos de eventos; contrato relayer para batchear submissions on-chain.
F5 — Despliegue provincial: coordinación con ETAC / Defensa Civil de Córdoba para desplegar la red en Sierras Chicas a escala (≥ 20 nodos), incluyendo logística outdoor (paneles solares, gabinete IP65, LoRaWAN como backup de conectividad).
F6 — Onboarding permissionless: reemplazo de authorizeWorker() por mecanismo de stake o reputación on-chain, de modo que cualquier operador pueda sumarse sin aprobación manual.
F7 — Multi-cadena y portabilidad del verifier: portar el contrato a otros L2 (Optimism, Arbitrum) y eventualmente a no-EVM (Solana, Polkadot via zkVerify).

11.6 Resultados esperados cuantitativos (hipótesis falsables)

A diferencia de una propuesta de “experimento abierto”, la tesis se compromete con hipótesis cuantificables que pueden ser confirmadas o refutadas por los experimentos. Las bandas reflejan incertidumbre razonable basada en la literatura existente de zkML.

#	Hipótesis	Métrica esperada	Banda de incertidumbre
H1	Speedup EZKL CUDA vs ARM en proof generation crece con el tamaño del modelo	10×–100× para modelos ≤ 5 M params	±50 % por modelo
H2	Knee-point edge: hay un tamaño máximo de modelo viable en RPi 4	~2–5M params (proof time < 30 min, RAM < 3.5 GB)	sensible a versión EZKL
H3	Pareto edge: existe un modelo viable on-device con accuracy aceptable	MobileNetV3-Small INT8 (único modelo evaluado)	accuracy ≥ 94 %, proof < 20 min edge / < 20 s GPU
H4	Costo por proof verificado on-chain (Base L2)	< $0.005 USD por verificación	factor 2× según gas price
H5	Tamaño del proof EZKL on-chain	10–50 KB	depende del circuito
H6	Frescura de la web pública (Δt evento on-chain → mapa)	< 30 s P95	depende del indexer
H7	Falsos negativos del clasificador en humo controlado	< 5 %	crítico para caso de uso
H8	Mínimo reward económico para sustentabilidad del nodo edge	$0.50–$1.50 USD / día por nodo activo	depende de costo eléctrico local

Interpretación de los resultados: si H1, H2 y H4 se confirman, el aporte C2 (benchmark Edge vs GPU) es un resultado publicable independientemente del resto. Si H6 se confirma, el aporte C3 (plataforma + web pública auditable) es defendible. Si alguna hipótesis se refuta, el resultado negativo también es publicable — eso es lo que diferencia ciencia de ingeniería.

12. Referencias bibliográficas

(Formato IEEE — versión preliminar; se ampliará durante la revisión sistemática de la Fase 0.)

zkML

[1] Y. Zhang et al., “A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning,” arXiv preprint arXiv:2502.18535, Feb. 2025.

[2] Springer Nature, “A survey of zero-knowledge proof based verifiable machine learning,” Artif. Intell. Rev., 2026.

[3] EZKL Team, “Benchmarking ZKML Frameworks,” blog.ezkl.xyz, 2025. [Online]. Available: https://blog.ezkl.xyz/post/benchmarks/

[4] EZKL Team, “State of EZKL: 2025,” blog.ezkl.xyz, 2025. [Online]. Available: https://blog.ezkl.xyz/post/state_of_ezkl/

[5] ICME, “The Definitive Guide to ZKML (2025),” blog.icme.io, 2025.

[6] Lagrange Labs, “DeepProve-1: First zkML System to Prove Full LLM Inference,” lagrange.dev/blog, 2025.

[7] “On-chain zero-knowledge machine learning: An overview and comparison,” ScienceDirect, 2024.

Edge AI / Fire Detection

[8] “Edge-Based Autonomous Fire and Smoke Detection Using MobileNetV2,” PMC, 2025. PMC12567645.

[9] “ForestGuard: An IP66 Edge-AI Raspberry Pi Node for Illegal Logging and Early Fire/Smoke Detection,” IJSRA, 2025.

[10] “ForestProtector: IoT Architecture with Deep RL for Wildfire Monitoring,” arXiv preprint arXiv:2501.09926, 2025.

[11] “Tiny Machine Learning and On-Device Inference: A Survey,” PMC, 2025.

[12] “Real-Time Performance Benchmarking of TinyML Models,” arXiv preprint arXiv:2509.04721, 2025.

DePIN y blockchain edge

[13] “Decentralized physical infrastructure networks (DePIN) tokenomics,” Frontiers in Blockchain, 2025.

[14] “Blockchain-Enabled Edge Intelligence for IoT,” MDPI Future Internet, vol. 13, no. 2, 2021.

[15] “Secure blockchain integrated deep learning framework for IoT edge intelligence,” Scientific Reports, Nov. 2025.

[16] zkVerify Team, “2025: Year in Review,” zkverify.io/blog, 2025.

Kubernetes y plataformas cloud-native

[17] B. Burns et al., Kubernetes Patterns: Reusable Elements for Designing Cloud Native Applications, 2nd ed. O’Reilly Media, 2023.

[18] J. Dobies, J. Wood, Kubernetes Operators: Automating the Container Orchestration Platform, O’Reilly Media, 2020.

[19] CNCF, “KEDA: Kubernetes Event-driven Autoscaling,” keda.sh, 2025.

[20] OpenTelemetry, “Observability Framework,” opentelemetry.io, 2025.

Contexto local

[21] “En 2024 se quemaron casi 70.000 hectáreas de bosque nativo en Córdoba,” elDiarioAR, 2024.

[22] “La startup argentina que detecta incendios forestales antes que la NASA,” Perfil, 2024.

[23] “Informe sobre incendios forestales en Córdoba, septiembre 2024,” Defensoría del Pueblo de la Nación, 2024.

[24] “Córdoba redujo más del 80 % la superficie afectada en 2025,” La Ranchada, 2025.

Anexo B — Preguntas frecuentes conceptuales

B.1 ¿Cómo ayuda esto a prevenir incendios?

No previene — detecta temprano. La diferencia es crítica: un incendio detectado en los primeros 5 minutos se puede apagar con una motobomba y 2 personas. El sistema de referencia actual (satélites) tarda 35–60 min; una red densa de cámaras edge puede detectar humo en minutos, 24/7, sin operador.

B.2 ¿Una persona externa puede aportar con cámara o cómputo? ¿Y si muestra un incendio falso?

Sí — ese es el modelo DePIN. Sin zkML el problema sería trivial: cualquier nodo podría mandar “humo” sin haber corrido el modelo. Con zkML el contrato no acepta el resultado sin prueba matemática. Lo que sí es posible es input fraud (mostrar una imagen guardada de fuego al sensor), que se mitiga con multi-testigo (si un solo nodo grita “fuego” y los vecinos no, la alerta se marca como sospechosa).

B.3 ¿Por qué se necesitan varias Raspberry Pi y no una sola?

Para la tesis: con un solo nodo no se puede medir el comportamiento de la red (uptime distribuido, fallas, visualización geoespacial con múltiples marcadores). Con 3 RPi + GPU worker on-demand + web pública se hacen experimentos reales de red full-edge. Para el caso de uso: una cámara cubre un ángulo limitado de un cerro; la visión es que muchas personas pongan cámaras formando una red densa.

B.4 ¿El sistema crea un token propio o usa uno existente?

Para la tesis crea un token propio (VeriFireToken, ERC-20) sin valor económico real, igual que una tesis de redes crea una red privada. Si escalara a producción, la decisión sería usar un token existente (USDC, ETH) o emitir uno con distribución real.

B.5 ¿Quién pone el dinero que reciben los operadores?

La pregunta más incómoda del modelo DePIN. Tres modelos posibles: emisión inflacionaria (token sin demanda no vale), consumidores pagan (un municipio o aseguradora paga por las alertas — sostenible pero requiere clientes), subsidio inicial (centralizado). La tesis modela formalmente bajo qué condiciones el sistema es autosustentable.

B.6 ¿Esto sirve solo para Sierras de Córdoba o escala como SaaS?

El protocolo y la implementación son agnósticos a la región: cualquier organización puede reusar el firmware, deployar el contrato y servir su propia web pública. La extensión a una plataforma SaaS multi-tenant con aislamiento por tenant queda documentada en §11.5 como trabajo futuro. Sierras Chicas es el caso de uso ancla; el aporte académico es el protocolo + benchmark + web pública.

B.7 ¿Por qué dos backends (Edge y GPU)? ¿Por qué no más?

Dos backends son los extremos del espacio: el edge (máxima privacidad, mínimo costo de hardware) y la GPU cloud (máximo throughput). Comparar lado a lado los extremos responde la pregunta central de la tesis — cuándo es viable el edge y cuándo conviene delegar al GPU. Agregar un tercer backend (cluster K8s CPU) duplicaría el alcance experimental sin agregar un eje cualitativamente nuevo; queda documentado como F1 en §11.5 (trabajos futuros).

B.8 ¿Las imágenes se almacenan en la blockchain?

No. Solo va on-chain: hash de la imagen (32 bytes), resultado (1 byte), proof (~10–50 KB), firmas (~130 bytes). El frame queda en el RPi y se descarta.

B.9 ¿Para qué probar la integridad del cómputo si asumo que la imagen es real?

Porque son dos propiedades distintas. zkML resuelve integridad del cómputo (corrí el modelo acordado sobre alguna imagen) pero no autenticidad de la entrada (la imagen vino del sensor físico ahora). Sin zkML un nodo podría hardcodear resultado=1 durante una ola de calor para cobrar el reward alto. La tesis declara explícitamente el límite del threat model.

Anexo C — Glosario técnico

Blockchain — Base de datos compartida entre miles de computadoras que nadie controla individualmente.

Smart contract — Programa que vive dentro de la blockchain y se ejecuta automáticamente cuando se cumplen ciertas condiciones.

ERC-20 — Estándar para crear tokens digitales en redes compatibles con Ethereum.

Base (L2) — Red blockchain construida sobre Ethereum con transacciones mucho más baratas y rápidas.

DePIN — Decentralized Physical Infrastructure Network. Modelo donde personas comunes contribuyen con hardware físico a una red compartida y reciben tokens automáticamente.

ONNX — Formato estándar para guardar modelos de machine learning (como un PDF de redes neuronales).

TinyML — Rama del ML que optimiza modelos para correr en dispositivos de muy bajos recursos (cuantización, pruning).

Cuantización (INT8) — Compresión que guarda los pesos como enteros de 8 bits en vez de flotantes de 32 bits (4× reducción, < 5 % pérdida de accuracy en clasificación binaria).

MobileNetV3 — Red neuronal convolucional para edge: ~2.5M parámetros (vs ~25M en ResNet o ~138M en VGG-16).

ZKP / Zero-Knowledge Proof — Técnica criptográfica para probar que sabés algo sin revelar el detalle.

zkML — Aplicación de ZKPs a machine learning. Permite probar que un modelo fue ejecutado correctamente sobre cierta entrada sin revelar la entrada.

EZKL — Herramienta open-source que implementa zkML: convierte modelos ONNX en circuitos Halo2 y exporta el verifier como contrato Solidity. Tiene builds tanto para ARM (RPi) como para CUDA (GPU).

Halo2 — Sistema de pruebas ZK del equipo de Zcash, backend criptográfico de EZKL.

SNARK / zk-SNARK — Tipo de ZKP con propiedades deseables: prueba pequeña (Succinct), verificable rápido (Non-interactive), sin revelar info privada (Argument of Knowledge).

Circuito aritmético — Representación matemática de un programa como ecuaciones sobre números, forma en que los sistemas ZK “entienden” el cómputo.

Hash (SHA-256) — Función que toma cualquier dato y produce un número fijo. Imposible reconstruir el original desde el hash.

Proof / Witness — En zkML el witness son los datos privados que el prover conoce (imagen, pesos, cálculos intermedios); el proof es la prueba pública compacta. Solo el proof sale del nodo.

Solidity — Lenguaje de programación para smart contracts en redes EVM.

Foundry — Suite de herramientas para desarrollo de smart contracts en Solidity (compilador + tests + deploy).

Raspberry Pi 4 — Computadora de placa única (~$80 USD), procesador ARM Cortex-A72 4 núcleos 1.8 GHz, hasta 8 GB RAM.

ARM Cortex-A72 — Procesador ARM optimizado para eficiencia energética. Los benchmarks públicos de EZKL existentes son en x86; esta tesis benchmarkea ARM contra GPU CUDA por primera vez.

Vast.ai — Marketplace de instancias GPU on-demand (RTX 3090 / 4090 / A100) que la tesis usa como GPU worker remoto para el modo split del protocolo y para el benchmark contra ARM.

Modo full-edge vs modo split — Los dos modos del protocolo. Full-edge: el RPi genera el proof on-device (privacidad máxima). Split: el RPi firma el witness y lo envía al GPU worker, que produce el proof y firma con sigWorker.

OpenStreetMap / Leaflet — Stack open-source para renderizar el mapa interactivo de nodos en la web pública de monitoreo.

Indexer / subgraph — Servicio que escucha eventos del contrato on-chain y los cachea en una base de datos para que la web pública pueda consultarlos sin golpear al nodo RPC en cada request.

Threat model — Descripción explícita de qué ataques un sistema pretende resistir y cuáles quedan fuera de scope.

Replay attack — Ataque donde un nodo reutiliza una prueba válida para cobrar rewards múltiples veces. Se previene con un registro on-chain de hashes ya usados.

Kubernetes (K8s) — Sistema open-source para orquestar aplicaciones en contenedores. Referenciado en §8.4 y §11.5 como base del trabajo futuro; no se usa en esta tesis.

Helm — Gestor de paquetes para Kubernetes (análogo a apt o npm). Trabajo futuro (§11.5).

SaaS — Software-as-a-Service. Modelo donde un proveedor opera un servicio que múltiples clientes consumen sin instalarlo localmente.

Multi-tenant — Arquitectura donde un único deployment del software sirve a múltiples organizaciones independientes con aislamiento entre ellas. Trabajo futuro (§11.5); la web pública actual es global y sin tenants.

HPA / KEDA — Mecanismos de auto-scaling en Kubernetes. Trabajo futuro (§11.5).

Row-Level Security (RLS) — Característica de Postgres que define políticas a nivel de fila para controlar qué registros ve cada usuario. Trabajo futuro (§11.5).

Backend (de cómputo) — En esta tesis, una clase de hardware donde se puede generar el proof zkML: edge (Raspberry Pi 4, ARM Cortex-A72) o cloud GPU (VM Vast.ai con EZKL CUDA). Backends adicionales (clusters K8s CPU paralelizados, multi-GPU) quedan como trabajo futuro (§11.5).

Anexo D — Plan de difusión open-source

VeriFire se libera bajo el principio de que el aporte académico se multiplica si la comunidad puede continuar el trabajo. Esta sección define cómo se publica el repositorio para que sobreviva a la defensa de la tesis.

D.1 Licenciamiento

Componente	Licencia	Razón
Smart contracts (Solidity)	MIT	Estándar en Ethereum / Base; permite forks comerciales sin retribución obligatoria
Operador K8s + Helm chart	Apache 2.0	Estándar CNCF; cláusula de patentes
Light client edge (Python)	MIT	Compatible con dependencias upstream
Control plane SaaS (Python/FastAPI)	MIT
Dataset etiquetado de humo/fuego (Sierras CBA)	CC BY 4.0	Atribución requerida; uso comercial permitido
Tesis (texto del documento)	CC BY-NC-SA 4.0	Académica: atribución, no comercial, share-alike

D.2 Repositorio

Host: GitHub bajo organización licdia-unlu o verifire-network (a definir con el director).
CI/CD: GitHub Actions con workflows para tests unitarios (pytest, foundry test), build de imágenes Docker, publish del Helm chart a un registry público (ghcr.io).

D.3 Política de contribuciones

CONTRIBUTING.md define proceso: fork → branch → PR → 1 reviewer del equipo core + CI passing.
Code of Conduct: Contributor Covenant 2.1.
Issue templates: bug report / feature request / question.
Security policy (SECURITY.md): disclosure responsable de vulnerabilidades del contrato a security@verifire.example (alias del director / autor).

Documento preparado: mayo 2026. Versión 2.

VeriFire — Propuesta de Tesis (v2)

Plataforma SaaS multi-backend (Edge / Cloud / Kubernetes) de inferencia verificable con zkML para redes DePIN de monitoreo ambiental — Alex Agustín Hernando, Dir. Dr. David Petrocelli

Universidad Nacional de Córdoba · FCEFyN · Ingeniería en Computación · Mayo 2026

Título tentativo: VeriFire: Plataforma SaaS multi-backend de inferencia verificable (Edge / Cloud / Kubernetes) para redes DePIN de monitoreo ambiental


Autor	Alex Agustín Hernando
Director	Dr. David Petrocelli — LICDIA UNLu / Caylent USA
Codirector (edge / embedded)	Cátedra de Sistemas Embebidos — FCEFyN UNC
Codirector (cloud-native / sistemas distribuidos)	Cátedra de Sistemas Distribuidos / Cloud Computing — FCEFyN UNC
Espacio curricular	Trabajo Final / Tesis de grado
Fecha	Mayo 2026

1. Título

VeriFire: Plataforma SaaS multi-backend de inferencia verificable con zkML para redes DePIN de monitoreo ambiental, con caso de uso ancla en detección temprana de incendios en las Sierras de Córdoba.

2. Resumen

Esta tesis propone el diseño, implementación y evaluación de VeriFire, una plataforma Software-as-a-Service multi-tenant que combina inferencia de machine learning verificable con pruebas zkML (Zero-Knowledge Machine Learning) para habilitar redes DePIN (Decentralized Physical Infrastructure Networks). En estas redes cada operador puede demostrar criptográficamente que ejecutó correctamente una inferencia sobre datos reales —sin revelar el dato crudo—, la prueba se verifica en cadena y activa un reward económico diferenciado por clase de nodo.

El aporte central es una arquitectura desacoplada entre dónde se ejecuta el cómputo (edge IoT, cloud VM, cluster Kubernetes) y cómo se verifica (un único contrato on-chain agnóstico al backend). Un mismo protocolo de input-binding criptográfico admite tres clases de “Compute Backend” con distintos trade-offs de privacidad, costo y escalabilidad, todas verificadas uniformemente en una red EVM (Base L2). Esta arquitectura habilita escalar a múltiples regiones y tenants como SaaS, y a operadores de cómputo heterogéneos (desde Raspberry Pi de un hobbyista hasta clusters K8s corporativos).

El caso de uso ancla es la detección temprana de incendios en las Sierras de Córdoba mediante una red de cámaras de bajo costo, problema socialmente relevante (~70.000 hectáreas quemadas en 2024). El aporte académico, sin embargo, no es el sistema de detección sino la dupla protocolo + plataforma transferible a cualquier DePIN de sensing.

La metodología incluye benchmark experimental cross-platform (ARM edge vs x86 cloud GCP vs pod K8s) del trade-off accuracy / latencia / RAM / costo de gas; implementación end-to-end (firmware, operador K8s, control plane SaaS, smart contracts) en una red piloto multi-backend; análisis de seguridad del mecanismo y modelado económico del reward por clase. Los aportes esperados se publican como tres papers complementarios: workshop sobre zkML cross-platform, paper de plataforma cloud-native, y paper completo de la red DePIN.

3. Área temática

Área principal

Blockchain y aplicaciones descentralizadas (DApps).

Subáreas

DePIN — Decentralized Physical Infrastructure Networks.
Inferencia verificable on-chain (zkML) — Zero-Knowledge Machine Learning aplicado a redes con incentivo económico.
Smart contracts y tokenomics — Solidity, Foundry, EVM, mecanismos de reward multi-clase.
Arquitecturas cloud-native (Kubernetes) y plataformas SaaS multi-tenant para AI — operadores K8s, model serving, auto-scaling, multi-tenancy.
Edge AI / IoT — TinyML cuantizado, firmware en hardware resource-constrained.
Criptografía aplicada — Zero-Knowledge Proofs, SNARKs, protocolos de input-binding.

Clasificación ACM CCS 2012

Security and privacy → Cryptography → Distributed systems security
Security and privacy → Cryptography → Public key (asymmetric) techniques → Digital signatures
Theory of computation → Cryptographic protocols → Interactive proof systems
Computer systems organization → Distributed architectures
Computing methodologies → Machine learning approaches

4. Palabras claves

zkML, DePIN, Kubernetes, edge AI, blockchain.

5. Fundamentación de la investigación

Las sierras de Córdoba concentran uno de los problemas ambientales más graves de la Argentina central:

2024: ~70.000 hectáreas de bosque nativo quemadas — más del triple de la superficie de CABA. El incendio en la zona de Capilla del Monte / San Marcos Sierras alcanzó 42.046 ha en un solo evento.
2025: mejora significativa (~21.000 ha afectadas, 80 % menos que 2024), atribuida a detección más temprana y coordinación mejorada del ETAC.
La detección temprana es el factor diferencial crítico: un incendio detectado en sus primeros 5 minutos puede controlarse con recursos mínimos; uno detectado tarde requiere decenas de dotaciones y aviones hidrantes.

Los sistemas actuales de detección presentan limitaciones: la detección satelital (NASA FIRMS, Copernicus, Satellites on Fire) tiene latencia de 35–60 minutos; las cámaras 360° fijas en torres ETAC tienen cobertura limitada y costo alto; los drones requieren operador y no son autónomos 24/7. No existe en Córdoba una red de sensores de bajo costo, densa, que opere 24/7 con latencia de minutos y que sea privacy-preserving.

5.2 Interés científico: el problema de la confianza en redes distribuidas de sensores

Una red de sensores distribuida con incentivos económicos requiere resolver un problema fundamental: ¿cómo saber que el nodo realmente ejecutó el modelo sobre datos reales y no simplemente mintió el resultado para cobrar el reward?

Las soluciones existentes —oráculos centralizados, multi-witness al estilo Helium, TEEs (Intel SGX / ARM TrustZone)— tienen limitaciones de privacidad, requerimiento de hardware específico, o vulnerabilidades documentadas. zkML es la única solución que preserva privacidad y provee verificabilidad sin terceros, pero hasta 2025–2026 no existe ninguna implementación evaluada en hardware edge IoT resource-constrained ni una plataforma que orqueste pruebas zkML a escala con compute heterogéneo (edge + cloud + K8s).

5.3 Interés técnico: cómputo heterogéneo y plataformas DePIN

La mayoría de los DePINs actuales asumen una clase única de hardware (Helium = hotspots; Filecoin = storage nodes; Hivemapper = dashcams). Esto los hace rígidos: no pueden absorber operadores con GPUs ociosas, no escalan a modelos grandes, y no resisten picos de carga. Una arquitectura multi-backend con compute pluggable, validada experimentalmente, sería un patrón de diseño reutilizable para la próxima generación de DePINs.

5.4 Interés personal y formativo

La tesis articula los cuatro ejes técnicos del autor: blockchain (smart contracts, tokenomics), arquitectura cloud-native (Kubernetes operators, SaaS multi-tenant), AI escalable (model serving, GPU pipelines) y criptografía aplicada (zkML). Es un trabajo de tesis con riesgo técnico medio-alto pero alto potencial de impacto académico (publicaciones tier A) y social (transferencia al ETAC / Defensa Civil CBA).

6. Descripción del tema de estudio

6.1 Definición del tema

El tema central es el diseño y validación experimental de protocolos y plataformas de inferencia verificable on-chain con cómputo heterogéneo, aplicados a redes DePIN de sensing ambiental. Se ubica en la intersección de cuatro áreas:

Área	Aporte específico al tema
Blockchain	Smart contracts verificadores multi-clase, tokenomics, replay protection, capability attestation
AI · Arquitectura escalable cloud-native + Plataforma SaaS	Operadores K8s, model serving, auto-scaling con KEDA/HPA, GPU pipelines, multi-tenant isolation, observabilidad; control plane multi-tenant, abstracción de Compute Backend, routing de jobs, SLOs por tenant
Edge AI / IoT	TinyML cuantizado, firmware RPi, light client
zkML / criptografía	Circuitos SNARK (EZKL/Halo2), input-binding, doble firma

6.2 Distribución porcentual del aporte

Área	%	Descripción del aporte
Blockchain	25 %	Smart contract verificador multi-backend (Solidity + Foundry + Base L2); reward ERC-20 con diferenciación por clase de nodo; contrato EZKL Verifier auto-generado; protocolo on-chain (replay protection, node-class binding, event emission).
AI · Arquitectura Escalable Cloud-Native + Plataforma SaaS	45 %	Capa K8s / cloud-native: operador para Proof Workers + serving de modelos (CRDs `InferenceJob` y `ModelServing`); Helm chart; auto-scaling horizontal con KEDA / HPA y métricas custom; multi-tenant isolation por namespace; model registry y versionado on-chain del modelo; observabilidad (Prometheus + Grafana + OpenTelemetry); pipelines GPU-aware. Capa SaaS / sistemas distribuidos: control plane multi-tenant (REST API + dashboard); registro y onboarding de nodos heterogéneos; abstracción “Compute Backend” detrás de interfaz uniforme; routing de jobs según capacidad, latencia y costo; SLOs por tenant.
Edge AI / IoT	15 %	TinyML (MobileNetV3 / EfficientNet-Lite cuantizados INT8); firmware RPi 4 (captura → inferencia → proof → submit); métricas accuracy / F1 / AUC-ROC; light client.
zkML / Criptografía	15 %	Circuito SNARK de inferencia via EZKL (Halo2); protocolo de input-signing (hash binding entrada → proof) independiente del backend de cómputo; benchmark cross-platform (ARM vs x86 vs GPU); análisis del threat model criptográfico.

6.3 Límites del tema

Está incluido en el alcance: - Diseño formal del protocolo VeriFire (input-binding, doble firma, contrato multi-clase). - Implementación de referencia open-source: light client edge, cloud worker, operador K8s, control plane SaaS, smart contracts. - Benchmark experimental en al menos dos backends de cómputo (edge + uno más). - Red piloto multi-backend operacional con dos tenants ficticios. - Análisis de seguridad del mecanismo y modelado económico. - Caso de uso ancla: clasificación binaria humo / no-humo.

Queda fuera del alcance: - Despliegue a producción a escala provincial (es trabajo futuro). - Análisis legal/regulatorio del token. Aclaración explícita: el VeriFireToken es un ERC-20 de testnet (Base Sepolia), sin valor económico, sin distribución pública, sin oferta a terceros. La tesis no genera ningún instrumento financiero regulable bajo MICA, SEC ni la CNV argentina; el token es un constructo de laboratorio análogo a una “red privada” en una tesis de redes. - Hardware custom: la tesis usa RPi 4 estándar como representante del edge, no diseña placas propias. - Modelos generativos o LLMs de visión: el trabajo se enfoca en clasificadores binarios cuantizados. - Multi-cadena: el contrato corre solo en Base (EVM); portar a Solana/Polkadot es trabajo futuro. - Política de upgrade en producción del modelo y del verifier: se documenta en la tesis (qué pasa cuando se reentrena el modelo y cambia el IEZKLVerifier, qué grace period existe, cómo se invalidan los proofs viejos), pero no se ejercita en operación real porque el modelo no se reentrena durante el piloto.

6.5 Justificación cuantitativa de la red piloto

La elección de 3 nodos edge + 1 cloud worker + 1 cluster K8s mínimo no es arbitraria: es el mínimo capaz de validar las propiedades centrales del sistema sin sobre-dimensionar.

Propiedad a validar	Por qué 3 RPi alcanzan
Tolerancia a fallos del data plane	Con 3 nodos podemos simular caída del 33 % (1 nodo offline) y verificar que el control plane y los otros 2 siguen operativos sin degradación visible.
Multi-witness mínimo para alertas	3 cámaras geo-distribuidas en el campus permiten implementar el quórum básico “≥ 2 nodos coinciden en humo” para descartar input-fraud (un solo nodo gritando “fuego”).
Heterogeneidad operacional	Cada RPi puede correr una clase distinta del clasificador (custom CNN, MobileNetV3-Tiny, MobileNetV3-Small) para validar que el routing y la verificación toleran heterogeneidad de modelo dentro del mismo tenant.
Routing entre clases de backend	Con 3 capture nodes + cloud + K8s, el Job Router enfrenta el caso real “cuándo conviene enviar a cloud vs procesar local”: eso solo se puede observar con ≥ 3 nodos pidiendo cómputo simultáneo.
Aislamiento multi-tenant	2 tenants × 3 nodos = 6 endpoints diferentes contra el mismo control plane, suficiente para validar RLS en Postgres y namespace isolation en K8s.

Escalar a 5 o 10 nodos no agrega propiedades nuevas que validar — solo agrega más datos a las mismas mediciones. Por eso la red piloto se acota a 3 RPi y el resto se documenta como trabajo futuro.

6.6 Trabajo previo del autor (evidencia de viabilidad)

Antes de presentar esta propuesta, el autor cuenta con los siguientes assets que reducen el riesgo técnico:

PoC EZKL en RPi 4 funcional (modelo CNN custom de 3 capas, INT8) que genera y verifica proofs localmente — demuestra que el toolchain ARM+EZKL es operativo en el hardware target.
Smart contract Solidity básico (Verifier auto-generado por EZKL + reward simple) deployado en Base Sepolia, ya verificando una prueba real generada en RPi.
Familiaridad con Kubernetes y operadores vía cursado de la diplomatura LICDIA y experiencia previa con Helm/k3s.
Acceso institucional a hardware de laboratorio (RPi de cátedra de Sistemas Embebidos, cluster k3s on-prem disponible en FCEFyN).

Esta no es una propuesta especulativa: el camino crítico (proof EZKL → verifier on-chain en hardware edge real) ya está validado en versión mínima. El trabajo de tesis consiste en escalar y completar esa base con multi-backend, multi-tenant SaaS, operador K8s, y benchmark sistemático.

6.7 Deep dive del aporte: dónde está la novedad

Cada uno de los cinco campos involucrados (Blockchain, AI/Cloud-native, SaaS, Edge AI/IoT, zkML) tiene literatura madura por separado. La novedad de esta tesis no está dentro de ningún campo individual sino en la intersección de los cinco, donde no hay implementación académica publicada.

Diagrama de intersecciones (Venn de cinco campos)

Lectura del diagrama: cada bolita es un campo con literatura propia y madura. La estrella ★ central marca el espacio de los cinco simultáneamente — donde no hay implementación académica publicada y donde se ubica el aporte de esta tesis.

Lo que ya existe (y no es el aporte)

Intersección	Quién la ocupa	Por qué no alcanza
Blockchain ∩ zkML	Inference Labs (Bittensor), zkVerify, Modulus Labs	Datacenter only, no edge, no multi-backend, no SaaS multi-tenant
Blockchain ∩ DePIN ∩ IoT	Helium, Hivemapper, Geodnet	Sin verificabilidad criptográfica del cómputo (multi-witness ≠ zkML)
AI ∩ Cloud-native ∩ K8s	KServe, Kubeflow, Ray Operator	No hay integración con verificación on-chain ni proof generation pipelines
Edge AI ∩ IoT ∩ TinyML	ForestGuard, MobileNetV2 fire detection	Sin blockchain, sin verificabilidad, sin compute heterogéneo
zkML ∩ Edge	(literatura agnóstica)	Surveys identifican explícitamente la ausencia de evaluaciones edge IoT resource-constrained

Lo que esta tesis ocupa por primera vez

La intersección ★ donde se cruzan los cinco campos, materializada en cinco contribuciones (C1–C5) que se detallan en §11.1:

Protocolo zkML multi-backend con doble firma (Blockchain ∩ zkML ∩ Cloud-native).
Benchmark cross-platform en cuatro clases de hardware (zkML ∩ Edge ∩ Cloud-native ∩ AI).
Plataforma SaaS de referencia open-source (Cloud-native ∩ SaaS ∩ Blockchain ∩ Edge).
Metodología de circuitos zkML “backend-aware” (zkML ∩ AI ∩ Edge).
Patrón arquitectónico DePIN heterogéneo (Blockchain ∩ Cloud-native ∩ SaaS).

Por qué esta intersección es difícil (y por qué nadie la ocupó todavía)

Cross-disciplinar: requiere dominar cinco campos que normalmente viven en silos académicos distintos (criptografía, sistemas distribuidos, ML embebido, blockchain, cloud-native).
Hardware-in-the-loop: la mayoría de los papers de zkML no tocan hardware real; los que lo hacen no abordan multi-backend.
Costo experimental: correr 4 backends × 6 modelos × 30 réplicas + red piloto operacional 2–3 meses requiere una inversión coordinada que rara vez se justifica para un solo paper.
Caso de uso anclado en realidad: muchas propuestas teóricas no se molestan en validar contra un dominio social concreto (incendios CBA), lo cual deja la novedad sin “pegada” práctica.

Riesgo controlado del aporte

Si por motivos técnicos no se logra la versión completa, el aporte se preserva con dos backends (alcance mínimo defendible §9.8) — sigue siendo la primera intersección publicada de los campos. La granularidad del benchmark se reduce, pero la categoría de aporte sobrevive.

7. Planteamiento del problema de estudio y objetivos

7.1 Pregunta central de investigación

¿Es viable diseñar un protocolo y plataforma SaaS multi-tenant de inferencia verificable on-chain (Proof-of-Inference) que admita backends de cómputo heterogéneos (edge ARM resource-constrained, cloud x86 VM, Kubernetes), preservando privacidad y verificabilidad uniformes; y cuál es el trade-off cuantificable entre accuracy del modelo, latencia de generación del proof, consumo de recursos y costo on-chain en cada clase de backend?

7.2 Preguntas secundarias

Q1 — Edge: ¿Qué arquitecturas de modelo TinyML son proving-friendly en EZKL sobre ARM Cortex-A72?
Q2 — Cross-platform: ¿Cómo escala el proof time entre ARM edge, x86 cloud VM y pod K8s para el mismo modelo y dataset? ¿Hay un knee-point donde edge deja de ser viable?
Q3 — Plataforma: ¿La abstracción “Compute Backend” introduce overhead significativo (control plane latency, queueing, encryption del witness) respecto a una solución específica por backend?
Q4 — Privacidad: ¿El binding criptográfico extendido (input-sig + worker-sig) es suficiente para el threat model de un DePIN multi-backend, o el modo cloud/K8s requiere capas adicionales (TEE, MPC)?
Q5 — Tokenomics: ¿Qué rango de precios del token y diferenciación de reward por clase son necesarios para que cada backend tenga incentivo positivo dado su costo operacional real?
Q6 — Operacional K8s: ¿Cuánto auto-scaling consigue el operador VeriFire frente a picos de eventos? ¿Qué métricas operan bien como leading indicator del scaling?

7.3 Objetivo general

Diseñar, implementar y evaluar empíricamente una plataforma SaaS multi-tenant de inferencia verificable on-chain con backends de cómputo heterogéneos, validando un caso de uso real de detección temprana de incendios en las Sierras de Córdoba, y produciendo una metodología y un patrón arquitectónico transferibles a otras redes DePIN de sensing ambiental.

7.4 Objetivos específicos

OE1 — Formalizar el protocolo VeriFire multi-backend (input-binding, doble firma, contrato multi-clase) y su threat model.
OE2 — Realizar el primer benchmark cross-platform (ARM edge / x86 cloud / Kubernetes) de proof generation con EZKL para clasificadores binarios cuantizados.
OE3 — Implementar la plataforma de referencia open-source: light client edge, cloud worker, operador Kubernetes (CRDs + Helm chart), control plane SaaS multi-tenant, smart contracts.
OE4 — Desplegar y operar una red piloto multi-backend (3 RPi + cloud worker GCP + cluster K8s mínimo) durante 2–3 meses con dos tenants ficticios.
OE5 — Analizar la seguridad del mecanismo (Sybil, replay, worker malicioso) y modelar las condiciones económicas para que cada clase de backend tenga incentivo positivo.
OE6 — Producir tres publicaciones académicas: workshop zkML cross-platform, paper de plataforma cloud-native, paper completo de red DePIN.

7.5 Justificación del problema

¿Qué se va a investigar? Cómo construir y evaluar una plataforma de inferencia verificable on-chain que admita cómputo heterogéneo manteniendo verificabilidad y privacidad.
¿Por qué? Porque ningún DePIN actual resuelve simultáneamente verificabilidad criptográfica + cómputo pluggable + multi-tenancy SaaS, y ese gap impide que las redes de sensing escalen.
¿Para qué? Para producir un patrón de diseño reutilizable y un benchmark empírico que sirva de referencia a futuras redes DePIN, y para validar el modelo en un caso socialmente relevante.
¿A quiénes va dirigida la solución? A operadores de redes DePIN (técnico), a la comunidad académica (zkML, sistemas distribuidos), y a organismos como ETAC / Defensa Civil CBA (impacto social).

8. Trabajos relacionados

Esta sección hace un deep dive en los cinco campos relevantes. Para cada trabajo: ficha técnica concreta (año, hardware, métricas), qué sí resuelve y, sobre todo, qué gap deja abierto respecto a la propuesta de esta tesis.

8.1 Edge AI para detección de incendios

La literatura de detección de incendios en edge es madura pero no verificable. Los sistemas existentes optimizan accuracy y latencia de inferencia local, pero asumen que el operador del nodo es honesto.

Sistema	Año	Hardware	Modelo	Accuracy	Latencia	Verificable on-chain
Edge MobileNetV2 (PMC 2025)	2025	RPi 5	MobileNetV2 cuantizado	97.98 %	0.77 s	❌
ForestGuard (IJSRA 2025)	2025	RPi 4B + cámara	Fusión acústico-óptica	~93 %	tiempo real	❌
YOLOv8 + BM688	2024	RPi 4	YOLOv8 nano	~95 %	1–2 s	❌
ForestProtector (arXiv 2501.09926)	2025	Jetson Nano + RPi	RL + CNN	Alta	variable	❌
TinyML Real-Time Bench (arXiv 2509.04721)	2025	múltiples MCUs	varios	n/a	3.47–14.98 ms/frame	❌

Lo que estos sistemas resuelven:

Detección rápida y precisa en hardware barato (RPi 4 / Jetson Nano).
Footprint del modelo de 286–536 KB post-cuantización INT8, lo cual hace viable el despliegue masivo.
Operación 24/7 con latencia sub-segundo de inferencia.

Lo que dejan abierto (gap específico):

Sin verificabilidad criptográfica del cómputo: un nodo malicioso puede hardcodear resultado = 1 durante una ola de calor para cobrar reward, o nunca correr el modelo y devolver ruido — y nadie puede detectarlo.
Sin integración blockchain: las alertas viven en un servidor central; no hay incentivo económico distribuido.
Sin compute heterogéneo: asumen una clase única de hardware. Si el modelo crece (de MobileNet a EfficientNet-Lite4), el sistema simplemente no funciona — no tiene fallback a cloud o cluster.

VeriFire suma exactamente esas tres dimensiones (verificabilidad ZK, blockchain con reward por clase, multi-backend) sobre el mismo problema base.

8.2 zkML: Zero-Knowledge Machine Learning

Frameworks principales en 2025–2026:

Framework	Backend ZK	Velocidad relativa	RAM típica	Edge-friendly	Estado
EZKL	Halo2 (Plonkish)	Baseline	Media (1–8 GB)	Sí (con modelos chicos)	Producción, MIT
zkPyTorch	Custom (Marzo 2025)	VGG-16 en 2.2 s	Alta (32+ GB)	No	Research
Lagrange DeepProve-1	Custom (Agosto 2025)	LLM completo (GPT-2)	Muy alta (128+ GB)	No	Producción datacenter
RISC Zero zkVM	RISC-V	65.88× más lento que EZKL	Muy alta	No	Producción
Circom + Groth16	R1CS	Lento	Media	Marginal	Maduro

Por qué EZKL es la elección de la tesis:

Convierte modelos ONNX directamente a circuitos Halo2; no requiere reescribir el modelo.
Genera el contrato verificador en Solidity automáticamente (ezkl create-evm-verifier), lo cual cierra el loop on-chain sin código manual.
Es 65.88× más rápido que RISC Zero zkVM y 2.92× más rápido que Orion (medido en benchmarks oficiales del equipo EZKL, 2025).
License MIT, comunidad activa, releases mensuales.

Limitación reportada en la literatura zkML:

Modelos grandes (>10 M params) pueden requerir 128 GB+ RAM para generar el proof. Esto hace obligatorio el uso de TinyML cuantizado para on-device proving — o bien delegar a backends potentes (cloud/K8s/GPU), que es justamente la idea de VeriFire.
El survey de Springer Nature (2026) y arXiv 2502.18535 (Feb 2025) identifican explícitamente la ausencia de evaluaciones hardware-in-the-loop en dispositivos edge IoT resource-constrained. Citando textualmente: “all current zkML benchmarks assume datacenter or desktop x86 hardware”.

Caso de referencia: Inference Labs (Bittensor Subnet 2).

Métricas reportadas: 160M+ pruebas zkML generadas en producción durante 2024–2025.
Hardware: GPUs de datacenter (A100/H100).
Caso de uso: validar inferencias de modelos de Bittensor sobre prompts de usuarios.
Gap respecto a VeriFire: Inference Labs no toca edge ni IoT, no tiene un caso de uso ambiental, y no maneja multi-tenancy SaaS. Demuestra que zkML escala, pero no en el régimen resource-constrained.

Caso de referencia: zkVerify (2025).

Primer protocolo orientado específicamente a verificación ZK para IoT/DePIN.
Roadmap incluye chains de soporte y un Verifier modular.
Gap: sin implementaciones de campo, sin operador K8s, sin benchmark cross-platform. Es un blueprint, no un sistema validado.

8.3 DePIN: Redes de infraestructura física descentralizada

DePIN coordinó en 2025–2026 la construcción de infraestructura física mediante incentivos tokenizados: ~$19B market cap, 250+ proyectos en CoinGecko, $1.6M/mes de revenue real en proyectos top de Solana (Frontiers in Blockchain, 2025).

Mecanismos de verificación de trabajo físico (PoPW) por proyecto

Proyecto	Mecanismo	Hardware	Verificabilidad del cómputo	Gap respecto a VeriFire
Helium	Proof-of-Coverage (multi-witness RF)	Hotspots LoRaWAN	Multi-testigo geográfico — no verifica cómputo, solo presencia	Sin inferencia; sin zkML
Filecoin	Proof-of-Replication + Proof-of-Spacetime	Storage nodes	Verifica que los datos están almacenados, no que se computó algo	Aplicable solo a storage, no a sensing
Geodnet / Wingbits	Location Oracle (GPS + multi-testigo)	Receptores GNSS / ADS-B	Verifica posición, no cómputo	Sin inferencia; sin verificabilidad criptográfica
Hivemapper	Multi-witness + verificación off-chain por humanos	Dashcams	Crowd verification — no criptográfica	Centralizado en el verificador
Quakecore (peaq)	Sensores sísmicos + aggregation	Acelerómetros IoT	Multi-testigo + ML server-side	Sin zkML, sin edge AI verificable
Inference Labs (Bittensor)	zkML server-side	GPUs datacenter	✅ Verifica cómputo con ZK	Datacenter only, sin edge, sin multi-tenant
zkVerify	Verificación ZK genérica	Agnóstico	✅ Diseño	Sin implementación de campo, sin K8s

Lectura del cuadro: los DePINs maduros (Helium, Filecoin, Hivemapper) usan multi-witness, no zkML — porque zkML es muy reciente. Los que sí usan zkML (Inference Labs) están en datacenter. Nadie cruza zkML + edge IoT + multi-backend simultáneamente, que es el espacio de VeriFire.

8.4 Kubernetes operators y plataformas multi-tenant para AI workloads

Operadores K8s consolidados para AI:

Operador / framework	Función	¿Aplicable a proof generation?
KServe / KFServing	Model serving (inferencia)	Sirve inferencias, no genera proofs
Kubeflow Pipelines	Pipelines de entrenamiento ML	Pipelines de training, no proving
Ray Operator	Distributed compute (Ray on K8s)	Sí en teoría — ningún proyecto lo usó para zkML público
KEDA	Event-driven autoscaling	✅ Reutilizable como dependencia
NVIDIA GPU Operator	Provisioning de GPUs en pods	✅ Reutilizable para K8s self-managed GPU
OPA Gatekeeper	Policy engine multi-tenant	✅ Reutilizable para aislamiento por tenant

Patrones de multi-tenancy SaaS sobre K8s (Burns 2023, Dobies 2020):

Namespace-per-tenant + NetworkPolicies + ResourceQuotas.
RLS en Postgres + tenant_id propagado en headers.
Métricas Prometheus etiquetadas por tenant para billing.

Gap específico respecto a VeriFire:

Ningún operador existente está diseñado para proof generation: los CRDs InferenceJob y ModelServing que propone VeriFire no son extensiones de KServe, son nuevos.
Ningún operador está integrado nativamente con verificación on-chain: falta el bridge K8s ↔ smart contract (signing del proof, submit a Base, manejo de gas), que es parte de la contribución C3 de la tesis.
Multi-tenancy K8s aplicada a DePIN no está documentada: los patrones existen para SaaS B2B (CRM, observabilidad), no para redes con incentivo económico on-chain.

8.5 Cuadro consolidado de proyectos más cercanos

Resumen comparativo de los cinco proyectos individuales más cercanos al espacio de VeriFire, dimensión por dimensión:

Proyecto	Edge IoT	zkML	Cloud + K8s	SaaS multi-tenant	Blockchain	Caso de uso real
Helium	✅	❌	❌	⚠️ parcial	✅	✅
Inference Labs (Bittensor)	❌	✅	⚠️ datacenter	❌	✅	⚠️
ForestGuard / Edge MobileNet	✅	❌	❌	❌	❌	✅
zkVerify	⚠️ blueprint	✅	❌	❌	✅	❌
Satellites on Fire (AR)	❌	❌	✅ centralizado	⚠️	❌	✅
VeriFire (esta tesis)	✅	✅	✅	✅	✅	✅

Conclusión del estado del arte:

El espacio en el que cae esta tesis — zkML + edge IoT + cloud + Kubernetes + DePIN + SaaS multi-tenant + caso de uso real validado — no tiene implementación académica publicada. Cada uno de los seis ejes existe individualmente (y bien) en la literatura; ningún trabajo combina los seis. Esa intersección es el aporte (C1–C5, §11.1).

9. Propuesta metodológica

9.1 Enfoque general

Investigación aplicada de tipo design science: se construye un artefacto (protocolo + plataforma), se evalúa empíricamente con métricas cuantitativas, y se generaliza el resultado en forma de patrón arquitectónico y benchmark publicable. La metodología combina:

Fase de diseño formal (protocolo, threat model, contrato).
Fase experimental (benchmark cross-platform de proof generation y accuracy).
Fase de implementación (firmware, operador K8s, control plane SaaS, contratos).
Fase de validación operacional (red piloto multi-backend con dos tenants).
Fase analítica (seguridad del mecanismo, modelado económico).

9.2 Arquitectura técnica de la solución

Cuatro backends, un protocolo, un contrato. La separación entre backends CPU-based y GPU-based es deliberada: permite cuantificar el impacto del acelerador en el proof time del mismo modelo y traza una curva de costo-rendimiento que es parte del aporte (C2).

#	Backend	Clase de cómputo	Hardware típico	Rol	Privacidad
1	Edge (ARM)	CPU ARM (proof on-device)	Raspberry Pi 4/5, Jetson Nano	Captura + inferencia + proof on-device	Máxima
2	Cloud VM (CPU)	x86 CPU	GCP Compute Engine free tier (e2-micro / e2-small, AMD/Intel)	Proof en CPU x86 con más RAM que el edge; el nodo edge envía el witness firmado	Parcial
3	Kubernetes managed (CPU)	x86 CPU paralelizado	GKE Autopilot o EKS (workers CPU-only)	Proof distribuido entre pods CPU, auto-escalable, multi-tenant; representa el caso típico “cluster corporativo sin GPU”	Parcial + aislamiento por namespace
4	Kubernetes self-managed (GPU)	GPU (CUDA / ROCm)	Cluster k3s on-prem con GPU local · Vast.ai GPU on-demand · pods con device plugin NVIDIA	Proof acelerado por GPU para modelos grandes (EfficientNet-Lite4, VGG-16) que en CPU son infactibles; permite comparar el mismo modelo CPU vs GPU y trazar la curva de aceleración	Parcial + aislamiento por namespace

El control plane SaaS hace de orquestador (registro, capability attestation, routing, dashboard). El contrato verificador on-chain es agnóstico al backend y diferencia el reward según la clase declarada.

Por qué cuatro backends y no tres: la dimensión CPU vs GPU es ortogonal a la dimensión edge vs cloud vs cluster. Sin la cuarta clase no se puede medir cuánto acelera la GPU el proof generation respecto a un cluster CPU equivalente con el mismo modelo. Esa medición es justamente la que habilita decir “para modelos > N parámetros, K8s+GPU es la única clase viable” — y eso es un resultado publicable.

9.3 Arquitectura de servicios y escalabilidad

La plataforma VeriFire se organiza en cuatro planos de servicio desplegados como microservicios independientes, cada uno con su modelo de escalabilidad y su responsabilidad acotada. La separación responde al principio de loose coupling: cualquier plano puede actualizarse, escalarse o reemplazarse sin tocar a los otros.

9.3.1 Planos de servicio

Plano	Servicios principales	Responsabilidad	Modelo de escalabilidad
1. Data plane (edge)	Light client (firmware RPi)	Captura, firma de entrada, inferencia local opcional, envío del witness al control plane	Horizontal por adición de dispositivos físicos. Cada nuevo capture node se onboardea contra su tenant en el control plane.
2. Control plane (SaaS)	API Gateway · Tenant Service · Node Registry · Job Router · Notification Service · Dashboard (web)	Orquestación multi-tenant: registro y autenticación de nodos, capability attestation, ruteo de jobs según SLA del tenant, dashboard	Horizontal stateless detrás de load balancer. Postgres con RLS para aislamiento por tenant; Redis para cache/queue. Auto-scaling por CPU + RPS.
3. Compute plane (proof workers)	Cloud Worker Service (CPU) · K8s Operator (`InferenceJob` controller) · Worker Pods (CPU y GPU) · Model Serving (`ModelServing` CRD)	Generación de proofs zkML en CPU o GPU según el job; serving de modelos para inferencia delegada	KEDA + HPA con métricas custom (queue depth, GPU utilization). El operador despacha pods según resource hints del job y la afinidad CPU/GPU.
4. On-chain plane (blockchain)	Smart contract `VeriFireNetwork` (Base L2) · Verifier EZKL · Indexer (The Graph o subgraph propio) · Notification Webhook	Verificación criptográfica final, emisión de rewards, registro inmutable de eventos, indexado para consultas off-chain rápidas	Escala con el L2: Base soporta ~1000 TPS y fees << 1 cent. El indexer cachea eventos para que el dashboard no consulte el RPC en cada request.

9.3.2 Diagrama de servicios

9.3.3 Estrategias de escalabilidad por plano

Data plane (edge)

Escala linealmente con el número de nodos físicos. El control plane mantiene un registro distribuido por tenant; no hay cuello de botella centralizado en el data plane.
Cada nodo opera en push mode: no necesita polling.
Tolerancia a fallos: los witnesses no enviados se persisten en SD local hasta que la conectividad se restaura.

Control plane (SaaS)

Stateless services (API Gateway, Tenant, Node Registry, Job Router, Notification) detrás de un Application Load Balancer; auto-scaling con HPA por CPU + RPS. Target: P95 < 200 ms para endpoints sincrónicos.
Postgres como cuello de botella natural; mitigado con read replicas para queries de dashboard, partitioning por tenant_id, RLS para aislamiento, connection pooling con PgBouncer.
Redis como cache de tenant config (TTL 60 s) y queue ligera para notification dispatch.
Multi-tenancy: namespace lógico por tenant, RLS en Postgres, rate-limit por tenant en el API Gateway, métricas Prometheus etiquetadas por tenant_id.

Compute plane (proof workers)

Cloud Worker (single VM): baseline, no escala — sirve como referencia de costo. El control plane lo trata como un pool fijo de capacidad.
K8s managed CPU (GKE Autopilot): escala con KEDA según queue depth de jobs CPU. Min 1 / max N pods según presupuesto del tenant. Costo lineal con jobs procesados.
K8s self-managed GPU: escala con KEDA según queue depth de jobs GPU + métricas custom de NVIDIA DCGM (GPU utilization). Pods con nvidia.com/gpu: 1 resource request. Cluster autoscaler para nodos GPU (caros) — agresivo en scale-down.
Routing entre planes: el Job Router decide CPU vs GPU según resource hints del modelo y SLA del tenant. Política default: jobs con > 5 M params → GPU; resto → CPU paralelizado.

On-chain plane

Escala con la capacidad de Base L2 (~1000 TPS, fees sub-cent). En picos de eventos (humo simultáneo en muchos nodos), el control plane puede batchear submissions vía un contrato relayer (no implementado en la versión mínima, queda como trabajo futuro).
Indexer (subgraph propio o The Graph hosted) cachea todos los eventos InferenceVerified y AlertEmitted; el dashboard consulta el indexer, no el nodo RPC. Esto desacopla el TPS de lectura del TPS de escritura.

9.3.4 SLOs por tenant

Cada tenant tiene un SLA configurable que se traduce en SLOs internos del sistema. La plataforma expone los SLIs y permite al tenant definir el target.

SLO	SLI	Target default
Latencia end-to-end (alerta)	Tiempo desde captura hasta evento `AlertEmitted` on-chain	P95 < 90 s para clase EDGE; < 60 s para CLOUD/K8s
Disponibilidad del control plane	Uptime del API Gateway	99.5 % mensual
Throughput de proofs	Proofs verificados / hora por tenant	Configurable según tier de pago
Tasa de error de verificación	Proofs rechazados on-chain / proofs submitted	< 0.1 %
Tiempo de auto-scaling K8s	Tiempo desde queue depth > umbral hasta pod ready	< 60 s

Los SLOs se monitorean con error budgets. Si un tenant agota su error budget, el Job Router degrada gracefully (rate-limit, no rechazo total).

9.3.5 Failure modes y resiliencia

Falla	Impacto	Mitigación
Nodo edge offline	Pierde inferencias durante el outage	Buffer local en SD; reenvío al volver. No bloquea la red.
Control plane API down	Edge no puede pushear; jobs en cola se acumulan	API stateless con múltiples réplicas; circuit breaker hacia Postgres. RTO target: < 5 min.
Postgres del control plane down	Sin onboarding de nodos; routing degradado	Read replica failover automático; el data path puede operar con cache Redis durante 60 s.
K8s worker pod muere mid-proof	El job se pierde si no era idempotent	Operador implementa retry con backoff exponencial; jobs son idempotent por `proofHash`.
Base L2 RPC lento o fuera	No se publican rewards	Reintentos con backoff; los proofs quedan en queue local del worker hasta que el RPC vuelve.
Worker malicioso (compute plane)	Genera proofs falsos	El verifier on-chain rechaza; sin reward. La firma `sigWorker` lo asocia y el control plane lo desautoriza vía `authorizeWorker(false)`.
Compromiso del control plane	Censura selectiva o ruteo malicioso	Cada tenant puede correr su propio control plane (open-source, federated mode). El contrato on-chain es la fuente de verdad final.

9.3.6 Observabilidad

Métricas: Prometheus con scrape de cada microservicio + exporters de Postgres/Redis/NVIDIA. Etiquetadas por tenant_id, node_class, model_id.
Logs: stdout estructurado (JSON) → Loki o GCP Cloud Logging. Correlación por request_id end-to-end.
Trazas: OpenTelemetry desde el edge (light client) hasta el contrato on-chain (transaction hash como span attribute).
Dashboards Grafana: uno global (operador de la plataforma) + uno per-tenant (cliente del SaaS).
Alerting: SLO burn-rate alerts vía PagerDuty / webhook configurable por tenant.

9.4 Stack tecnológico

Capa	Tecnología	Backend(s)
Captura	PiCamera2	Edge
Signing entrada	`cryptography` + secp256k1	Edge (siempre)
Inference	ONNX Runtime (ARM/x86/CUDA)	All
zkML Prover	EZKL (Halo2)	All
Signing worker	secp256k1	Cloud / K8s
Job orchestration	Operador K8s + CRDs `InferenceJob`, `ModelServing`	K8s
Auto-scaling	KEDA + HPA con métricas custom (queue depth)	K8s
Control plane	FastAPI (Python) + Postgres con RLS multi-tenant	SaaS
On-chain submitter	web3.py	Control Plane / Worker
Smart Contract	Solidity 0.8.x + Foundry	On-chain
L2 Chain	Base (OP Stack)	On-chain
Observabilidad	Prometheus + Grafana + OpenTelemetry	All
IaC	Terraform + Helm	Cloud / K8s

9.5 Diseño experimental

Experimento 1 — Benchmark de Proving cross-platform (OE2)

Variable independiente: arquitectura del modelo (6 variantes) × plataforma (4 backends: Edge ARM / Cloud CPU / K8s managed CPU / K8s self-managed GPU).
Variables dependientes: proof time, peak RAM, proof size, gas cost, costo monetario por proof, speed-up CPU↔GPU (ratio aislado dentro del runtime K8s).
Réplicas: 30 pruebas por celda. Total: 6 modelos × 4 backends × 30 = 720 mediciones.
Plataformas:
- Edge ARM: RPi 4B 4 GB, Raspbian 64-bit.
- Cloud CPU: GCP Compute Engine e2-small, Debian 12, 2 vCPU x86, 2 GB RAM (free tier).
- K8s managed CPU: GKE Autopilot, 3 pods con limits 4 vCPU / 8 GB sin GPU.
- K8s self-managed GPU: cluster k3s on-prem o Vast.ai, 1 pod con NVIDIA device plugin (RTX 3090 o equivalente).
Métrica: superficie de Pareto 3D accuracy / latencia / costo + curva de speed-up CPU→GPU por modelo.
Aporte: primera comparación lado-a-lado de zkML en estas cuatro clases de hardware, separando la contribución del acelerador GPU vs la paralelización entre pods CPU vs el baseline single-host.

Experimento 2 — Accuracy del clasificador

Train/val/test split: 70/15/15 sobre dataset combinado (D-Fire + Kaggle Fire Detection + imágenes propias de Sierras Chicas).
Métricas: Accuracy, Precision, Recall, F1, AUC-ROC.
Ablation: INT8 vs FP32; énfasis en minimizar falsos negativos.

Experimento 3 — Integración end-to-end multi-backend (OE4)

Topología: 3 nodos RPi edge + 1 cloud worker GCP + 1 cluster k3s mínimo (3 pods) con el protocolo completo.
Multi-tenancy: control plane con dos tenants ficticios (“ETAC-CBA” y “Defensa-Civil-AR”) para validar aislamiento.
Período: 2–3 meses de operación continua en campus UNC.
Métricas: uptime por backend, latencia end-to-end por clase, costo de gas mensual, distribución de proofs por backend, métricas del operador K8s.

Experimento 4 — Seguridad del mecanismo DePIN multi-class (OE5)

Modelado económico: ¿qué reward por clase para que cada backend tenga incentivo?
Simulación de ataques: Sybil, replay, worker-malicioso, edge-impostor.
Análisis de degenerate cases: reuso de proofs, colusión entre cloud workers, censura del control plane.

Experimento 5 — Escalabilidad del operador Kubernetes (OE6)

Carga sintética: 10×, 100×, 1000× el caudal real de inferencias.
Variables: cold-start de pods, throughput, latencia P50/P95/P99, comportamiento del HPA.
Comparación: cluster k3s on-prem vs managed (GKE Autopilot).
Aporte: primera caracterización pública del proof generation throughput en un cluster K8s real.

9.6 Modelos a evaluar

Cada modelo se ejecuta en los cuatro backends (Edge ARM, Cloud VM CPU, K8s managed CPU, K8s self-managed GPU). La tabla muestra el proof time esperado en cada uno.

Modelo	Params	Accuracy target	Edge ARM (RPi 4)	Cloud CPU (GCP e2-small)	K8s managed CPU (3 pods GKE)	K8s self-managed GPU (1 pod, RTX 3090)
Custom CNN 3-layer INT8	~200K	~82 %	~1–3 min	~10–20 s	~5–10 s	~2–5 s
MobileNetV3-Tiny INT8	~600K	~88 %	~3–8 min	~30 s–1 min	~10–20 s	~3–8 s
MobileNetV3-Small INT8	~2.5M	~94 %	~10–20 min	~2–4 min	~30 s–1 min	~10–20 s
EfficientNet-Lite0 INT8	~4.7M	~97 %	~25–45 min (riesgo OOM)	~5–10 min	~1–3 min	~30 s–1 min
EfficientNet-Lite4 INT8	~13M	~98 %	❌ infactible	~15–30 min	~5–10 min	~1–2 min
VGG-16 (referencia ablation)	~138M	—	❌	❌ o ~hr	~30–60 min	~5–10 min

Lectura horizontal de la tabla: las dos últimas columnas comparan el mismo modelo en CPU vs GPU dentro del mismo runtime (Kubernetes), aislando el efecto del acelerador. Las columnas 4 y 5 (Edge ARM vs Cloud CPU) aíslan el efecto de la arquitectura del CPU. Las columnas 5 y 6 (Cloud CPU vs K8s managed CPU) aíslan el efecto de la paralelización entre pods.

Visualización esperada del trade-off (esquemática)

El siguiente placeholder muestra cómo se proyecta el frente de Pareto sobre los dos ejes principales (proof time vs accuracy). Cada punto es un par modelo×backend; la línea punteada es el frente de Pareto. La forma exacta se confirma en Experimento 1 (mes 4).

Nota: este gráfico es una proyección esperada basada en literatura zkML 2024–2025 y benchmarks de EZKL en x86. Los datos reales se obtienen en el Experimento 1 (mes 4). El frente de Pareto típicamente sube con GPU + cluster, pero el costo monetario por punto del frente puede invertir el orden — esa tensión es uno de los hallazgos esperados de la tesis.

9.7 Criterios de éxito

Criterio	Mínimo viable	Objetivo
Proof time edge ARM (RPi 4)	< 30 min para algún modelo	< 5 min para al menos un modelo
Proof time cloud CPU (GCP e2-small)	< 5 min para modelo edge-tier	< 1 min
Proof time K8s managed CPU (3 pods)	< 2 min para modelo edge-tier	< 30 s
Proof time K8s self-managed GPU (1 pod)	< 1 min para modelo edge-tier	< 10 s para edge-tier; < 5 min para EfficientNet-Lite4
Speed-up CPU → GPU (mismo modelo)	≥ 5×	≥ 20×
Accuracy clasificador	F1 ≥ 0.85	F1 ≥ 0.92
RAM pico proving edge	< 3.5 GB	< 2 GB
Gas verificación	< 500k gas	< 200k gas
Uptime red piloto	≥ 90 %	≥ 95 %
Multi-tenancy	2 tenants aislados sin cross-leak	Tests automatizados de aislamiento
Auto-scaling K8s	Responde a 10× en < 2 min	Responde a 100× en < 1 min

9.8 Alcance mínimo defendible

Si por restricciones de tiempo o técnicas no se alcanza la versión completa, el alcance mínimo defendible exige: al menos 2 backends funcionando (edge + uno más), operador K8s mínimo (kind/minikube con CRD funcional), control plane single-tenant con arquitectura preparada para multi-tenant, contrato multi-class deployado en Base Sepolia con al menos una transacción exitosa por clase, y benchmark cross-platform de al menos una arquitectura de modelo. Esa configuración reducida sigue produciendo el primer benchmark cross-platform de zkML en hardware edge real y el patrón arquitectónico DePIN multi-backend, suficiente para CACIC o un workshop internacional.

9.9 Estrategias de mitigación técnica

Dos estrategias de respaldo se documentan explícitamente para preservar el aporte aún si el camino preferido falla. Cada una mantiene la verificabilidad on-chain (que es el aporte criptográfico) aunque sacrifique alguna otra propiedad (privacidad o accuracy).

Mitigación A — Modelo ultra-pequeño custom para preservar viabilidad edge

Cuándo se activa: si el benchmark muestra que ningún modelo estándar (incluyendo MobileNetV3-Tiny INT8) genera proof en RPi 4 en menos de 30 minutos con los recursos disponibles, hay riesgo de que el caso EDGE quede sin demostración funcional. Esa es justamente la propiedad de privacidad full que diferencia EDGE de los otros backends; perderla diluye el aporte.

Qué hacemos: diseñar y entrenar una CNN custom mínima:

Input: 64×64 pixels (grayscale o RGB reducido)
Conv2D(8 filters, 3×3) → BatchNorm → ReLU
Conv2D(16 filters, 3×3) → BatchNorm → ReLU → MaxPool
Flatten → Dense(32) → Dense(2) → Softmax

Parámetros: ~50K–100K (vs 200K de la “Custom CNN 3-layer” del benchmark estándar).
Proof time target en RPi 4: < 3 minutos.
Trade-off: accuracy probablemente cae a ~80–85 % (vs 88 % del MobileNet-Tiny). Suficiente para PoC del protocolo, no para producción.

Por qué es válido como mitigación y no como solución principal: un accuracy de 80 % es bajo para detección de incendios en producción (alto falso negativo). Pero el aporte de la tesis no es el clasificador — es el protocolo y la plataforma. Mostrar que el modelo más chico imaginable también funciona end-to-end refuerza el patrón arquitectónico, sin pretender que ese modelo sea desplegable.

Mitigación B — Arquitectura split (ya integrada como casos B/C del protocolo)

Cuándo se activa: automáticamente, en operación normal de la plataforma. No es un fallback de emergencia: es el comportamiento default cuando el modelo a ejecutar no es proving-friendly en el backend del nodo edge.

Qué hacemos: el nodo edge genera el witness firmado y lo envía cifrado al backend Cloud o K8s, que produce el proof y firma el resultado. La doble firma (sigInput del capture node + sigWorker del proof generator) preserva el binding criptográfico entrada → cómputo → reward; el verifier on-chain es el mismo y rechaza cualquier proof inválido independientemente de dónde se generó.

Trade-off explícito:

✅ Verificabilidad on-chain íntegra.
✅ Binding criptográfico preservado (el worker no puede falsificar sigInput).
⚠️ Privacidad reducida: el worker ve el witness (no el frame crudo si se envía solo el embedding, pero sí información derivada).
✅ Reward económico ajustado a la baja para reflejar el menor valor de privacidad (clase CLOUD/K8S < EDGE).

Conclusión: lo que en propuestas previas era un fallback reactivo (“si edge no aguanta, salimos por cloud”) en VeriFire es un ciudadano de primera clase del protocolo. Eso convierte una limitación técnica en un aporte arquitectónico.

10. Recursos involucrados y cronograma de trabajo

10.1 Recursos de hardware

Recurso	Cantidad	¿Se cuenta con él?
Raspberry Pi 4B 4 GB	3	A adquirir (~$240 USD propios o beca)
Raspberry Pi Camera Module v3	3	A adquirir (~$120 USD)
MicroSD 64 GB + case + PSU	3	A adquirir
Cluster K8s on-prem (3 nodos viejos, ≥ 8 GB RAM c/u)	1	Hardware reutilizado del laboratorio
(Alt.) Cluster managed GKE Autopilot	—	Si no alcanza on-prem; ~$200 USD con créditos
Conectividad outdoor (SIM 4G)	3 (opc.)	WiFi del campus en fase inicial; SIM solo si despliega afuera

10.2 Recursos de cómputo en la nube

Recurso	Costo	¿Se cuenta con él?
GCP Compute Engine e2-micro / e2-small (cloud worker base)	$0 (free tier always-free + créditos $300 GCP)	Sí — cuenta personal con free tier
Vast.ai GPU on-demand para ablation (~30 hs)	~$30 USD	Créditos existentes
Base Sepolia (testnet)	$0	Pública
Base mainnet (gas fees deploy + experimentos)	< $60 USD	Wallet personal

10.3 Recursos de software

EZKL (MIT), Foundry, ONNX Runtime, kopf o kubebuilder, FastAPI, Postgres con RLS, Helm 3, Prometheus, Grafana, OpenTelemetry, web3.py, Pillow, scikit-learn, PyTorch + ONNX export. Todos open-source, sin costo de licencia.

10.4 Datasets

D-Fire dataset (público, Kaggle), Fire Detection Dataset (Kaggle), imágenes propias etiquetadas de Sierras Chicas (a recolectar).

10.5 Recursos humanos

Tesista (autor): dedicación part-time de 20–25 hs/semana durante 12 meses (compatible con el cursado de los últimos años).
Director: revisión técnica quincenal y aprobación de hitos.
Codirector embedded: validación del firmware y benchmark de hardware ARM.
Codirector cloud-native: validación del operador K8s, multi-tenancy, arquitectura SaaS.
Colaboraciones potenciales (no bloqueantes): CONICET Córdoba / Defensa Civil CBA para validación del caso de uso, Satellites on Fire (startup CBA) para acceso a imágenes históricas etiquetadas.

10.6 Presupuesto consolidado

Item	Costo (USD)
3× RPi 4B 4 GB	$240
3× Cámaras + accesorios	$120
Conectividad 4G (opcional, 3 meses)	$90
Cloud worker GCP (e2-small free tier)	$0
Vast.ai GPU on-demand	~$30
Cluster K8s managed (alternativa, 3 meses)	~$200 (o $0 on-prem)
Gas fees (Base mainnet)	< $60
Dominio / hosting del control plane	$30
Total estimado	~$770–1.000

10.7 Cronograma de trabajo

Duración total: 12 meses distribuidos en 5 fases comprimidas. Asumiendo dedicación part-time de 20–25 hs/semana (compatible con el cursado de los últimos años de Ing. en Computación), las 5 fases caben en un año calendario. La versión mínima defendible (§9.8) cabe en 8–9 meses si fuera necesario adelantar la defensa.

Fase	Meses	Entregables
Fase 0 — Preparación	1	Revisión bibliográfica focal (~30 papers core, no exhaustiva); setup de hardware (2 RPi + cluster k3s mínimo o kind local); toolchain (EZKL ARM y x86, ONNX Runtime, Foundry, kopf, FastAPI); PoC: modelo toy de 3 capas → EZKL → proof generado en RPi y en pod K8s, ambos verificados por el mismo verifier en Base Sepolia.
Fase 1 — Benchmark cross-platform	2–4	Curación y etiquetado del dataset; fine-tuning de las 6 arquitecturas; ejecución de Experimentos 1 + 2 sobre los 4 backends; paper parcial (workshop): “Cross-platform Benchmarking of zkML Provers across Edge, Cloud and Kubernetes Backends”; diseño formal del protocolo VeriFire multi-backend.
Fase 2 — Protocolo, contratos y operador K8s	5–7	Light client edge (firmware RPi); cloud worker (FastAPI service); operador Kubernetes (CRDs + Helm chart); smart contracts multi-class (Solidity/Foundry) deployados en Base Sepolia; control plane SaaS multi-tenant (API REST + dashboard mínimo); testing unitario + integración + Experimento 4 (seguridad).
Fase 3 — Red piloto multi-backend	8–10	Despliegue: 3 RPi en campus + 1 cloud worker GCP + cluster k3s on-prem; onboarding de 2 tenants; operación continua 8 semanas (Experimento 3); stress testing del operador K8s (Experimento 5); recolección y análisis de datos operacionales; iteración del protocolo.
Fase 4 — Escritura y defensa	11–12	Escritura de la tesis completa (en paralelo con Fase 3 desde mes 9); submisión paper completo a IEEE IoT Journal o ACM SenSys; submisión paper de plataforma a ACM SoCC o KubeCon poster; preparación de la defensa y defensa final.

Margen de seguridad: las fases 1 y 2 solapan parcialmente (el diseño formal del protocolo se puede empezar mientras corre el benchmark). Si una fase se retrasa 2–3 semanas, el cronograma absorbe el corrimiento sin tocar la defensa, recortando del alcance opcional definido en §9.8.

Diagrama de Gantt

10.8 Hitos críticos

Hito	Mes	Entregable
H1	1	PoC: proof funcional en RPi y en pod K8s, ambos verificados on-chain
H2	4	Benchmark cross-platform completo (4 backends × 6 modelos) + workshop paper submited
H3	7	Protocolo VeriFire v1.0 + operador K8s + control plane SaaS en testnet
H4	10	Red piloto multi-backend operacional 8 semanas con 2 tenants
H5	11	Paper completo submited a venue primario
H6	12	Defensa

10.9 Gestión de riesgos

Riesgo	Probabilidad	Impacto	Mitigación
EZKL demasiado lento en RPi 4 (> 60 min/proof para todos los modelos)	Media	Medio	El backend cloud/K8s absorbe la carga; en multi-backend, edge lento no es bloqueante — pasa a ser un dato más del benchmark.
RAM insuficiente edge (OOM durante proving)	Media	Bajo	El cloud asume el job; el control plane rutea por capacidad.
Degradación de accuracy por cuantización extrema	Baja	Medio	Mixed-precision (INT8 convoluciones, FP16 capas críticas).
Costo de gas demasiado alto	Baja	Medio	Base tiene fees << 1 cent. Fallback: off-chain verification + on-chain commitment.
Logística outdoor	Alta	Bajo	Fase 3 empieza en campus UNC; Sierras Chicas opcional.
EZKL introduce breaking changes	Baja	Medio	Pin de versión. El protocolo es prover-agnostic.
Complejidad del operador K8s subestimada	Media	Medio	Empezar con kopf (Python) en vez de kubebuilder (Go). Si se convierte en sumidero, recortar a script + cronjobs nativos sin CRD propio.
Multi-tenancy introduce vulnerabilidades	Media	Alto	tenant_id en todas las tablas, RLS en Postgres, tests de cross-tenant data leak antes de Fase 3.
Costo cloud/K8s excede presupuesto	Baja	Medio	GCP free tier para cloud worker; k3s on-prem para cluster; spot instances para Vast.ai.
Encryption del witness añade latencia	Baja	Bajo	Hybrid encryption (RSA-OAEP + AES-GCM); medición y reporte explícito.

11. Aportes esperados

11.1 Aporte académico

Cinco contribuciones originales (C1–C5):

C1 — Protocolo VeriFire multi-backend: diseño formal de un protocolo de Proof-of-Inference que admite múltiples clases de backend de cómputo bajo un mismo contrato verificador. Modelo de input signing extendido con doble firma (capture + worker) que establece un binding triple: entrada → cómputo → reward. Circuito zkML mínimo viable parametrizable en complejidad para correr en al menos tres clases de hardware. Interfaz del contrato verificador con clase de nodo on-chain y capability attestation.
C2 — Benchmark empírico cross-platform: primera evaluación sistemática (que se sepa) del trade-off zkML en múltiples clases de backend simultáneamente — proof time, peak RAM, proof size, gas cost, costo monetario por proof — sobre ARM Cortex-A72, x86 cloud VM y pod Kubernetes con resource limits configurables.
C3 — Plataforma VeriFire SaaS de referencia (open-source): prototipo funcional end-to-end con light client edge, operador Kubernetes con CRDs y Helm chart, control plane SaaS multi-tenant, smart contracts en Base Sepolia/mainnet, observabilidad Prometheus + Grafana + OpenTelemetry, IaC con Terraform y Helm, dataset público de imágenes humo/fuego.
C4 — Metodología de diseño de circuitos zkML “backend-aware”: guía con reglas prácticas derivadas del benchmark — qué arquitecturas son proving-friendly en cada backend, dónde está el knee-point de cada plataforma, qué nivel de cuantización preserva la viabilidad del circuito, reglas de routing dado un modelo y un SLA de latencia.
C5 — Modelo arquitectónico de plataforma DePIN heterogénea: patrón de diseño reutilizable para DePINs de próxima generación, donde el contrato es agnóstico al backend y solo verifica integridad criptográfica + capability attestation.

11.2 Aporte técnico

Repositorio open-source con la implementación completa (license MIT/Apache-2): firmware, operador K8s, control plane, contratos, scripts de despliegue.
Helm chart distribuible: cualquier operador puede instalar la plataforma con helm install verifire.
Dataset público de imágenes etiquetadas de humo/fuego de la zona Sierras Chicas.

Caso de uso transferible al ETAC / Defensa Civil de Córdoba para detección temprana de incendios, reduciendo la latencia de detección de 35–60 min (satelital) a minutos (red densa edge).
Modelo de negocio compatible con financiamiento público (un municipio o Defensa Civil paga un fee por acceso a alertas) o financiamiento descentralizado (DePIN puro), cuyas condiciones de sustentabilidad la tesis modela formalmente.

11.4 Aporte económico y de mercado

Habilitación de un mercado bilateral de cómputo verificable para sensing: oferta (operadores edge + operadores K8s/cloud con capacidad ociosa) y demanda (municipios, aseguradoras, ONGs ambientales) coordinadas vía smart contract.
Validación de una arquitectura SaaS escalable para DePIN, replicable a otros dominios de sensing (calidad de aire, ruido, tráfico, plagas agrícolas, monitoreo de fauna).

11.5 Publicaciones planeadas

#	Mes	Venue	Título tentativo
1	4	NeurIPS Workshop on TrustML / similar	“Cross-platform Benchmarking of zkML Provers across Edge, Cloud and Kubernetes Backends”
2	10	ACM SoCC o KubeCon poster	“A Multi-Backend DePIN Architecture: Verifiable Inference with Pluggable Compute”
3	11	IEEE IoT Journal o ACM SenSys	“VeriFire: A Multi-Backend SaaS Platform for Verifiable Inference in DePIN Sensor Networks”

11.6 Resultados esperados cuantitativos (hipótesis falsables)

A diferencia de una propuesta de “experimento abierto”, la tesis se compromete con hipótesis cuantificables que pueden ser confirmadas o refutadas por los experimentos. Las bandas reflejan incertidumbre razonable basada en la literatura existente de zkML.

#	Hipótesis	Métrica esperada	Banda de incertidumbre
H1	Speed-up GPU vs CPU (mismo modelo, runtime K8s) crece con el tamaño del modelo	5×–30× para modelos 0.6M–13M params	±50 % por modelo
H2	Knee-point edge: hay un tamaño máximo de modelo viable en RPi 4	~2–5M params (proof time < 30 min, RAM < 3.5 GB)	sensible a versión EZKL
H3	Pareto front accuracy / latencia: existe un modelo dominante para edge	MobileNetV3-Tiny INT8 esperado en el frente	accuracy ≥ 88 %, proof < 8 min
H4	Costo por proof verificado on-chain (Base L2)	< $0.005 USD por verificación	factor 2× según gas price
H5	Tamaño del proof EZKL on-chain	10–50 KB	depende del circuito
H6	Auto-scaling K8s frente a 100× pico de carga	tiempo a estabilizar < 60 s	depende del cluster
H7	Overhead del control plane SaaS vs solución dedicada	< 200 ms P95 latency adicional	medible en Experimento 1
H8	Falsos negativos del clasificador en humo controlado	< 5 %	crítico para caso de uso
H9	Multi-tenancy: aislamiento entre tenants A y B	0 cross-tenant leaks en 30 tests automáticos	binario: 0 o falla
H10	Mínimo reward económico para sustentabilidad del nodo EDGE	$0.50–$1.50 USD / día por nodo activo	depende de costo eléctrico local

Interpretación de los resultados: si H1, H2 y H4 se confirman, el aporte C2 (benchmark cross-platform) es un resultado publicable independientemente del resto. Si H6 y H7 se confirman, el aporte C3 (plataforma SaaS) es defendible. Si alguna hipótesis se refuta, el resultado negativo también es publicable — eso es lo que diferencia ciencia de ingeniería.

12. Referencias bibliográficas

(Formato IEEE — versión preliminar; se ampliará durante la revisión sistemática de la Fase 0.)

zkML

[1] Y. Zhang et al., “A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning,” arXiv preprint arXiv:2502.18535, Feb. 2025.

[2] Springer Nature, “A survey of zero-knowledge proof based verifiable machine learning,” Artif. Intell. Rev., 2026.

[3] EZKL Team, “Benchmarking ZKML Frameworks,” blog.ezkl.xyz, 2025. [Online]. Available: https://blog.ezkl.xyz/post/benchmarks/

[4] EZKL Team, “State of EZKL: 2025,” blog.ezkl.xyz, 2025. [Online]. Available: https://blog.ezkl.xyz/post/state_of_ezkl/

[5] ICME, “The Definitive Guide to ZKML (2025),” blog.icme.io, 2025.

[6] Lagrange Labs, “DeepProve-1: First zkML System to Prove Full LLM Inference,” lagrange.dev/blog, 2025.

[7] “On-chain zero-knowledge machine learning: An overview and comparison,” ScienceDirect, 2024.

Edge AI / Fire Detection

[8] “Edge-Based Autonomous Fire and Smoke Detection Using MobileNetV2,” PMC, 2025. PMC12567645.

[9] “ForestGuard: An IP66 Edge-AI Raspberry Pi Node for Illegal Logging and Early Fire/Smoke Detection,” IJSRA, 2025.

[10] “ForestProtector: IoT Architecture with Deep RL for Wildfire Monitoring,” arXiv preprint arXiv:2501.09926, 2025.

[11] “Tiny Machine Learning and On-Device Inference: A Survey,” PMC, 2025.

[12] “Real-Time Performance Benchmarking of TinyML Models,” arXiv preprint arXiv:2509.04721, 2025.

DePIN y blockchain edge

[13] “Decentralized physical infrastructure networks (DePIN) tokenomics,” Frontiers in Blockchain, 2025.

[14] “Blockchain-Enabled Edge Intelligence for IoT,” MDPI Future Internet, vol. 13, no. 2, 2021.

[15] “Secure blockchain integrated deep learning framework for IoT edge intelligence,” Scientific Reports, Nov. 2025.

[16] zkVerify Team, “2025: Year in Review,” zkverify.io/blog, 2025.

Kubernetes y plataformas cloud-native

[17] B. Burns et al., Kubernetes Patterns: Reusable Elements for Designing Cloud Native Applications, 2nd ed. O’Reilly Media, 2023.

[18] J. Dobies, J. Wood, Kubernetes Operators: Automating the Container Orchestration Platform, O’Reilly Media, 2020.

[19] CNCF, “KEDA: Kubernetes Event-driven Autoscaling,” keda.sh, 2025.

[20] OpenTelemetry, “Observability Framework,” opentelemetry.io, 2025.

Contexto local

[21] “En 2024 se quemaron casi 70.000 hectáreas de bosque nativo en Córdoba,” elDiarioAR, 2024.

[22] “La startup argentina que detecta incendios forestales antes que la NASA,” Perfil, 2024.

[23] “Informe sobre incendios forestales en Córdoba, septiembre 2024,” Defensoría del Pueblo de la Nación, 2024.

[24] “Córdoba redujo más del 80 % la superficie afectada en 2025,” La Ranchada, 2025.

Anexo A — Diseño del Smart Contract Multi-Class

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "./IEZKLVerifier.sol"; // Auto-generado por EZKL

contract VeriFireNetwork is ERC20, Ownable {
    string public constant VERSION = "1.0.0";

    IEZKLVerifier public verifier;
    bytes32 public modelHash;        // hash on-chain del modelo ONNX activo
    uint256 public modelVersion;     // monotonic
    uint256 public verifierActivatedAt;  // grace period

    enum NodeClass { EDGE, CLOUD, K8S }

    mapping(NodeClass => uint256) public rewardPositive;
    mapping(NodeClass => uint256) public rewardUptime;
    mapping(address => mapping(NodeClass => mapping(address => bool))) public authorizedWorkers;
    mapping(address => uint256) public nodeUptime;
    mapping(bytes32 => bool) public usedProofs;

    event InferenceVerified(address indexed captureNode, address indexed workerNode, NodeClass class, bool positive, uint256 timestamp);
    event AlertEmitted(address indexed captureNode, NodeClass class, uint256 timestamp);
    event WorkerAuthorized(address indexed captureNode, NodeClass class, address worker);
    event VerifierUpgraded(address indexed oldVerifier, address indexed newVerifier, bytes32 newModelHash, uint256 newModelVersion);
    event RewardsUpdated(NodeClass indexed class, uint256 positive, uint256 uptime);

    constructor(address _verifier) ERC20("VeriFireToken", "VFT") Ownable(msg.sender) {
        verifier = IEZKLVerifier(_verifier);
        rewardPositive[NodeClass.EDGE]  = 12e18;
        rewardPositive[NodeClass.CLOUD] = 10e18;
        rewardPositive[NodeClass.K8S]   =  9e18;
        rewardUptime[NodeClass.EDGE]    = 1.2e18;
        rewardUptime[NodeClass.CLOUD]   = 1.0e18;
        rewardUptime[NodeClass.K8S]     = 0.9e18;
    }

    function authorizeWorker(NodeClass class, address worker) external {
        require(class != NodeClass.EDGE, "Edge proves on-device");
        authorizedWorkers[msg.sender][class][worker] = true;
        emit WorkerAuthorized(msg.sender, class, worker);
    }

    function submitInference(
        bytes calldata proof,
        uint256[] calldata publicInputs,
        address captureNode,
        bytes calldata sigInput,
        bytes calldata sigWorker,
        NodeClass class
    ) external {
        bytes32 proofHash = keccak256(proof);
        require(!usedProofs[proofHash], "Proof already used");
        require(publicInputs.length >= 2, "Bad public inputs");

        if (class == NodeClass.EDGE) {
            require(captureNode == msg.sender, "Edge must be self-submitted");
        } else {
            require(authorizedWorkers[captureNode][class][msg.sender], "Worker not authorized");
        }

        bytes32 inputHashMsg = bytes32(publicInputs[0]);
        require(_verifySignature(inputHashMsg, sigInput, captureNode), "Bad input sig");

        bytes32 workerMsg = keccak256(abi.encodePacked(proofHash, publicInputs, class));
        require(_verifySignature(workerMsg, sigWorker, msg.sender), "Bad worker sig");

        require(verifier.verify(proof, publicInputs), "Invalid zkML proof");

        usedProofs[proofHash] = true;
        bool positive = publicInputs[1] == 1;
        nodeUptime[captureNode]++;

        uint256 reward = positive ? rewardPositive[class] : rewardUptime[class];
        _mint(captureNode, reward);

        if (positive) emit AlertEmitted(captureNode, class, block.timestamp);
        emit InferenceVerified(captureNode, msg.sender, class, positive, block.timestamp);
    }

    function _verifySignature(bytes32 hash, bytes calldata sig, address expected)
        internal pure returns (bool) { /* OpenZeppelin ECDSA */ }

    function setRewards(NodeClass class, uint256 positive, uint256 uptime) external onlyOwner {
        rewardPositive[class] = positive;
        rewardUptime[class] = uptime;
        emit RewardsUpdated(class, positive, uptime);
    }

    /// @notice Upgrade del verifier ON-chain cuando se reentrena el modelo.
    /// @dev Establece el nuevo verifier y registra el hash y versión del modelo.
    ///      Los nodos tienen GRACE_PERIOD para actualizar antes de que sus
    ///      proofs viejos sean rechazados off-chain por el control plane.
    function upgradeVerifier(address newVerifier, bytes32 newModelHash) external onlyOwner {
        address old = address(verifier);
        verifier = IEZKLVerifier(newVerifier);
        modelHash = newModelHash;
        modelVersion += 1;
        verifierActivatedAt = block.timestamp;
        emit VerifierUpgraded(old, newVerifier, newModelHash, modelVersion);
    }
}

Notas de diseño del contrato:

Versionado on-chain: string public constant VERSION = "1.0.0" permite a indexers y dashboards declarar la versión del protocolo de manera auditable.
Doble firma: sigInput (capture node) + sigWorker (proof generator) cierra el binding triple entrada → cómputo → reward.
Reward al capture node: quien aporta el sensor físico cobra; el reparto con el worker (cloud/K8s) se acuerda off-chain. Simplifica el contrato y se alinea con la práctica DePIN.
Replay protection: usedProofs[proofHash] rechaza pruebas reutilizadas.
Capability attestation: authorizedWorkers[captureNode][class][worker] impide que un worker malicioso intercepte witnesses ajenos.
Upgrade del verifier: upgradeVerifier(newVerifier, newModelHash) rota el verificador y registra el hash + versión del modelo en cadena. Emite evento VerifierUpgraded que los indexers y dashboards consumen para invalidar proofs anteriores fuera del grace period.
Ownable: acceso administrativo pensado para transferir a un multisig o DAO en producción.

Política de upgrade del modelo (post-tesis)

Cuando el modelo se reentrene (más imágenes de Sierras CBA, nuevas zonas geográficas, modelos con mejor accuracy), los proofs generados con el modelo viejo no pueden seguir siendo aceptados — pero la transición no puede romper la red:

Etapa	Quién hace qué	Duración
T0 — Anuncio	Owner emite `VerifierUpgraded`; indexer + dashboard avisan a todos los tenants	inmediato
T0 → T0+72h — Grace period	Verifier acepta proofs de ambas versiones (viejo y nuevo). Los nodos descargan el nuevo modelo ONNX vía CDN del control plane y reentrenan circuitos EZKL locales	72 horas
T0+72h — Cutover	El control plane rechaza off-chain submissions con `modelVersion` viejo; on-chain el contrato sigue verificando criptográficamente, pero el indexer marca esos eventos como deprecated	discreto
T0+30d — Limpieza	Si > 99 % de los nodos migraron, se puede `setVerifier` a un contrato que solo acepte la versión nueva	configurable

El modelHash on-chain permite a cualquier auditor externo verificar qué modelo exacto se usó en cualquier inferencia histórica — propiedad útil para forensics regulatorios o disputas legales.

Anexo B — Preguntas frecuentes conceptuales

B.1 ¿Cómo ayuda esto a prevenir incendios?

No previene — detecta temprano. La diferencia es crítica: un incendio detectado en los primeros 5 minutos se puede apagar con una motobomba y 2 personas. El sistema de referencia actual (satélites) tarda 35–60 min; una red densa de cámaras edge puede detectar humo en minutos, 24/7, sin operador.

B.2 ¿Una persona externa puede aportar con cámara o cómputo? ¿Y si muestra un incendio falso?

Sí — ese es el modelo DePIN. Sin zkML el problema sería trivial: cualquier nodo podría mandar “humo” sin haber corrido el modelo. Con zkML el contrato no acepta el resultado sin prueba matemática. Lo que sí es posible es input fraud (mostrar una imagen guardada de fuego al sensor), que se mitiga con multi-testigo (si un solo nodo grita “fuego” y los vecinos no, la alerta se marca como sospechosa).

B.3 ¿Por qué se necesitan varias Raspberry Pi y no una sola?

Para la tesis: con un solo nodo no se puede medir el comportamiento de la red (uptime distribuido, coordinación, fallas). Con 3 RPi + cloud worker + cluster K8s se hacen experimentos reales de red multi-backend. Para el caso de uso: una cámara cubre un ángulo limitado de un cerro; la visión es que muchas personas pongan cámaras formando una red densa.

B.4 ¿El sistema crea un token propio o usa uno existente?

Para la tesis crea un token propio (VeriFireToken, ERC-20) sin valor económico real, igual que una tesis de redes crea una red privada. Si escalara a producción, la decisión sería usar un token existente (USDC, ETH) o emitir uno con distribución real.

B.5 ¿Quién pone el dinero que reciben los operadores?

La pregunta más incómoda del modelo DePIN. Tres modelos posibles: emisión inflacionaria (token sin demanda no vale), consumidores pagan (un municipio o aseguradora paga por las alertas — sostenible pero requiere clientes), subsidio inicial (centralizado). La tesis modela formalmente bajo qué condiciones el sistema es autosustentable.

B.6 ¿Esto sirve solo para Sierras de Córdoba o escala como SaaS?

Escala — esa es la razón de la arquitectura SaaS multi-tenant. Cualquier organización (provincia, municipio, ONG, universidad de otro país) puede onboardearse como tenant, configurar sus backends, ver su dashboard aislado y recibir alertas. Sierras Chicas es el caso de uso ancla; el aporte académico es la plataforma.

B.7 ¿Por qué tres backends? ¿No es over-engineering?

No, es la respuesta a tres limitaciones reales de los DePIN actuales: modelos grandes infactibles en hardware barato (los corre cloud/K8s), operadores con GPU ociosa que no pueden contribuir (ahora sí), picos de carga que colapsan edge (cloud absorbe el overflow). El alcance mínimo defendible recorta a 2 backends para controlar el riesgo.