Capa de seguridad compartida

¿Qué es una capa de seguridad compartida?

Una capa de seguridad compartida es un modelo de seguridad blockchain en el que varias cadenas, servicios, aplicaciones o módulos dependen de un conjunto común de validadores, de staking agrupado o de garantías reutilizadas mediante restaking, en lugar de desarrollar su propia seguridad desde cero.

En el ámbito cripto, una capa de seguridad compartida permite a las nuevas redes tomar prestada o aprovechar la seguridad económica de un sistema más amplio que ya cuenta con validadores, participantes en staking, gobernanza e infraestructura de seguridad.

La documentación oficial de la relay chain de Polkadot describe la seguridad compartida como un modelo en el que las cadenas conectadas se benefician de Nominated Proof of Stake sin tener que poner en marcha su propia seguridad.

La documentación oficial de Interchain Security de Cosmos Hub describe Interchain Security como una plataforma para lanzar cadenas basadas en Cosmos-SDK que pueden aprovechar el conjunto de validadores, el staking y la comunidad de Cosmos Hub.

La descripción general oficial de EigenLayer presenta el restaking como un sistema que permite a los participantes en staking proporcionar seguridad a los servicios del ecosistema EigenLayer.

Una capa de seguridad compartida puede dar soporte a appchains, parachains, consumer chains, servicios de disponibilidad de datos, sistemas de oráculos, bridges, infraestructura de rollups y otras redes cripto que necesitan una seguridad fiable.

El objetivo principal es reducir el coste y la dificultad de lanzar una infraestructura segura.

En lugar de que cada nueva cadena tenga que atraer a sus propios validadores y crear su propia economía de tokens de staking, puede conectarse a una base de seguridad más amplia.

En pocas palabras, una capa de seguridad compartida es una base de seguridad que muchos sistemas cripto pueden utilizar al mismo tiempo.

Por qué son importantes las capas de seguridad compartida

Las capas de seguridad compartida son importantes porque resulta difícil proteger de forma independiente las nuevas blockchains y los nuevos servicios.

Una red pequeña con un conjunto de validadores débil puede ser más fácil de atacar, censurar, detener o manipular.

Una nueva cadena puede contar con tecnología sólida y, aun así, no atraer suficientes validadores, delegadores, stake, supervisión, liquidez y participación en la gobernanza.

La seguridad compartida puede facilitarlo al permitir que los nuevos sistemas accedan a un fondo de seguridad económica ya existente.

Esto puede reducir los costes iniciales para los desarrolladores y mejorar la seguridad de los usuarios.

También puede mejorar la interoperabilidad, ya que los sistemas protegidos por la misma capa pueden compartir reglas de mensajería, supuestos sobre los validadores o relaciones de liquidación.

La documentación oficial de las parachains de Polkadot indica que estas se benefician de la seguridad compartida, la interoperabilidad y la escalabilidad, al tiempo que se centran en la lógica específica de sus aplicaciones.

La seguridad compartida es especialmente importante en el diseño de blockchains modulares, porque la ejecución, la liquidación, el consenso, la disponibilidad de datos y la verificación pueden tener lugar en distintas partes.

Cuando estas funciones se separan, a los usuarios les resulta más difícil entender los supuestos de seguridad.

Una capa de seguridad compartida ofrece a desarrolladores y usuarios una base más clara para evaluar quién protege el sistema y qué ocurre si los validadores actúan de forma indebida.

Cómo funciona una capa de seguridad compartida

Una capa de seguridad compartida funciona conectando varios sistemas a una misma fuente de seguridad.

Esta fuente puede ser una cadena proveedora, una relay chain, un protocolo de restaking, un mercado de validadores, un sistema de staking agrupado o una red de seguridad criptoeconómica.

El sistema conectado suele recibir de la capa compartida servicios de validación, atestación, producción de bloques, disponibilidad de datos, finalidad, verificación de mensajes u otros servicios de seguridad.

Los validadores u operadores pueden ejecutar software adicional para cada cadena o servicio conectado.

Los participantes en staking pueden delegar activos a validadores u operadores que aceptan proteger sistemas adicionales.

El sistema conectado puede pagar recompensas, comisiones, inflación u otros incentivos a los validadores y participantes en staking que lo protegen.

Si los validadores u operadores no cumplen sus obligaciones, el modelo de seguridad compartida puede aplicar penalizaciones, slashing, expulsiones, pérdida de recompensas o medidas de gobernanza, según el protocolo.

El diseño exacto depende del ecosistema.

Algunos sistemas replican el conjunto de validadores de la cadena proveedora en las consumer chains.

Otros permiten que solo una parte de los validadores acepte proteger un servicio concreto.

Por tanto, la capa de seguridad compartida no es una única tecnología, sino una familia de diseños que agrupan confianza y seguridad económica.

Cadena proveedora

Una cadena proveedora es una blockchain que proporciona seguridad a otras cadenas o servicios.

En los modelos de seguridad compartida al estilo de Cosmos, la cadena proveedora puede compartir su conjunto de validadores y su stake con las consumer chains.

La documentación de Interchain Security de Cosmos Hub afirma que Hub puede permitir que las cadenas aprovechen sus validadores, stake y comunidad.

