Blockchain privada vs. pública: cómo elegir y cuándo evitar ambas (2026)

Esta es la cruda realidad sobre el debate entre blockchain pública y privada: para cuando la mayoría de los equipos se lo plantea, ya han elegido mal.

Suele ocurrir así: un directivo leyó algo sobre blockchain, un proveedor presentó su propuesta comercial y alguien dijo «deberíamos hacer esto en una red privada porque la pública parece arriesgada» o, al contrario, «tenemos que ser descentralizados, así que debe ser pública». Se financia una POC. Tres meses después, alguien se da cuenta de que lo que han desarrollado no necesita blockchain en absoluto, o requiere un enfoque completamente distinto a lo que están construyendo.

Ese ciclo se puede evitar. La cuestión de pública frente a privada no es la primera pregunta, ni siquiera la segunda. Es la tercera, y que todo lo demás salga bien depende de acertar primero en las anteriores.

Por eso este artículo plantea algo diferente. Recorre el árbol de decisión real —si necesitas una blockchain, permisionada o no permisionada, qué plataforma elegir y cuándo dar un paso atrás— en el orden en que lo abordaría un equipo técnico competente. Incluyendo las verdades que nadie que venda consultoría blockchain quiere decir en voz alta.

 Las recomendaciones que verás a continuación se basan en lo que realmente funciona en producción y en lo que se cancela en silencio doce meses después de su lanzamiento.

¿Realmente necesitas una blockchain? (La pregunta que descarta el 60 % de los proyectos)

La mayoría de los casos de uso que acaban en una blockchain habrían funcionado mejor con una base de datos distribuida bien diseñada, con un control de acceso sólido, un registro de auditoría firmado y una buena política de copias de seguridad. La blockchain aporta dos cosas que la base de datos no ofrece: confianza descentralizada y constancia inalterable frente a manipulaciones entre partes que no confían plenamente entre sí.

Si no necesitas ninguna de las dos, estás pagando el peaje de la blockchain a cambio de nada. Y la blockchain tiene un coste: es más lenta, más cara de operar, más difícil a la hora de contratar especialistas y bastante más compleja de modificar una vez desplegada.

Aquí tienes un test muy claro en cuatro puntos. La blockchain es la herramienta adecuada cuando:

• Varias partes necesitan compartir estado
• Esas partes no confían del todo entre sí ni en un intermediario único
• Se requiere realmente una única fuente de verdad
• El coste de las disputas, la conciliación o las auditorías es lo bastante alto como para justificar la infraestructura

Si falta cualquiera de estos cuatro puntos, la respuesta honesta suele ser «utiliza una base de datos». Si faltan dos o más, sin duda es «utiliza una base de datos».

Ejemplos concretos. Casos donde la blockchain supera este test:

• Liquidación interbancaria entre entidades competidoras que no actúan como intermediarias entre sí
• Trazabilidad del origen en cadenas de suministro entre proveedores de proveedores, donde ninguna empresa tiene visibilidad de toda la cadena
• Tokenización de activos para bienes inmuebles fraccionados o valores privados, donde el cumplimiento normativo exige demostrar el historial de propiedad
• Protocolos de finanzas descentralizadas (DeFi) donde la razón de ser es la participación abierta sin intermediarios ni guardianes de acceso
• Acreditaciones de identidad digital entre entidades independientes (una universidad expide un título y un empleador extranjero lo verifica, sin depender de un registro central)

Casos donde no supera el test, pero se desarrolla igualmente:

• Gestión documental interna en una sola empresa: una base de datos con almacenamiento firmado resuelve esto al 2 % del coste
• Puntos de fidelización para un único comercio: una base de datos cumple esta función, y la blockchain no aporta descentralización real porque el comercio controla todo el sistema
• Pistas de auditoría para una entidad regulada: una base de datos con encadenamiento criptográfico lo resuelve, y al auditor no le importa que esté en una blockchain
• Estado de flujos de trabajo internos «tokenizados»: tu herramienta de BPM resuelve esto, utilízala

Todos estos son patrones reales. He visto a equipos ponerlos en marcha, conseguir el respaldo de la dirección, quemar entre seis y diez meses y, un año después, rehacerlo discretamente en Postgres una vez se marcharon los consultores. Nadie habla de estos proyectos en los casos de éxito. Y hay un motivo para ello.

Si, tras responder con honestidad a estas cuatro preguntas, tu caso de uso aún necesita una blockchain, perfecto: has superado el primer filtro. La mayoría de las ideas que nacen con un «deberíamos explorar blockchain» no lo pasan. Las que lo consiguen son las interesantes. Ahí es donde la elección entre pública o privada se convierte en el debate real.

La verdadera diferencia no es pública frente a privada, sino permisionada frente a no permisionada

Una rápida aclaración de términos, porque aquí empieza la mitad de la confusión. «Pública» y «privada» son simplificaciones, y bastante imprecisas. Las propiedades que determinan de verdad las decisiones de arquitectura son las redes permisionadas frente a las no permisionadas.

