⚠ DEMO CONCEPTUAL · Datos simulados con fines demostrativos
Transparencia VenezuelaSistema Blockchain + IA
Arquitectura técnica

Cómo está construido el sistema por dentro. Primero la vista general; luego el recorrido real de cada subsistema, paso a paso. La misma arquitectura sirve a todos los ministerios.

A · Vista general · el sistema en capas

Una petición recorre las capas de arriba abajo: la app habla con la API, que orquesta los servicios (IA, firma e indexación), que escriben en la capa de confianza (blockchain) y de datos.

Cada capa y su función, de la app del ciudadano a los datos.

1 CLIENTE 2 API · PUERTA ÚNICA 3 SERVICIOS 4 CONFIANZA Y DATOS Portal públicoweb (Next.js) App ciudadanamóvil (PWA) API GatewayREST · Edge Motor IAML + LLM auditor Servicio PKIfirma de credenciales Indexadoreventos on-chain PostgreSQLmetadatos (Supabase) Polygon (L2)smart contract IPFSdocs descentralizados orquesta consulta precios sella indexa
ClienteNext.js · React · Tailwind
APIAPI REST · Edge Functions
ServiciosMotor IA (ML + LLM) · Servicio PKI · Indexador on-chain
ConfianzaPolygon (L2 Ethereum) · Solidity · viem
DatosPostgreSQL (Supabase) · IPFS
B · Cómo funciona por dentro · en detalle

El recorrido real de cada subsistema, con la técnica concreta de cada etapa. Cada paso con el sello replica un mecanismo ya en producción en otro gobierno — el detalle, en Probado en el mundo.

1 · El Motor IA · de un contrato a una alerta

Un contrato no recibe un veredicto de una caja negra. Pasa por capas acumulativas, de la más barata y explicable (reglas) a la más fina (grafos y LLM). Cada capa replica una técnica ya probada.

Contrato entrantemonto, ítems, oferentes Extracción de featuresprecio unit., nº ofertas, plazo Capa de reglasIQR · Benford · HHI Capa de grafossocios · testaferros LLM auditorlee pliego y justificación Score + decisiónaprueba · alerta · rechaza normaliza z-score vs mercado cruza bases señales combina OCDS · estándar abierto OCP / Cardinal UK NFI · WB GRAS Brasil ChatTCU Brasil Alice
2 · El recorrido del dato · on-chain vs off-chain

Regla de oro de todos los gobiernos que usan blockchain: el documento NUNCA se sube a la cadena. Se sube su huella. Así se prueba integridad sin exponer datos ni saturar la red.

PDF del contratodocumento completo IPFSguarda el documento Hash SHA-256huella única del doc Árbol Merkleraíz anclada on-chain Verificación ciudadanaprueba Merkle vía QR se guarda en se calcula se sella cualquiera verifica off-chain Estonia KSI · keyless Georgia · ancla a Bitcoin Exonum light client
3 · La firma y la cadena de confianza

El sistema no confía en 'quién dice ser' un ministerio: confía en una firma criptográfica encadenada hasta la raíz. El mismo algoritmo de Ethereum, verificable on-chain.

Autoridad Raízclave del Gobierno Credencial delegadaclave del ministerio Firma del contratofirma el hash, no el PDF Verificación de cadenaministerio → raíz firma la credencial firma con su clave se comprueba ECDSA secp256k1 on-chain, sin servidor
¿Quién está en cada nivel de esta cadena?Aquí se ve el mecanismo de la firma. El modelo institucional — qué autoridad es la raíz, qué ministerios son delegados y cómo se revoca a uno corrupto — está en Gobernanza · quién certifica a quién →
C · Decisiones de diseño · por qué este stack

Las tres preguntas que hace todo evaluador técnico ante un blockchain de gobierno — respondidas de frente.

¿Red pública o de consorcio?

El reflejo natural para varios entes sería una red de consorcio cerrada (tipo Quorum o Hyperledger). Elegimos una L2 pública (Polygon) con permisos a nivel de smart contract: el ciudadano verifica sin pedir permiso, se ancla a la seguridad de Ethereum y no hay lock-in con un proveedor. La transparencia es el producto — una red cerrada la contradiría.

¿Quién valida los bloques?

Polygon usa Proof of Stake, no minería (Proof of Work). Sin coste energético, transacciones de céntimos y confirmación en segundos — idóneo para el volumen de un Estado y para un gobierno que no puede justificar el gasto de una red de minado.

¿Quién controla el contrato?

El control de acceso se implementa con roles on-chain (patrón AccessControl): rol raíz para el Gobierno Central, rol emisor para cada ministerio — el reflejo en código de la jerarquía de Gobernanza. Las actualizaciones del contrato pasan por multifirma con timelock y auditoría previa (Slither + revisión manual).

Arquitectura conceptual con fines demostrativos. Las tecnologías nombradas reflejan el diseño propuesto; el sistema productivo está en desarrollo.