La cadena proveedora suele contar con un token establecido, un conjunto de validadores, un sistema de gobernanza, una economía de staking y una reputación.

Las consumer chains se benefician porque no tienen que crear por sí solas una economía de seguridad completa.

La cadena proveedora puede beneficiarse porque las consumer chains pueden generar nueva demanda, comisiones, recompensas y valor para el ecosistema.

Esta relación debe diseñarse con cuidado, ya que los validadores de la cadena proveedora asumen obligaciones adicionales.

Si las consumer chains exigen demasiado, los validadores pueden sufrir una mayor carga operativa o un menor rendimiento.

Si las recompensas son demasiado bajas, quizá los validadores no quieran participar.

Una cadena proveedora solo resulta útil si puede compartir su seguridad sin debilitar el sistema base.

Consumer chain

Una consumer chain es una blockchain que recibe seguridad de una cadena proveedora o de una capa de seguridad compartida.

Una consumer chain puede seguir teniendo su propia lógica de aplicación, configuración de gobernanza, comisiones, modelo de tokens y experiencia de usuario.

Lo que toma prestado es parte de la estructura de seguridad que valida o protege su estado.

Esto puede ayudar a una nueva cadena a lanzarse más rápido y con una seguridad mayor de la que podría desarrollar por sí sola.

Sin embargo, una consumer chain no está libre de riesgos por el mero hecho de utilizar seguridad compartida.

Puede seguir estando expuesta a errores en contratos inteligentes, fallos en la lógica de la aplicación, riesgos de oráculos y bridges, riesgos de gobernanza, baja liquidez y problemas en la interfaz de usuario.

Los usuarios también deben comprobar en qué medida se aplica realmente a la consumer chain la seguridad de la cadena proveedora.

Algunos diseños exigen que todo el conjunto de validadores valide la consumer chain.

Otros diseños permiten utilizar solo una parte del conjunto o un grupo que participe voluntariamente.

La solidez de una consumer chain depende de los detalles del acuerdo de seguridad compartida.

Conjunto de validadores

Un conjunto de validadores es el grupo de validadores responsable de producir, comprobar, finalizar o atestiguar la actividad de una blockchain.

En una capa de seguridad compartida, el conjunto de validadores puede proteger más de una cadena o servicio.

Esto puede mejorar la seguridad, ya que una nueva cadena puede depender de validadores que ya tienen un compromiso económico y experiencia operativa.

También puede aumentar la complejidad operativa, porque quizá los validadores tengan que ejecutar muchos tipos de software diferentes.

Si los validadores están sobrecargados, la calidad de la validación puede disminuir.

Si demasiados sistemas dependen del mismo conjunto de validadores, los fallos pueden estar correlacionados.

La diversidad de validadores es importante: la seguridad es menor cuando muchos validadores están controlados por el mismo operador, alojados en la misma infraestructura o expuestos al mismo error de software.

La documentación de la relay chain de Polkadot señala que la seguridad depende no solo del stake, sino también del número de validadores y de factores de centralización social o física.

Un conjunto compartido de validadores puede ser muy eficaz, pero debe mantenerse descentralizado, supervisado y correctamente incentivado.

Los usuarios deben preguntarse quién valida realmente los sistemas conectados.

Seguridad agrupada

La seguridad agrupada consiste en que varios participantes combinan su stake, el trabajo de sus validadores o sus garantías económicas para proteger un sistema.

En los diseños de seguridad compartida, la seguridad agrupada puede dificultar los ataques a un nuevo servicio, ya que un atacante debe superar una base de seguridad mayor.

La documentación oficial de términos clave de EigenLayer describe la seguridad agrupada mediante restaking como un modelo en el que varias partes combinan recursos para proporcionar mayor seguridad a un sistema.

La seguridad agrupada puede ser eficiente porque el mismo capital de seguridad puede respaldar más de un servicio útil.

También puede entrañar riesgos si el mismo capital queda expuesto a demasiadas condiciones de slashing o a demasiados fallos correlacionados.

Por eso, la seguridad agrupada debe evaluarse teniendo en cuenta tanto sus ventajas como las cargas que implica.

La ventaja es una protección compartida más sólida.

La carga consiste en que validadores y participantes en staking pueden asumir más responsabilidades y más formas de perder fondos.

La seguridad agrupada resulta atractiva, pero no es seguridad gratuita.

Cada servicio adicional modifica el perfil de riesgo y recompensa del fondo compartido.

Restaking y seguridad compartida

El restaking es uno de los modelos modernos de seguridad compartida más importantes.

El restaking permite utilizar activos en staking o tokens de staking líquido para proteger servicios adicionales más allá de la cadena base original.

La descripción general de EigenLayer indica que el restaking permite volver a poner en staking ETH nativo o tokens de staking líquido para proporcionar seguridad a Autonomous Verifiable Services.

Estos servicios pueden incluir disponibilidad de datos, verificación, tareas similares a las de un oráculo, bridges, coprocesadores y otras infraestructuras que necesitan garantías criptoeconómicas.

Los operadores ejecutan el software necesario para dar soporte a estos servicios.

Los participantes en staking pueden delegar en operadores o ejecutar ellos mismos la infraestructura de operador.