No permisionada: cualquiera puede unirse, ejecutar un nodo, validar y realizar transacciones. Sin barreras de acceso. La red confía en la criptografía y en los incentivos económicos para mantener la honestidad de los participantes. Ethereum, Bitcoin, Solana, Polygon PoS y Avalanche C-Chain son las redes no permisionadas de referencia.

Permisionada: los participantes están identificados y autorizados para unirse a la red. Un órgano de gobierno —un consorcio de entidades, una única empresa o, en ocasiones, un regulador— decide quién entra. La red confía en la criptografía junto con la identidad institucional. Hyperledger Fabric, R3 Corda y Quorum son las redes permisionadas de referencia.

Luego están las variantes que a muchos artículos les encanta tratar como categorías independientes, aunque en el fondo no lo sean:

• Consorcio: una modalidad específica de red permisionada, gobernada de forma conjunta por un grupo de organizaciones. La mayoría de los despliegues de blockchain empresarial son redes de consorcio, aunque el marketing las llame «privadas».
• Híbrida: un núcleo permisionado con un anclaje en una cadena pública para garantizar la auditabilidad. No es tanto una arquitectura propia como un modelo de despliegue cada vez más habitual.

En la práctica, la frontera entre pública y privada tampoco es tajante. Polygon no es permisionada en su capa base, pero admite configuraciones permisionadas. Ethereum puede ejecutarse como un fork privado para un único consorcio; varios despliegues empresariales de gran envergadura hacen exactamente esto. Lo decisivo no es qué cadena utilizas, sino cómo configuras la participación, la validación y la visibilidad de los datos en su interior.

En el resto de este artículo seguiremos utilizando «privada» y «pública» porque son los términos que buscan las empresas. Ten en cuenta que equivalen a «permisionada» y «no permisionada». Esta distinción es fundamental a la hora de definir los requisitos técnicos.

Definición de blockchain pública y privada

Un breve repaso conceptual para quienes hayan llegado aquí directamente. Puedes saltarte esta sección si ya tienes claros los conceptos básicos.

¿Qué es una blockchain pública?

Una blockchain pública es una red abierta y no permisionada donde cualquier persona con conexión a internet puede ejecutar un nodo, validar transacciones y operar. No existe una autoridad central, guardianes de acceso ni listas de miembros. El registro es accesible a escala global: cada transacción, cada dirección y cada llamada a un smart contract (contrato inteligente) es de dominio público. Bitcoin es el ejemplo por excelencia. Ethereum es la referencia para cadenas públicas con soporte de smart contracts. Solana, Polygon PoS y Avalanche entran en la misma categoría, aunque sus arquitecturas técnicas difieran.

Su modelo de seguridad es económico. Los validadores son quienes deciden bloquear capital en staking (prueba de participación o proof of stake) o consumir electricidad (prueba de trabajo o proof of work), y el protocolo está diseñado para que atacar la red resulte más costoso que operar de forma legítima. La confianza se apoya en las matemáticas y en las fuerzas del mercado, en lugar de en identidades o acuerdos legales.

Ventajas de una blockchain pública

Los motivos por los que merece la pena desarrollar sobre cadenas públicas, cuando encajan con el proyecto:

• Participación verdaderamente abierta: sin procesos de incorporación complejos, sin filtros de KYC en la capa de protocolo y sin intermediarios con capacidad para revocar el acceso
• Transparencia y auditabilidad por defecto: el estado de la cadena es visible para cualquiera, lo que a veces es un inconveniente, pero muy a menudo una gran ventaja
• Resistencia a la censura: ninguna entidad puede impedir de forma unilateral que una transacción se procese e incluya
• Efectos de red y liquidez: las cadenas públicas (en especial Ethereum y sus L2) cuentan con amplios ecosistemas de desarrolladores, herramientas y capital a los que conectarse
• Interoperabilidad con el ecosistema cripto general: stablecoins, puentes (bridges), primitivas de DeFi e infraestructura de NFT conviven en las cadenas públicas
• Inmutabilidad de las transacciones liquidadas: una vez confirmada, ningún operador o administrador puede revertir una transacción

Desventajas de una blockchain pública

Los costes y limitaciones, explicados con franqueza:

• El rendimiento (throughput) es inferior al de una base de datos o una red permisionada: incluso Solana o las L2 modernas ofrecen cifras por debajo de lo que alcanza habitualmente la infraestructura empresarial
• Los costes por transacción se pagan en el token nativo de la red, lo que los expone a la volatilidad del mercado; los picos de gas son una realidad muy tangible
• La privacidad no se configura de forma nativa, sino que debe añadirse por capas: las pruebas de conocimiento cero (ZK) y la computación fuera de la cadena son viables, pero exigen mucho tiempo de desarrollo
• La postura regulatoria sobre las cadenas públicas evoluciona constantemente y varía según la jurisdicción; esa incertidumbre es real y no debe pasarse por alto
• La firmeza de las transacciones (finality) es probabilística en muchas redes públicas en lugar de inmediata, lo que influye en procesos de liquidación con acuerdos de nivel de servicio (SLA) estrictos
• Cumplir normativas de protección de datos como el derecho al olvido del RGPD resulta complejo a nivel de arquitectura en un registro inmutable

