Panel de soluciones blockchain para la transformación digital del Estado peruano

Veintitrés desafíos con definición suficiente para evaluación técnica, la red que corresponde a cada uno según su naturaleza y el marco normativo aplicable.

23desafíos con evaluación técnica
25entidades en el programa
20en red permisionada soberana
100%con interés declarado en pilotos
El eje que decide la red

Gobernanza o valor

La red adecuada no depende del tamaño de la entidad ni de la complejidad del problema, sino de una sola pregunta: ¿el desafío consiste en gobernar una jerarquía cerrada de validadores, o en mover valor entre partes que ya se confían? Cada punto representa una entidad. Pasa el cursor para identificarla; haz clic para ver su ficha.

Gobernanza soberanaUna entidad rectora controla quién valida. Red permisionada dedicada.
Liquidación de valorEmisores de confianza mutua liquidan obligaciones. Red de pagos.
Red
Arquetipo

Tres redes intercambiables y una alternativa autónoma

Las tres redes de la gama lila comparten el mismo entorno de ejecución (EVM), corren contratos en Solidity y son portables entre sí sin necesidad de reescribirlos, aunque el despliegue y las integraciones requieren adaptación. Se distinguen solo por el modo de despliegue: red propia sin token (Besu), red pública neutral (Ethereum), o cadena soberana interoperable (Avalanche).

Stellar es la única fuera de esa familia y por eso lleva el color diferencial, pues no admite migración hacia las otras tres. Sin embargo su capacidad de elegir qué otros nodos considera confiables ofrece una forma de control o autoridad que las otras no, sin necesidad de desplegar y auditar smart contract. Por ello resulta una alternativa apropiada para aquellas entidades que busquen trazabilidad de fondos y pagos ciudadanos con simplicidad operativa.

Besu · permisionado sin token · EVM Ethereum · pública neutra · EVM Avalanche · cadena soberana · EVM Stellar · pública con acuerdo entre nodos · operaciones nativas (Soroban opcional)

Arquetipo predominante del portafolio

Los 23 desafíos se agrupan en cinco arquetipos técnicos. Uno concentra más de un tercio del portafolio: la notarización documental, es decir, probar que un documento existió, con determinado contenido y en determinada fecha, sin llevar el documento a la cadena.

Notarización documental 8 de 23
Interoperabilidad multi-entidad 5
Credenciales verificables 5
Gobernanza jerárquica 3
Liquidación de valor 2

Arquetipo × red recomendada

BesuEthAvaStel Notarización documental 62·· Interoperabilidad multi-entidad 5·5· Credenciales verificables 5··· Gobernanza jerárquica 3·1· Liquidación de valor 1··2

Lectura de portafolio. Ocho entidades sin relación entre sí llegaron al mismo requisito técnico: sellar un hash con fecha y recuperarlo para verificación. Sumados los cinco de credenciales verificables —que son notarización con un emisor y un formato de credencial encima—, trece de veintitrés casos comparten núcleo, y todos caben en Besu. La decisión de cartera es entonces un servicio común de sellado y verificación sobre red permisionada, con las otras tres redes reservadas a los casos que las justifican.

Por qué el arquetipo predice la red. Los cinco casos de interoperabilidad comparten un obstáculo que no es técnico sino de competencias: cada participante tiene rectoría propia sobre su registro y ninguno puede subordinarse al conjunto de validadores de otro. El JNE y la ONPE son organismos constitucionalmente autónomos; el INGEMMET concurre con MINEM, SUNARP y SERFOR, que responden a sectores distintos; la Autoridad Portuaria coordina terminales privados que compiten entre sí; el OFIS depende de que MINEDU y MINSA le entreguen dato sensible sin ceder control sobre él. Una sola red permisionada exige que alguien administre la membresía, y ese alguien no existe en ninguno de los cinco casos. Avalanche resuelve precisamente eso: cada entidad opera su propia cadena soberana y los mensajes entre ellas se verifican por firma agregada de los validadores de origen, sin que ninguna admita validadores ajenos ni intermediario común. Por eso aparece en los casos donde la interoperabilidad es decisiva, y no en los casos de notarización ni en credenciales, donde hay un emisor único y la pregunta de quién administra la red simplemente no se plantea.

Método de selección del tipo de red

A partir del eje Gobernanza o Valor se seleccionaron 4 redes y se descartaron 2.

Los criterios de selección son:

  • Compatibilidad con el arquetipo de cada desafío público.
  • Compatibilidad con la red ya utilizada por el Estado peruano (LNET), asegurando la futura migración del prototipo sin necesidad de reconstruir y en cumplimiento con la Ley 30.225 que regula las contrataciones.
  • Capacidad de procesamiento nativo a nivel de protocolo que simplifique el diseño y el mantenimiento de los contratos inteligentes, y que no esté disponible en ninguna de las demás redes evaluadas.
  • Naturaleza de los operadores de la infraestructura de la red, crucial para asegurar la soberanía de los datos.
  • Año que comenzó su operación.

Redes evaluadas contra los criterios

Red · entorno Migra a LNET Proceso nativo exclusivo Operadores En operación desde
Hyperledger BesuEVM · Solidity
Federada
2019*
AvalancheEVM · Solidity
Descentralizada · Cadena soberana
2020
EthereumEVM · Solidity
Descentralizada
2015
StellarSoroban · WASM
Federada
2014
CardanoPlutus · UTXO
Descentralizada
2017
MidnightCompact · ZK
Consorcio de corporaciones financieras y tecnológicas
2026

Las cuatro primeras se seleccionaron para la realización de un piloto, mientras Cardano y Midnight se descartaron por no cumplir con ningún criterio.

El entorno de ejecución es el filtro decisivo, puesto que solo lo compilado para EVM migra a LNET sin reconstruir.

Stellar se admite pese a no migrar porque resuelve pagos con operaciones del propio protocolo, sin contratos que desplegar ni auditar.

El guion (–) en Proceso nativo exclusivo no significa ausencia de capacidades: Besu es un cliente de Ethereum, de modo que ambos ejecutan el mismo repertorio de precompilados y operaciones de protocolo y ninguno lo tiene en exclusiva. Este criterio busca distinguir lo que una red ofrece y las demás no: en Avalanche, la mensajería entre cadenas verificada por el propio protocolo; en Stellar, los pagos y la emisión de activos resueltos sin desplegar contrato alguno.

* Hyperledger Besu es un cliente, no una red: el año corresponde a LNET, la red construida sobre Besu que el Estado peruano ya utiliza y hacia la cual migrarían los prototipos. Es la trayectoria que importa para esta decisión.

TECHGOB · Panel de análisis de portafolio GovTech · 2026
Elaborado sobre la base de datos consolidada del diagnóstico y el Taller organizado junto a la SGTD de Perú. Dos entidades quedaron fuera por no declarar un desafío evaluable. Las recomendaciones de red son preliminares y están sujetas a validación en Fase 0.