La propuesta es mejorar la eficiencia del capital, ya que un mismo fondo de activos en staking puede respaldar más de un servicio cripto.

El riesgo es que los servicios adicionales pueden añadir exposición a slashing, riesgos operativos, de contratos inteligentes y de gobernanza.

El restaking convierte el capital en staking en un recurso de seguridad compartida.

Los usuarios deben entender exactamente qué servicios contribuyen a proteger sus activos en restaking.

Autonomous Verifiable Services

Autonomous Verifiable Services, conocidos habitualmente como AVS en el ecosistema EigenLayer, son servicios que utilizan seguridad restaked a través de EigenLayer.

La descripción general de EigenLayer define los AVS como servicios creados sobre el protocolo que aprovechan la seguridad compartida de Ethereum.

Un AVS puede definir tareas que deben llevar a cabo los operadores.

Estas tareas pueden consistir en validación, disponibilidad de datos, computación, atestación, mensajería u otro trabajo verificable.

Los operadores aceptan prestar servicios a los AVS.

Los participantes en staking delegan activos a los operadores y aceptan el perfil de riesgo asociado a los servicios que estos eligen.

Un AVS debe definir claramente sus requisitos, recompensas, condiciones de slashing, reglas de supervisión y lógica de verificación.

Si el diseño del AVS es débil, la seguridad compartida quizá no proteja a los usuarios como se espera.

Los usuarios no deben suponer que todos los AVS ofrecen el mismo nivel de seguridad por el mero hecho de utilizar un protocolo de seguridad compartida.

La calidad del diseño del servicio sigue siendo importante.

Interchain Security

Interchain Security es un enfoque del ecosistema Cosmos para la seguridad compartida.

Permite que una consumer chain utilice la seguridad de una cadena proveedora, en lugar de empezar con un conjunto de validadores aislado.

La documentación de Cosmos Interchain Security la describe como una plataforma para lanzar cadenas basadas en Cosmos-SDK.

La documentación oficial de Partial Set Security explica que las consumer chains pueden utilizar solo una parte de los validadores de la cadena proveedora, lo que ofrece más flexibilidad que el modelo replicado anterior.

Esto significa que la seguridad compartida puede adaptarse a las necesidades de una consumer chain.

Una cadena que necesite más seguridad puede exigir una mayor proporción de validadores.

Una cadena más pequeña o experimental puede elegir un modelo de participación voluntaria con un nivel de seguridad garantizado menor.

La contrapartida es clara: más seguridad suele exigir un mayor compromiso de los validadores y recompensas más elevadas.

Interchain Security muestra cómo la seguridad compartida puede convertirse en una relación de gobernanza y económica entre cadenas.

También demuestra que los usuarios deben comprobar cuánta seguridad de la cadena proveedora recibe realmente una consumer chain.

Seguridad compartida de Polkadot

Polkadot es uno de los ejemplos más consolidados de una capa de seguridad compartida.

Polkadot utiliza una arquitectura de relay chain y parachains en la que las cadenas conectadas pueden beneficiarse de la seguridad y la interoperabilidad de la relay chain.

La documentación de la relay chain de Polkadot indica que las cadenas Layer 1 conectadas se benefician de la seguridad de Nominated Proof of Stake sin tener que poner en marcha su propio conjunto de validadores.

La documentación de las parachains de Polkadot señala que estas heredan la seguridad del conjunto de validadores de Polkadot y pueden comunicarse mediante Cross-Consensus Messaging.

Este modelo permite a las cadenas específicas para aplicaciones centrarse en su propia lógica, mientras la relay chain coordina la seguridad.

También crea un entorno de interoperabilidad compartido, ya que las parachains pueden comunicarse bajo supuestos comunes.

El modelo de Polkadot no es igual que el restaking o Cosmos Interchain Security.

Se trata de una arquitectura de capa 0 cuyo diseño se centra en la seguridad compartida y la mensajería entre cadenas.

Antes de evaluar aplicaciones de este ecosistema, los usuarios deben entender la relay chain, los validadores, el coretime, las parachains, la gobernanza y el modelo de mensajería.

La seguridad compartida es más sólida cuando los usuarios entienden tanto la base de seguridad común como la lógica específica de cada cadena de aplicaciones.

Capa de seguridad compartida frente a blockchain independiente

Una blockchain independiente es responsable de su propia seguridad.

Debe atraer validadores, participantes en staking, mineros, delegadores, operadores de nodos, participantes en la gobernanza y una infraestructura de supervisión.

Una cadena con seguridad compartida puede depender de una capa de seguridad existente para algunas de estas responsabilidades.

Esto puede facilitar su lanzamiento y crecimiento.

Sin embargo, una cadena independiente puede tener más autonomía y menos dependencias externas.

Una cadena con seguridad compartida puede depender de la gobernanza de la cadena proveedora, de la participación de los validadores, de reglas de slashing compartidas o de las actualizaciones de la capa de seguridad.

La contrapartida está entre la autonomía y la puesta en marcha de la seguridad.

Una cadena independiente controla su propio destino, pero debe protegerse por sí misma.

Una cadena con seguridad compartida recibe apoyo, pero acepta las reglas y los supuestos de otra capa.