¿Qué es una blockchain privada?

Una blockchain privada —o más exactamente, una blockchain permisionada— es una red donde la participación está controlada. Un órgano de gobierno, ya sea una única entidad, un consorcio de organizaciones o una autoridad reguladora, decide quién puede ejecutar un nodo, quién puede validar y quién tiene acceso de lectura a los datos. La identidad se gestiona en la capa de protocolo y la pertenencia a la red es explícita.

Hyperledger Fabric, R3 Corda y Quorum son los ejemplos representativos. Lo que comparten no es tanto una tecnología específica como un modelo de gobernanza: la confianza se fundamenta en la identidad institucional y en acuerdos legales entre participantes identificados, y no en incentivos económicos entre actores anónimos. En la mayoría de los despliegues reales, una blockchain «privada» es en realidad un consorcio: varias organizaciones que comparten la gobernanza, en lugar de una sola compañía operando una cadena por su cuenta.

Ventajas de una blockchain privada

Por qué las empresas eligen cadenas privadas:

• Alto rendimiento y baja latencia: el consenso permisionado con un número reducido de validadores ofrece confirmaciones en menos de un segundo y miles de TPS
• Visibilidad de datos configurable: los canales, las transacciones privadas y el intercambio punto a punto permiten que diferentes participantes vean distintos conjuntos de datos sin necesidad de complejas soluciones criptográficas
• Costes predecibles: gastos operativos en lugar de tarifas por transacción, sin exposición a la volatilidad del mercado de tokens
• Adecuación regulatoria para participantes identificados: el cumplimiento de normativas KYC y PBC/AML puede integrarse en la capa de red, lo que facilita enormemente trabajar con entidades reguladas
• Flexibilidad en la gobernanza: el consorcio puede actualizar el protocolo, modificar normativas y resolver conflictos sin necesidad de un consenso global
• Mayor facilidad para cumplir la protección de datos: rectificar o suprimir información es técnicamente viable cuando la gobernanza lo autoriza

Desventajas de una blockchain privada

Los inconvenientes, que a menudo se minimizan en el marketing de blockchain empresarial:

• La seguridad depende de la fiabilidad del grupo de validadores: si el 51 % de los miembros del consorcio actúa de forma concertada o sufre una brecha de seguridad, el historial puede reescribirse
• Los efectos de red se limitan al consorcio: no es posible aprovechar el ecosistema más amplio de herramientas, liquidez y componibilidad que ofrecen las cadenas públicas
• La carga operativa es considerable: gestionar la infraestructura, administrar accesos, coordinar actualizaciones y resolver discrepancias requiere un esfuerzo continuado
• Dependencia del proveedor y del consorcio: abandonar un consorcio de Fabric o migrar desde Corda no es un proceso sencillo una vez consolidado el proyecto
• El desafío de la gobernanza suele ser más complejo que el técnico: definir quién puede modificar cada regla y en qué momento frena más proyectos de consorcio que cualquier incidencia técnica
• La pregunta honesta sobre si realmente necesitabas una blockchain (ver primera sección) cobra especial relevancia en redes privadas: es fácil terminar desarrollando por error una base de datos distribuida muy costosa

Cuatro factores de decisión más importantes que la tabla de características

La clásica tabla comparativa que aparece en la mayoría de los artículos sobre blockchain apenas sirve para tomar decisiones prácticas. Decir que «la pública ofrece transparencia y la privada privacidad» no ayuda a definir una arquitectura. Las preguntas que realmente determinan las decisiones de diseño son estas cuatro.

¿Quién puede participar?

El grado de apertura de la capa de participación. Las redes no permisionadas permiten que cualquiera con conexión a internet y un monedero (wallet) se una y opere, sin comprobaciones de identidad, filtros de acceso ni procesos de alta. Las redes permisionadas regulan el acceso mediante KYC, acuerdos de adhesión o votaciones de gobernanza.

Para casos de uso donde los participantes son entidades reguladas —bancos, sociedades de valores, proveedores de salud o administraciones públicas—, el modelo permisionado suele ser obligatorio por mero cumplimiento normativo. El regulador exige saber quién opera en la red, y «cualquiera en internet» no es una respuesta válida cuando se transmiten datos médicos o instrucciones de liquidación.

Para casos de uso donde el valor reside en la participación abierta —DeFi para usuarios finales, marketplaces de NFT abiertos, aplicaciones resistentes a la censura o transferencias internacionales—, el modelo no permisionado es fundamental. Imponer barreras de acceso desvirtúa el producto.

Solo esta pregunta resuelve cerca del 60 % de las dudas entre pública y privada. Si conoces a tus usuarios y necesitas verificar su identidad antes de que interactúen con el sistema, debes optar por una red permisionada. Si no los conoces ni necesitas saber quiénes son, debes elegir una red no permisionada.

¿Quién valida las transacciones?

La capa de consenso. Aquí es donde las repercusiones arquitectónicas se vuelven tangibles.

Las cadenas no permisionadas emplean consensos basados en seguridad económica: prueba de trabajo (Bitcoin), prueba de participación (Ethereum tras The Merge, Solana, Polygon) o variantes de prueba de participación delegada. El principio es que los validadores son quienes deciden arriesgar capital, y el protocolo se encarga de que atacar la red resulte más costoso que cumplir sus normas.

Las cadenas permisionadas recurren al consenso institucional: variantes de Practical Byzantine Fault Tolerance (PBFT), Raft o Istanbul BFT. Aquí los validadores son organizaciones concretas e identificadas que han acordado participar, y el protocolo solo necesita mantenerlas sincronizadas, incluso si una minoría falla o se desconecta.

Efectos directos en la práctica:

• El consenso permisionado es mucho más rápido: confirma transacciones en milisegundos o pocos segundos, frente a los bloques de aproximadamente 12 segundos de Ethereum o los cerca de 60 minutos de firmeza económica en Bitcoin.
• El consenso permisionado es notablemente más económico por transacción: asumes costes de infraestructura, no pagas tarifas de gas.
• El consenso permisionado solo es tan fiable como las instituciones que validan: si el 51 % del consorcio decide alterar el historial, puede hacerlo. La seguridad económica se sustituye por la reputación institucional y los acuerdos legales.

Por esta última razón, el consenso permisionado encaja a la perfección en una red de liquidación entre bancos regulados (sujetos a suficientes restricciones legales y reputacionales como para evitar colusiones) y resulta inadecuado para un sistema de oráculos descentralizados (donde el objetivo es precisamente evitar ese riesgo de colusión).

¿Quién puede ver los datos?

La capa de visibilidad. En una cadena pública no permisionada, el historial de transacciones es visible globalmente por defecto. Cada dirección, cada importe y cada llamada a un smart contract queda registrado públicamente. La privacidad debe incorporarse por capas mediante pruebas de conocimiento cero, esquemas de commit-reveal o computación fuera de la cadena. Es perfectamente viable, pero nada trivial y costoso tanto en capacidad de cómputo como en tiempo de ingeniería.

En una red permisionada, la visibilidad de los datos es configurable por diseño. Hyperledger Fabric cuenta con «canales», que son esencialmente subredes donde organizaciones específicas ven datos específicos. Corda va más allá: los datos se comparten punto a punto entre participantes, sin replicarse a todos. Quorum dispone de transacciones privadas. Cada una de estas opciones permite que distintos participantes vean diferentes subconjuntos de datos, sin complicaciones criptográficas innecesarias.

Para casos de uso empresariales con requisitos reales de confidencialidad (estrategias de trading, historiales médicos, precios de proveedores), las redes permisionadas resultan mucho más sencillas de desplegar. No porque la privacidad sea imposible en las redes públicas, sino porque el presupuesto de ingeniería que destinarías a circuitos ZK y capas de privacidad adicionales rinde mejor simplemente usando una blockchain que soporte visibilidad selectiva de forma nativa.

¿Quién asume el coste de funcionamiento?

La capa económica, en la que casi nadie repara hasta el segundo año de operación.

Las redes públicas cobran comisiones de transacción en el token nativo de la red. ETH en Ethereum, MATIC en Polygon, SOL en Solana. Quien ejecuta una DApp paga por cada transacción, y esos costes pueden dispararse de forma impredecible (basta recordar cómo cada emisión masiva de NFT llegó a situar temporalmente el gas de Ethereum en 200 $ por transacción). Tus costes operativos dependen del uso y quedan expuestos al mercado.

Las redes permisionadas son costeadas directamente por los miembros del consorcio. Implican costes de infraestructura —servidores, operaciones, monitorización— en lugar de comisiones por transacción. Es un modelo más predecible y menos expuesto a las fluctuaciones de mercado del token nativo.

A largo plazo y con altos volúmenes de transacción, las opciones permisionadas suelen ser más económicas. Con volúmenes bajos, el coste fijo de infraestructura de una red permisionada puede hacer que las redes públicas resulten más rentables, sobre todo desde que las L2 como Arbitrum y Base redujeron las comisiones a fracciones de céntimo.

Las plataformas que realmente importan en 2026

Esta sección analiza las plataformas que de forma realista llegan a la lista final de candidatos en un entorno empresarial. Hoy en día existen cientos de L1 y L2, pero la mayoría son irrelevantes para tu decisión. Estas son las que importan.

Ethereum (no permisionada)

La opción por defecto para todo lo que requiera smart contracts abiertos y programables. Tras The Merge y la consolidación de múltiples rollups L2 (Optimism, Arbitrum, Base, zkSync, Scroll), en 2026 Ethereum es más un ecosistema que una sola red.

Para los compradores corporativos, la alternativa más realista suele ser recurrir a L2 compatibles con Ethereum antes que a la propia mainnet. Son mucho más económicas, ofrecen finalidad más rápida y siguen aprovechando el modelo de seguridad de Ethereum para la liquidación. La mainnet queda para operaciones que exigen máxima descentralización y admiten pagar entre 1 $ y 5 $ por transacción. Hoy en día, la mayor parte de la actividad real de las aplicaciones se concentra en las L2.