Ningún modelo es automáticamente mejor: el modelo adecuado depende de los objetivos de la aplicación, la tolerancia al riesgo y las expectativas de los usuarios.

Capa de seguridad compartida frente a sidechain

Una sidechain es una blockchain independiente conectada a otra cadena mediante un bridge o un mecanismo de anclaje.

Una sidechain suele tener su propio conjunto de validadores y sus propios supuestos de seguridad.

Una cadena con seguridad compartida depende de forma más directa de una capa de seguridad común o de un conjunto de validadores proveedor.

Esta diferencia es importante porque los usuarios suelen confundir las cadenas conectadas con las cadenas que comparten seguridad.

Una cadena puede estar conectada mediante un bridge sin compartir la seguridad de los validadores.

Una cadena puede utilizar la misma máquina virtual que otra sin compartir su seguridad.

Una cadena puede tener comisiones bajas y wallets conocidas y, aun así, estar protegida por un conjunto de validadores independiente y más pequeño.

La seguridad compartida se refiere a quién valida y protege el sistema, no solo a cómo se mueven los activos entre sistemas.

Los usuarios deben preguntarse si la cadena hereda seguridad, la alquila, utiliza seguridad restaked o simplemente conecta activos mediante un bridge.

La respuesta modifica el modelo de riesgo.

Capa de seguridad compartida frente a rollup

Un rollup es un sistema de escalabilidad que ejecuta transacciones fuera de una cadena base y depende de esta para la liquidación, las pruebas o la publicación de datos, según el tipo de rollup.

Una capa de seguridad compartida tiene un alcance más amplio, ya que puede proteger muchos tipos de servicios, cadenas y módulos, no solo la ejecución de rollups.

Parte de la infraestructura relacionada con los rollups puede utilizar seguridad compartida para la disponibilidad de datos, la secuenciación, la verificación o la mensajería entre rollups.

Otros rollups dependen principalmente de su cadena de liquidación y de su sistema de pruebas.

La diferencia es importante porque la seguridad de un rollup depende de la disponibilidad de datos, la validez de las pruebas o los mecanismos de impugnación de fraude, las claves de actualización, los secuenciadores y los supuestos de liquidación.

La seguridad compartida puede añadir otra capa de operadores, participantes en staking, recompensas y condiciones de slashing.

Un rollup puede utilizar seguridad compartida para un componente concreto sin que todo su modelo de seguridad sea idéntico al de la capa compartida.

Los usuarios deben comprobar qué parte de la pila protege la seguridad compartida.

Los desarrolladores deben evitar afirmaciones imprecisas según las cuales un rollup está protegido por completo por una capa compartida si solo utiliza uno de sus módulos.

Las afirmaciones precisas sobre seguridad son esenciales en los sistemas cripto modulares.

Capa de seguridad compartida frente a bridge

Un bridge mueve activos o mensajes entre cadenas.

Una capa de seguridad compartida protege cadenas o servicios mediante validadores, stake o garantías restaked comunes.

Algunos bridges pueden utilizar seguridad compartida para la verificación, pero un bridge no es automáticamente una capa de seguridad compartida.

Los riesgos de un bridge incluyen errores en contratos inteligentes, la vulneración de firmantes, la repetición de mensajes, fallos de liquidez y el control de la gobernanza.

Los riesgos de la seguridad compartida incluyen fallos de validadores, el diseño del slashing, la concentración de operadores, los riesgos de gobernanza y la exposición a varios servicios.

Un bridge puede conectar dos cadenas que no compartan seguridad alguna.

Una capa de seguridad compartida puede facilitar la interoperabilidad, pero su función principal no es simplemente mover activos.

Al evaluar aplicaciones entre cadenas, los usuarios deben distinguir el riesgo de los bridges del riesgo de la seguridad compartida.

Una capa de seguridad compartida sólida puede estar emparejada con un bridge débil.

Una experiencia de usuario segura requiere tanto una validación segura como un movimiento seguro de activos.

Seguridad económica

La seguridad económica es el valor expuesto al riesgo que hace que los ataques resulten costosos.

En los sistemas proof-of-stake, la seguridad económica suele proceder de activos en staking que los validadores pueden perder si incumplen las reglas.

En una capa de seguridad compartida, la seguridad económica puede reutilizarse o agruparse entre varios servicios.

Esto puede hacer que los servicios pequeños sean más seguros, ya que no necesitan crear por sí solos un gran presupuesto de seguridad.

El riesgo es que se exagere la seguridad económica si el mismo stake se promete a demasiados servicios con riesgos coincidentes.

Los usuarios deben preguntarse cuánto stake puede someterse realmente a slashing en una cadena o servicio concreto.

También deben comprobar si el slashing está activo, es aplicable, se retrasa, depende de la gobernanza o solo está implementado parcialmente.

La seguridad económica no es solo una cifra llamativa.

Depende de las condiciones de slashing, la liquidez, el comportamiento de los validadores, la estructura legal, los contratos inteligentes y el valor de mercado.

Una seguridad compartida sólida requiere penalizaciones creíbles y una supervisión eficaz.

Slashing en la seguridad compartida