Puntos fuertes: el mayor ecosistema de desarrolladores con diferencia, el conjunto de herramientas más maduro, máxima liquidez y amplia familiaridad regulatoria. Puntos débiles: el panorama de L2 continúa fragmentándose, los puentes entre L2 siguen siendo un problema de UX sin resolver por completo y elegir «Ethereum» obliga ahora a seleccionar también una L2. Consulta nuestro trabajo en desarrollo de Ethereum para conocer el estado actual.

Polygon (no permisionada, compatible con Ethereum)

La opción no permisionada de referencia orientada al sector empresarial. Compatible con EVM, bajas comisiones y despliegues empresariales reales (Starbucks Odyssey antes de su cierre, Nike .Swoosh antes de finalizar, coleccionables de Reddit o diversas pruebas de concepto en cadenas de suministro). La suite completa de Polygon incluye ahora Polygon zkEVM y Polygon CDK para redes específicas por aplicación.

Puntos fuertes: la vía más económica para desplegar contratos compatibles con Ethereum a escala, excelente experiencia de desarrollo y una estrategia comercial muy activa para empresas. Puntos débiles: muchas alianzas con grandes marcas no tuvieron continuidad en el tiempo, la economía del token ha sido compleja y la red ha sufrido incidentes de seguridad. El desarrollo en Polygon es el destino habitual de la mayoría de nuestros clientes medianos que buscan una red no permisionada con costes viables para empresa.

Solana (no permisionada)

Alto rendimiento (teóricamente 65.000 TPS, en la práctica varios miles), costes mínimos y finalidad en menos de un segundo. Se utiliza en aplicaciones de consumo, DeFi de alta frecuencia, marketplaces de NFT y pagos en tiempo real. El stack de desarrollo en Rust de Solana en lugar de Solidity es un factor clave si tu equipo ya domina el entorno EVM.

La adopción empresarial está creciendo, pero históricamente se ha visto frenada por el historial de caídas de la red (múltiples interrupciones de varias horas entre 2022 y 2023, en gran parte resueltas pero aún presentes en la memoria institucional). Quien evalúe Solana para entornos corporativos en 2026 seguramente ya haya tenido que definir qué supondría una parada de Solana para sus SLA, y esa respuesta determina si resulta viable para su caso. Revisa desarrollo en Solana para analizar los aspectos prácticos.

Hyperledger Fabric (permisionada)

La blockchain empresarial más desplegada a nivel global. Originada en IBM y gestionada actualmente bajo el proyecto Hyperledger de la Linux Foundation. Cuenta con consenso modular, canales de datos privados y chaincode escrito en Go, JavaScript o Java en lugar de smart contracts convencionales.

Concebida para el mundo corporativo en cada una de sus decisiones de diseño. Los canales permiten que distintas organizaciones visualicen subconjuntos específicos de información. El Membership Service Provider resuelve la gestión de identidades. El consenso modular te permite escoger PBFT o Raft según tu modelo de confianza. Es la elección canónica para redes de consorcio, en especial cuando IBM ya forma parte de los proveedores de la cuenta.

Puntos fuertes: la red permisionada más madura, presencia real en producción, documentación exhaustiva y amplio respaldo de proveedores. Puntos débiles: compleja a nivel operativo, curva de aprendizaje pronunciada para equipos habituados a Ethereum y cierta pérdida de impulso general de las blockchains de consorcio desde 2022. Sigue siendo la opción estándar para proyectos de consorcio bancario y cadena de suministro. Nuestra práctica de Hyperledger Fabric detalla su implementación.

R3 Corda (permisionada, especializada)

Diseñada específicamente para servicios financieros. Cabe destacar que Corda no es estrictamente una blockchain tradicional: los datos se comparten punto a punto entre participantes, sin replicarse en cada nodo de un libro contable global. Lejos de ser un defecto, esto constituye una ventaja clave para flujos financieros regulados, donde los datos de negociación entre contrapartes no deben quedar expuestos al resto de participantes.

Estructurada en torno a los elementos que realmente utiliza el sector financiero: notarios, contratos en Kotlin o Java y flujos de trabajo en vez de smart contracts tradicionales. Muy sólida en cambio de divisas, derivados, préstamos sindicados y liquidación interbancaria. Su aplicabilidad es más acotada que la de Fabric —no la verás en cadena de suministro o salud—, pero resulta sumamente potente en su nicho.

Quorum, Besu y otras redes permisionadas derivadas de Ethereum

Quorum nació como un fork de Ethereum creado por JP Morgan para entornos permisionados. Actualmente bajo ConsenSys, su futuro estratégico ha sido incierto durante un par de años; conviene evaluar su estado antes de comprometerse. Hyperledger Besu sigue siendo una alternativa sólida de cliente Ethereum para redes permisionadas, con consenso IBFT2. Las redes Geth privadas también siguen utilizándose.