El slashing es una penalización que retira o quema stake cuando los validadores u operadores incumplen las reglas.

En los sistemas de seguridad compartida, el slashing puede proteger las cadenas y los servicios conectados al encarecer las conductas indebidas.

La documentación de términos clave de EigenLayer define el slashing como una penalización por completar de forma incorrecta o inexacta las tareas asignadas a los conjuntos de operadores.

La descripción general del restaking de EigenLayer explica que el stake delegado puede quedar sujeto a slashing cuando un operador asigna stake a conjuntos de operadores.

Esto significa que los participantes en staking deben supervisar qué servicios protegen los operadores que han elegido.

El slashing puede mejorar la rendición de cuentas, pero también genera nuevos riesgos para quienes participan en staking.

Si un operador falla en un servicio, los activos delegados pueden verse afectados aunque el participante en staking no haya ejecutado personalmente el software.

Las reglas de slashing deben ser claras, objetivas siempre que sea posible y aplicables.

La falta de claridad en estas reglas puede generar incertidumbre, disputas y confusión entre los usuarios.

La credibilidad de una capa de seguridad compartida depende de su capacidad para detectar y penalizar de forma justa los fallos graves.

Recompensas en la seguridad compartida

Las recompensas compensan a validadores, operadores y participantes en staking por proteger sistemas adicionales.

Pueden proceder de las comisiones de las consumer chains, la inflación, los pagos por servicios, los incentivos del protocolo o los ingresos de las aplicaciones.

Un modelo de seguridad compartida debe equilibrar las recompensas y el riesgo.

Si las recompensas son demasiado bajas, quizá los validadores no quieran proteger el sistema conectado.

Si son demasiado elevadas e insostenibles, el modelo puede atraer capital a corto plazo sin ofrecer una seguridad duradera.

Los sistemas de restaking pueden pagar a operadores y participantes en staking por dar soporte a AVS.

Los sistemas con cadena proveedora pueden distribuir las recompensas de las consumer chains entre validadores y delegadores.

Los sistemas al estilo de Polkadot pueden vincular el acceso a la seguridad con el coretime y la asignación de recursos de la red.

Los usuarios no deben evaluar la seguridad compartida basándose únicamente en el rendimiento.

Deben comparar las recompensas con los riesgos de slashing, de contratos inteligentes, de liquidez, de operadores y de gobernanza.

Seguridad compartida e interoperabilidad

La seguridad compartida puede mejorar la interoperabilidad, ya que los sistemas conectados pueden funcionar bajo supuestos de confianza comunes.

Si varias cadenas dependen de la misma capa de seguridad, puede resultar más fácil entender los mensajes entre ellas que los enviados entre cadenas no relacionadas.

La documentación de la relay chain de Polkadot describe la interoperabilidad segura mediante comunicación nativa entre cadenas.

La seguridad compartida puede hacer más prácticas las aplicaciones entre cadenas, ya que usuarios y desarrolladores pueden depender de una base de seguridad común.

Sin embargo, la seguridad compartida no resuelve automáticamente todos los problemas de interoperabilidad.

Siguen siendo importantes los formatos de los mensajes, los contratos de los bridges, los relayers, la latencia, la liquidez, la finalidad y la lógica de las aplicaciones.

Una capa de seguridad compartida puede reducir la fragmentación de la confianza, pero no elimina la necesidad de diseñar de forma segura las operaciones entre cadenas.

Los desarrolladores deben explicar qué se comparte, qué se verifica y qué sigue dependiendo de una infraestructura independiente.

Los usuarios no deben suponer que todos los mensajes entre cadenas con seguridad compartida están libres de riesgos.

La interoperabilidad es más segura cuando los supuestos de seguridad son explícitos.

Seguridad compartida y blockchains modulares

Las blockchains modulares dividen las funciones de la blockchain en capas independientes, como la ejecución, la liquidación, el consenso y la disponibilidad de datos.

Una capa de seguridad compartida puede proporcionar seguridad a una o varias de estas funciones.

Por ejemplo, un servicio puede utilizar seguridad compartida para la disponibilidad de datos, otra cadena para la liquidación y otro entorno para la ejecución.

Este diseño modular puede mejorar la especialización y el rendimiento.

También puede dificultar la comprensión de los riesgos, porque los usuarios deben evaluar varias capas a la vez.

Un fallo en un módulo puede afectar a toda la aplicación.

Un fallo en la disponibilidad de datos puede afectar a la recuperación de un rollup.

Un fallo de secuenciación puede afectar al orden de las transacciones y a la experiencia de usuario.

Un fallo de un bridge puede afectar al canje de activos.

Una capa de seguridad compartida ayuda a los sistemas modulares a coordinar la confianza, pero los usuarios siguen teniendo que entender toda la pila.

Seguridad compartida y MEV

El MEV, o valor máximo extraíble, puede aparecer cuando validadores, secuenciadores u operadores influyen en el orden, la inclusión o la ejecución de las transacciones.

Una capa de seguridad compartida puede reducir algunos riesgos mediante reglas comunes y operadores que rindan cuentas.

También puede concentrar el poder de ordenar transacciones si muchas aplicaciones dependen de los mismos operadores.