El atractivo de esta categoría radica en disponer de las herramientas de Ethereum (Solidity, Truffle o Hardhat, monederos compatibles con MetaMask) combinadas con características permisionadas. La propuesta consiste en «desarrolladores de Ethereum en una red privada». La realidad es más dispar: se ejecuta un consenso permisionado con menor rodaje en producción y con una comunidad más reducida que la de Fabric por un lado y la de Ethereum por el otro.

Cosmos, Polkadot y el enfoque de cadenas específicas para aplicaciones

El término medio emergente, especialmente interesante para empresas en 2026. Las zonas de Cosmos y las parachains de Polkadot permiten a un consorcio o a una sola organización gestionar su propia red soberana sin perder la interoperabilidad con un ecosistema más amplio mediante IBC (Cosmos) o XCM (Polkadot).

Aquí es donde los modelos híbridos cobran auténtico sentido. Obtienes el control de una red permisionada (tu propio grupo de validadores, tu gobernanza y tus reglas de visibilidad de datos) junto con la conectividad a un ecosistema no permisionado cuando lo necesitas. El protocolo Inter-Blockchain Communication (Cosmos) y XCM (Polkadot) cuentan con suficiente madurez en 2026 para que la interoperabilidad entre cadenas deje de ser el desafío de investigación de hace cinco años. Para consorcios que buscan soberanía sin aislamiento, la vía de las app-chains merece una seria consideración. Su adopción empresarial es aún más incipiente que la de Fabric, pero avanza con rapidez.

Comparativa de plataformas de un vistazo

Un recurso de referencia. No lo tomes como la decisión definitiva, sino como la guía rápida a la que recurrir mientras valoras las cuatro dimensiones de decisión anteriores.

Plataforma	Permisos	TPS realistas	Finalidad	Lenguaje de contratos	Ideal para / aspectos a vigilar
Ethereum mainnet	No permisionada	~15	~12 s (económica)	Solidity, Vyper	Máxima descentralización y ecosistema más profundo. Coste y rendimiento limitados: recurre a L2.
Ethereum L2 (Arbitrum, Base)	No permisionada	~2.000+	De segundos a minutos	Solidity	El entorno práctico para la mayoría de dApps en 2026. La UX de los puentes aún debe mejorar.
Polygon PoS	No permisionada	~7.000	~2 s	Solidity	Costes accesibles para empresas. Incidentes de seguridad pasados; vigilar gobernanza.
Solana	No permisionada	~3.000–4.000	<1 s	Rust	Velocidad y bajo coste. El historial de caídas es crítico para casos con SLA exigentes.
Hyperledger Fabric	Permisionada	~1.000–3.000	~1 s	Go, JS, Java	Opción por defecto para consorcios. Operativamente compleja.
R3 Corda	Permisionada	~600+	Inferior a un segundo	Kotlin, Java	Especializada en servicios financieros. Nicho acotado pero muy profundo.
Cosmos app-chain	Ambas	~10.000	~6 s	CosmWasm (Rust)	Cadena soberana con interoperabilidad. Aún en maduración en el ámbito corporativo.

Una advertencia sobre esta tabla: las cifras de rendimiento corresponden a lo que las plataformas sostienen de forma fiable en producción, no a sus reclamos de marketing. Los máximos teóricos varían notablemente: Solana anuncia 65.000 TPS y Fabric ha publicado pruebas de rendimiento de más de 20.000 TPS en entornos controlados. Ninguna de esas cifras es la que verás en la red donde realmente despliegues.

Cómo asignar los casos de uso al modelo adecuado

Seis casos de uso analizados con recomendaciones francas. Sin listas comerciales: una valoración práctica.

Liquidación interbancaria entre entidades reguladas

Permisionada. Con casi total seguridad, Corda o Fabric. Los participantes son entidades reguladas e identificadas, la confidencialidad de las operaciones no es negociable, la finalidad de la liquidación exige nivel institucional y el regulador demanda supervisar todo el sistema bajo una gobernanza con participantes nominales. Es el escenario exacto para el que se concibieron las redes permisionadas, y donde demuestran su valor.

Marketplace público de activos inmobiliarios tokenizados

No permisionada. Ethereum L2 o Polygon. La propuesta central reside en que «cualquiera puede adquirir una fracción», de modo que la participación abierta constituye la funcionalidad principal. Una red permisionada desvirtuaría por completo el producto. La auditabilidad de los smart contracts genera confianza para los clientes, no un riesgo. El cumplimiento normativo (KYC para inversores) se gestiona en la capa de aplicación, no a nivel de red.

Trazabilidad en cadena de suministro entre proveedores multinivel

Un consorcio permisionado (Fabric) suele ser la alternativa habitual y generalmente la correcta para la primera fase. Sin embargo, en 2026 la estrategia más avanzada es híbrida: una red permisionada para el detalle transaccional, con anclajes periódicos a una red pública (Ethereum o Polygon) para permitir auditorías independientes. De este modo, las organizaciones obtienen la privacidad y el rendimiento de una red permisionada, sumados a un registro público a prueba de manipulaciones verificable por auditores externos o clientes. Conviene contemplarlo desde el primer día en lugar de añadirlo a posteriori. Revisa nuestro trabajo sobre gestión documental en blockchain para patrones afines.