Si los operadores protegen varios servicios, pueden tener acceso a más flujos de transacciones y oportunidades entre dominios.

Esto puede generar tanto eficiencia como riesgo.

En los diseños de seguridad compartida son importantes las políticas de MEV, la supervisión, las reglas para los proponentes, los sistemas de ordenación justa y la transparencia.

Los usuarios deben entender si la capa de seguridad compartida protege contra la censura o si solo aplica penalizaciones económicas después de una conducta indebida.

Los desarrolladores no deben suponer que la seguridad compartida garantiza automáticamente un orden justo.

La seguridad compartida puede favorecer una mejor coordinación, pero la gestión del MEV requiere un diseño específico.

El orden de las transacciones sigue siendo uno de los problemas más difíciles de la infraestructura multicadena.

Resistencia a la censura

La resistencia a la censura es la capacidad de incluir transacciones válidas de los usuarios sin bloquearlas injustamente.

Una capa de seguridad compartida puede mejorar la resistencia a la censura si cuenta con un conjunto amplio y diverso de validadores.

Puede debilitarla si la validación está controlada por un número reducido de operadores o si las consumer chains dependen de una parte limitada del conjunto.

Los modelos de seguridad compartida parcial pueden ser flexibles, pero requieren revisar con cuidado la participación de los validadores.

La documentación de Cosmos Partial Set Security explica que las cadenas que participan voluntariamente quizá no reciban una cantidad fija de seguridad y deban supervisar la participación de los validadores.

Esto importa porque un grupo pequeño de operadores puede ser más fácil de presionar, sobornar o coordinar.

Los usuarios deben comprobar si existen vías de salida, mecanismos de respaldo o procesos de gobernanza en caso de censura.

Los desarrolladores deben diseñar aplicaciones que permitan a los usuarios entender la finalidad y los riesgos de inclusión de las transacciones.

La expresión «seguridad compartida» no garantiza la resistencia a la censura.

Esta depende de la diversidad de validadores, los incentivos, las reglas y la infraestructura del mundo real.

Vitalidad

La vitalidad es la capacidad del sistema para seguir avanzando y procesando transacciones válidas.

Una capa de seguridad compartida debe proteger tanto la seguridad como la vitalidad.

La seguridad implica que el sistema no finaliza estados inválidos o contradictorios.

La vitalidad implica que el sistema no se detiene indefinidamente.

La seguridad compartida puede mejorar la vitalidad cuando muchos validadores fiables respaldan los servicios conectados.

También puede ponerla en riesgo si los validadores deben ejecutar demasiadas cadenas, si fallan las actualizaciones de software o si los incentivos de los operadores son débiles.

Una consumer chain puede detenerse si no participan correctamente suficientes validadores compartidos.

Un AVS puede dejar de prestar el servicio si los operadores están desconectados o mal configurados.

Los usuarios deben comprobar el tiempo de actividad histórico, los informes de incidentes, la participación de los validadores y los procedimientos de emergencia.

Una capa de seguridad compartida segura debe poder seguir funcionando bajo presión.

Gobernanza en la seguridad compartida

La gobernanza determina cómo evoluciona una capa de seguridad compartida.

Puede aprobar consumer chains, cambiar los requisitos para los validadores, actualizar las reglas de slashing, modificar las recompensas, actualizar contratos o responder a emergencias.

En algunos sistemas de seguridad compartida, la gobernanza de la cadena proveedora puede decidir qué consumer chains pueden incorporarse.

En los sistemas de restaking, la gobernanza del protocolo o los proveedores de servicios pueden definir los conjuntos de operadores y las condiciones de slashing.

La gobernanza puede mejorar la capacidad de adaptación, pero también generar riesgos de centralización.

Si un grupo reducido puede cambiar rápidamente las reglas, los usuarios pueden encontrarse con cambios de seguridad inesperados.

Si la gobernanza es demasiado lenta, el ecosistema puede no responder a amenazas urgentes.

Los usuarios deben comprobar los bloqueos temporales, la distribución del poder de voto, los permisos de actualización, los controles de emergencia y la transparencia.

La seguridad compartida no es solo un sistema técnico.

También es un sistema de gobernanza y coordinación.

Concentración de operadores

La concentración de operadores se produce cuando un número reducido de operadores controla una gran proporción de la validación o de la seguridad restaked.

Esto puede reducir la descentralización y aumentar el riesgo de fallos correlacionados.

Si muchos usuarios delegan en el mismo operador, un error de este puede afectar a numerosos participantes en staking.

Si muchos servicios dependen del mismo grupo de operadores, un único fallo de infraestructura puede afectar a varios sistemas a la vez.

La concentración de operadores también puede concentrar influencia en la gobernanza y el MEV.

Antes de delegar activos restaked o depender de un servicio, los usuarios deben comprobar la diversidad de operadores.

Los desarrolladores deben diseñar incentivos que fomenten una base amplia de operadores.

Los grandes operadores pueden ser profesionales y fiables, pero el tamaño no debe considerarse por sí solo una garantía de seguridad.

Una capa de seguridad compartida saludable debe reducir los puntos únicos de fallo.

La seguridad descentralizada depende tanto del stake económico como de la distribución operativa.

Riesgos de la seguridad compartida

El primer riesgo es el slashing correlacionado en varios servicios.

El segundo es la sobrecarga de los operadores por asumir demasiadas tareas de validación.

El tercero es la captura de la gobernanza o las actualizaciones inseguras.

El cuarto es un diseño de slashing débil que no penaliza los fallos reales.

El quinto es un slashing demasiado agresivo que castiga injustamente los errores honestos.

El sexto es la vulnerabilidad de contratos inteligentes en contratos de restaking, delegación, recompensas o bridges.

El séptimo es un fallo de vitalidad si los validadores u operadores dejan de participar.

El octavo es que los usuarios no entiendan con claridad qué capa protege cada componente.

El noveno es exagerar la seguridad económica cuando el stake anunciado no puede someterse por completo a slashing para un servicio concreto.

El décimo es la dependencia compartida, por la que un fallo en una capa de seguridad afecta a muchos sistemas conectados a la vez.

Ventajas de las capas de seguridad compartida

La primera ventaja es que las nuevas cadenas y servicios pueden poner en marcha su seguridad más rápido.

La segunda es una seguridad económica más sólida que la que muchos conjuntos pequeños e independientes de validadores pueden alcanzar por sí solos.

La tercera es un menor coste de lanzamiento para los desarrolladores.

La cuarta es una mayor interoperabilidad entre los sistemas conectados.

La quinta es una mayor eficiencia del capital, ya que los activos en staking pueden respaldar más de un servicio útil.

La sexta es una mayor profesionalización de los validadores, ya que operadores consolidados pueden dar soporte a varias redes.

La séptima es que facilita el desarrollo de cadenas específicas para aplicaciones.

La octava es una mayor alineación del ecosistema entre cadenas proveedoras, consumer chains, operadores y usuarios.

La novena es una arquitectura de blockchain modular más flexible.

La décima es que la seguridad compartida puede dar mayor credibilidad a infraestructuras de gran valor antes de que cuenten con una economía de tokens nativa de gran tamaño.

Cómo evaluar una capa de seguridad compartida

Empieza por identificar la fuente de seguridad.

Comprueba si procede de una cadena proveedora, una relay chain, un protocolo de restaking, un mercado de validadores u otro diseño.

Comprueba cuánto stake protege realmente la cadena o el servicio concreto.

Comprueba si el conjunto de validadores es completo, parcial, voluntario, autorizado o abierto a todos.

Comprueba si el slashing está activo, es objetivo y aplicable, se retrasa o depende de la gobernanza.

Comprueba si los validadores u operadores son diversos y fiables.

Comprueba qué recompensas se pagan y si son sostenibles.

Comprueba si el sistema conectado presenta riesgos propios de contratos inteligentes, bridges, oráculos o gobernanza.

Comprueba si los usuarios pueden salir de forma segura si el servicio falla o cambia la relación de seguridad.

Una buena evaluación se pregunta qué se comparte, quién lo hace cumplir, qué puede fallar y quién asume el coste cuando falla.

Buenas prácticas para desarrolladores

Explica claramente el modelo de seguridad en la documentación para usuarios.

Indica si tu cadena o servicio utiliza seguridad compartida completa o parcial, operadores voluntarios o seguridad restaked.

Publica información sobre validadores, operadores, recompensas, slashing y gobernanza en un formato comprensible para los usuarios.

No afirmes que tu aplicación hereda toda la seguridad de una cadena base si solo utiliza seguridad compartida en uno de sus componentes.

Utiliza contratos auditados para el staking, la delegación, las recompensas, los bridges y la lógica de slashing.

Supervisa continuamente a los operadores y validadores.

Diseña recompensas que compensen a los operadores por el trabajo y los riesgos reales.

Prepara procedimientos de respuesta a incidentes para fallos de vitalidad, disputas de slashing, pausas de bridges y emergencias de gobernanza.

Facilita a los usuarios información sobre los activos o servicios expuestos a cada riesgo.

La seguridad compartida debe presentarse como una arquitectura precisa, no como un eslogan de marketing.

Buenas prácticas para usuarios

Lee la documentación oficial antes de utilizar una cadena o servicio que afirme ofrecer seguridad compartida.

Comprueba si la capa de seguridad protege todo el sistema o solo uno de sus módulos.

Antes de depositar fondos, comprueba la participación de los validadores u operadores.

Entiende el riesgo de slashing antes de poner activos en staking, delegarlos o hacer restaking.

No persigas recompensas más altas sin comprobar qué riesgos adicionales las generan.

Evalúa por separado los riesgos de bridges, oráculos, contratos inteligentes y gobernanza, sin confundirlos con las afirmaciones de seguridad compartida.

Haz pequeñas transacciones de prueba cuando pruebes una nueva cadena o servicio.

Controla a qué operadores o validadores están expuestos tus activos.

Sigue los anuncios, ya que las relaciones de seguridad compartida pueden cambiar mediante la gobernanza o las actualizaciones.

Considera la seguridad compartida como un modelo de riesgo que debes entender, no como una garantía de seguridad.

Errores frecuentes sobre las capas de seguridad compartida

Un error habitual es suponer que la seguridad compartida significa que no hay riesgo.