Identidad digital y credenciales verificables

Depende por completo de quién sea el emisor y de qué grado de apertura pública requiera el uso. Para identidades corporativas o gubernamentales (credenciales de empleados, licencias profesionales), el modelo permisionado tiene sentido: el emisor es la autoridad de confianza, la verificación se realiza contra anclajes de identidad reconocidos y la privacidad de los datos es fundamental. Para identidad autosoberana, donde cada persona gestiona sus propias credenciales y cualquiera puede verificarlas, el modelo no permisionado es arquitectónicamente natural. Desconfía de quienes intenten ofrecerte una solución única para ambos casos.

Protocolo DeFi o exchange descentralizado (DEX)

No permisionada, prácticamente sin otra alternativa. Un protocolo DeFi en red permisionada es una contradicción conceptual. Si estás construyendo algo que deba operar con el ecosistema DeFi existente, una L2 de Ethereum o una red compatible con EVM es la opción obligada. Los proyectos de desarrollo DeFi que hemos implementado coinciden sistemáticamente en este punto.

Gestión documental interna con requisitos de auditoría

Vuelve a aplicar las cuatro preguntas clave. En serio. Si los documentos están bajo el control de una sola organización y el auditor es la única parte externa, una base de datos bien diseñada con encadenamiento criptográfico de registros cubrirá cada necesidad real por una fracción mínima del coste. En este caso, recurrir a blockchain casi siempre equivale a buscar un problema para una solución previa. Si alguien de tu equipo insiste en utilizar blockchain por este motivo, anímale primero a estructurar un modelo adecuado en Postgres y comprueba si el proyecto sigue resultando atractivo.

Cuándo blockchain es la herramienta equivocada, sin importar el tipo

A nadie dentro del sector blockchain le agrada escribir esta sección. Aun así, conviene abordarla: las promesas exageradas son habituales en este ámbito y la honestidad es la mejor baza de credibilidad a largo plazo. Estos son los escenarios donde blockchain (pública o privada) no supera la evaluación y no debería ser tu elección:

• Una sola entidad centraliza todos los datos de todos modos. Una base de datos con un registro de auditoría firmado es más económica y cumple exactamente la misma función.
• Ya existe un intermediario de confianza, opera correctamente y no aplica tarifas que justifiquen su eliminación. La propuesta de blockchain consiste en prescindir del intermediario. Si no hay un problema de intermediación, la propuesta de blockchain carece de sentido.
• Los requerimientos de rendimiento son genuinamente de alta frecuencia: decenas de miles de transacciones por segundo de forma sostenida. Incluso las blockchains más veloces no compiten en ese nivel salvo en benchmarks muy concretos. Si estás construyendo un motor de trading en tiempo real o un switch de pagos, utiliza infraestructura especializada.
• Los requisitos de privacidad de datos chocan con el modelo de visibilidad de la red y no has presupuestado la capa de privacidad adicional. Las pruebas de conocimiento cero (ZK) no son gratuitas. Los canales y las transacciones privadas tienen sus propias contrapartidas técnicas. Conviene definir esto en la fase de alcance, nunca durante el despliegue.
• La normativa exige garantías específicas de residencia de datos o de derecho al olvido que la arquitectura blockchain dificulta. El derecho de supresión del RGPD encaja difícilmente en un registro inmutable. Tiene solución, pero exige planificar minuciosamente la arquitectura desde el inicio.
• El objetivo declarado es «queremos hacer algo con blockchain». Cuando un proyecto se concibe de forma inversa, impulsado solo por el afán de usar la tecnología, el resultado suele ser predecible. Huye de ese enfoque.

El planteamiento verdaderamente profesional no consiste en recurrir a blockchain solo porque figura en la hoja de ruta. Se trata de escoger la arquitectura más sencilla que resuelva el requisito real. A veces será una red pública. Otras veces, una permisionada. Y con frecuencia, una base de datos bien diseñada. La decisión debe responder a las necesidades del proyecto, no a una lista de deseos tecnológicos.

Los datos de mercado reflejan una sólida adopción de blockchain pública para tokenización

Un ámbito donde el debate entre blockchain pública y privada se está resolviendo discretamente a la vista de todos es la tokenización de activos: la categoría que abarca bonos y letras del tesoro tokenizados, activos del mundo real (RWA), stablecoins y security tokens. Conviene analizar las cifras, ya que muestran hacia dónde se dirige realmente el capital empresarial, en lugar de lo que prometen los casos de éxito sobre el papel.

Un informe reciente de InvestaX, plataforma de tokenización autorizada en Singapur, reúne los datos. A fecha de mayo de 2024, alrededor del 60 % de los productos de deuda pública tokenizada operaban en Ethereum (según The Block), el 87 % del valor total bloqueado en tokens RWA residía en Ethereum (según DefiLlama) y seis de los siete principales protocolos de RWA se desplegaban en Ethereum (según RWA.xyz). El informe de Grayscale «Public Blockchains and the Tokenization Revolution» llega a la misma conclusión: los bancos han explorado la infraestructura privada sobre todo por limitaciones regulatorias, pero las gestoras de activos se han decantado por blockchains públicas o soluciones híbridas.

En este contexto, se prevé que el mercado global de blockchain crezca de unos 44 mil millones de dólares en 2025 a cerca de 746 mil millones en 2032 (Fortune Business Insights), con una tasa anual compuesta superior al 50 %. Una parte importante de ese crecimiento corresponde a la tokenización.

Los motivos de esta inclinación hacia las redes públicas en este caso de uso concreto son la interoperabilidad (los tokens RWA que conviven con stablecoins, garantías DeFi y pools de liquidez son mucho más valiosos que los aislados), los efectos de red (los mejores desarrolladores, las herramientas más avanzadas y la mayor parte del capital están en las redes públicas) y la claridad regulatoria, que empieza a consolidarse en las principales jurisdicciones para valores tokenizados en infraestructuras públicas.

Esto no significa que las cadenas públicas sean la opción acertada para cualquier proyecto de tokenización. Un banco que necesite tokenizar su cartera interna de negociación, con contrapartes que sean exclusivamente otras entidades reguladas, tiene motivos de sobra para utilizar Corda o Fabric. Pero para las gestoras de fondos que buscan emitir tokens que se vayan a negociar, custodiar en protocolos DeFi o utilizar como colateral en el ecosistema general de activos digitales, los datos señalan con total claridad dónde está la actividad.

Toma esto como un dato de referencia a la hora de elegir tu plataforma, no como una imposición. El criterio de las cuatro preguntas expuesto al inicio de este artículo sigue vigente: si tu caso de uso de tokenización no necesita la interoperabilidad que ofrece una red pública, una solución permisionada puede seguir siendo la respuesta correcta. Estas cifras son relevantes para afinar el análisis, pero no sustituyen el encaje arquitectónico de fondo.

Cómo decidir de verdad: marco de trabajo en cuatro pasos

Uniendo todas las piezas: si estás valorando esto ahora mismo para un proyecto real, este es el orden a seguir:

1. Aplica el test de las cuatro preguntas para blockchain: ¿varias partes comparten estado? ¿Existe confianza parcial? ¿Se requiere una única fuente de verdad? ¿Es alto el coste de resolución de disputas? Si cualquiera de ellas falla, la respuesta es clara: no construyas sobre blockchain. Diseña primero una base de datos adecuada.
2. Elige entre red permisionada o no permisionada según la participación. ¿Quiénes participan? ¿Cuentan ya con una identidad verificada? ¿La participación abierta es una funcionalidad clave del producto o un obstáculo de cumplimiento normativo? Esta cuestión resuelve por sí sola la mayor parte del debate entre público y privado.
3. Filtra la plataforma según tus restricciones operativas: rendimiento (throughput), finalidad de las transacciones, gobernanza, costes, stack de desarrollo, encaje regulatorio y competencias actuales del equipo. Aquí es donde Ethereum, Solana, Polygon, Fabric, Corda y Cosmos presentan diferencias determinantes.
4. Desarrolla prototipos reales y objetivos. Construye la misma solución en las dos plataformas más viables para tu caso de uso. Mide resultados en lugar de fiarte de presentaciones comerciales. La mayoría de los equipos se saltan este paso y terminan arrepintiéndose, a veces asumiendo costes elevados. Un spike técnico de dos semanas te ahorra seis meses de un despliegue erróneo.

El error más habitual consiste en saltarse el paso 1 (presionados por «el consejo directivo quiere blockchain») y el paso 4 (presionados por «ya hemos elegido la plataforma»). Ambos atajos conducen a proyectos que parecen avanzar bien justo hasta el momento en que fracasan.

Conclusión

La decisión entre blockchain pública y privada se plantea mal en la mayoría de los artículos, y ese enfoque erróneo explica buena parte de los proyectos que descarrilan. El árbol de decisión real sitúa en la cima la pregunta «¿debemos construir sobre blockchain?», en el medio la elección entre «red permisionada o no permisionada» y en la base la selección de plataforma; manteniendo en todo momento en segundo plano la posibilidad de que blockchain no sea la herramienta adecuada.

Si aciertas con la primera pregunta, el resto resulta mucho más sencillo. La mayoría de los casos de uso que superan el test de cuatro partes encuentran una respuesta evidente entre red permisionada o pública en cuanto se define quién participa y quién valida. Casi todas las listas de plataformas se reducen a dos opciones reales al filtrar por rendimiento, finalidad y competencias del equipo. Construye prototipos antes de comprometerte y eliminarás de raíz la mayor parte del riesgo del proyecto.

Si estás analizando esto ahora —especialmente si te encuentras en ese momento incierto entre «creemos que blockchain puede aportar valor» y «estamos listos para definir el alcance del desarrollo»—, esa es la conversación donde la ayuda externa amortiza con creces su coste. Llevamos siete años trabajando a ambos lados de la frontera entre redes públicas y privadas; te diremos con total honestidad en qué lado encaja tu necesidad y si realmente tiene sentido utilizar una blockchain. Contáctanos y estudiaremos juntos qué quieres construir en la práctica.