Otro es creer que todas las cadenas conectadas reciben el mismo nivel de seguridad.

Un tercer error es confundir un bridge con una capa de seguridad compartida.

Un cuarto es considerar que el valor total en staking anunciado está disponible por completo para proteger todos los servicios.

Un quinto es ignorar la concentración de validadores u operadores.

Un sexto es ignorar las condiciones de slashing.

Un séptimo es suponer que la seguridad compartida protege frente a todos los errores de contratos inteligentes.

Un octavo es ignorar la gobernanza y los permisos de actualización.

Un noveno es creer que las recompensas del restaking son rendimientos gratuitos.

Un décimo es no comprobar si la capa de seguridad compartida está activa, es parcial o experimental, o sigue cambiando.

Preguntas frecuentes

¿Qué significa «capa de seguridad compartida» en el ámbito cripto?

Una capa de seguridad compartida es un sistema de seguridad blockchain en el que varias cadenas, servicios o módulos dependen de un conjunto común de validadores, de stake agrupado o de garantías restaked.

¿Por qué utilizan los proyectos una capa de seguridad compartida?

Los proyectos utilizan una capa de seguridad compartida para no tener que poner en marcha su seguridad desde cero y acceder a validadores, stake, interoperabilidad e infraestructura más sólidos.

¿Es la seguridad compartida lo mismo que un bridge?

No. Un bridge mueve activos o mensajes, mientras que la seguridad compartida proporciona validación, staking o protección criptoeconómica a cadenas o servicios.

¿Es la seguridad compartida lo mismo que una sidechain?

No. Una sidechain suele tener su propio conjunto de validadores, mientras que una cadena con seguridad compartida depende de una fuente de seguridad común o de una capa proveedora.

¿Qué es el restaking en la seguridad compartida?

El restaking permite que activos en staking o tokens de staking líquido protejan servicios adicionales más allá de la cadena base original.

¿Puede la seguridad compartida reducir los riesgos?

Sí. La seguridad compartida puede reducir los riesgos asociados a poner en marcha la seguridad de nuevos sistemas, pero también introduce riesgos de operadores, slashing, gobernanza, contratos y fallos correlacionados.

¿Qué es una cadena proveedora?

Una cadena proveedora es una blockchain que proporciona seguridad a consumer chains o servicios conectados.

¿Qué es una consumer chain?

Una consumer chain es una blockchain que recibe seguridad de una cadena proveedora o de una capa de seguridad compartida.

¿Cuál es el mayor riesgo de la seguridad compartida?

Un riesgo importante es que un fallo en el sistema compartido de validadores, operadores, gobernanza o slashing afecte a muchos servicios conectados al mismo tiempo.

¿Cómo deben evaluar los usuarios las afirmaciones sobre seguridad compartida?

Los usuarios deben comprobar la fuente de seguridad, la participación de los validadores, la concentración de operadores, las reglas de slashing, las recompensas, los poderes de gobernanza y qué partes del sistema están realmente protegidas.

Conclusión

Una capa de seguridad compartida es una arquitectura de seguridad cripto en la que varias cadenas, aplicaciones o servicios dependen de un fondo común de validadores, participantes en staking, operadores o garantías restaked.

Ayuda a los nuevos sistemas a lanzarse con una seguridad mayor de la que quizá podrían alcanzar por sí solos.

Se utiliza de varias formas, como la seguridad de relay chains, Interchain Security, el restaking, los conjuntos agrupados de validadores y los servicios de infraestructura modular.

La seguridad compartida puede mejorar la escalabilidad, la interoperabilidad, la eficiencia del capital, la velocidad de desarrollo y la alineación del ecosistema.

También puede generar nuevos riesgos por la exposición al slashing, la concentración de operadores, la dependencia de la gobernanza, los errores de contratos inteligentes, los riesgos de bridges, los fallos de vitalidad y los fallos correlacionados entre sistemas conectados.

Los desarrolladores deben explicar exactamente qué se protege, quién lo protege, cómo funcionan las recompensas y qué ocurre si fallan los validadores u operadores.

Los usuarios deben evaluar cuidadosamente las afirmaciones sobre seguridad compartida en lugar de suponer que un sistema conectado hereda automáticamente toda la seguridad de una cadena más grande.

Para los principiantes, una capa de seguridad compartida se entiende mejor como una base de seguridad que muchos sistemas cripto pueden utilizar conjuntamente.

Para los usuarios avanzados, es una capa de coordinación criptoeconómica que conecta el stake, los validadores, los operadores, las reglas de los servicios, las condiciones de slashing, las recompensas, la gobernanza y la interoperabilidad entre varios sistemas.

En el contexto de un glosario cripto, «capa de seguridad compartida» significa un marco de seguridad agrupada que permite a varias redes o servicios blockchain depender de validadores o garantías compartidos, asumiendo los riesgos específicos de ese modelo.

La idea clave es que la seguridad compartida puede hacer que la infraestructura cripto sea más sólida y eficiente, pero solo si usuarios y desarrolladores entienden exactamente el conjunto de validadores, las reglas de slashing, los poderes de gobernanza, los incentivos de recompensa y las vías de fallo que sustentan esa afirmación de seguridad.