Aprovechar la seguridad compartida para lograr una interoperabilidad segura entre cadenas

Dado que los ataques a los puentes de blockchain provocan pérdidas de miles de millones de dólares, no sorprende que las discusiones sobre la seguridad entre cadenas generen a menudo intensos debates. Pero creemos que es necesario adoptar un enfoque más pragmático, que implique analizar el problema de la interoperabilidad segura desde los principios básicos y diseñar mecanismos para aumentar las garantías de seguridad para las aplicaciones entre cadenas y sus usuarios.

En este artículo, exploraremos el concepto de seguridad compartida y explicaremos cómo los diseños de seguridad compartida (como los Comités Estatales de Lagrange) pueden reducir el costo de implementar propiedades de seguridad significativas para los protocolos de interoperabilidad. Si bien nos centramos en la seguridad compartida para los protocolos de comunicación entre cadenas, cualquier aplicación descentralizada, independientemente del caso de uso, puede aprovechar esta tecnología emergente para lograr una descentralización suficiente y minimizar la confianza sin incurrir en una sobrecarga operativa excesiva.

Una introducción informal a la seguridad compartida

La “seguridad compartida” se refiere a la seguridad que un protocolo obtiene de una fuente externa. En un esquema de seguridad compartida, los recursos que reúnen los participantes de un protocolo (por ejemplo, capital o capacidad computacional) se utilizan para crear seguridad económica para otro protocolo. La seguridad compartida difiere del modelo estándar, en el que cada red es responsable de su seguridad.

Las cadenas de bloques públicas como Bitcoin y Ethereum, por ejemplo, combinan algoritmos de consenso con mecanismos de resistencia a Sybil (como Prueba de trabajo o Prueba de participación) para garantizar la vitalidad y, al mismo tiempo, aumentar el costo de los ataques adversarios (por ejemplo, ataques Sybil , ataques de largo alcance , ataques de eclipse , ataques de bandidos del tiempo y ataques de soborno ).

Aunque los esquemas de seguridad compartida funcionan de manera diferente, los objetivos generalmente giran en torno a dos objetivos:

• Aumentar la eficiencia del capital en las redes blockchain sin crear riesgos adicionales (acumulación de riesgos) ni introducir supuestos de seguridad adicionales.
• Mejorar la capacidad de las redes blockchain (especialmente los protocolos nacientes) para defenderse contra transiciones de estados no válidas, reorganizaciones, resistencia a la censura y otros ataques a la vitalidad y seguridad de un protocolo.

La seguridad compartida no es exactamente un concepto nuevo; por ejemplo, la minería combinada se introdujo en 2011, lo que permitió a los mineros usar la misma prueba de trabajo criptográfica (PoW) para crear bloques en dos (o más) cadenas PoW diferentes que implementaban el consenso de Nakamoto . Esto permitió que los protocolos basados en PoW más nuevos (como Namecoin y Rootstock), cuyos tokens nativos no habían adquirido suficiente valor como para atraer un interés significativo de los mineros, compartieran la seguridad reutilizando los recursos computacionales dedicados a proteger la red Bitcoin para aumentar la dificultad de los bloques en el nuevo protocolo.

Dicho esto, se considera que la minería de fusión proporciona una forma débil de seguridad económica para las redes descentralizadas debido a su falta de seguridad responsable. En la literatura académica, la seguridad responsable refleja la capacidad de un protocolo para detectar nodos que (demostrablemente) violan las reglas del protocolo y castigar el comportamiento malicioso. Por ejemplo, los protocolos basados en Proof of Stake requieren que los nodos bloqueen la garantía (haciendo staking del token nativo del protocolo) antes de participar en el consenso, y pueden destruir/congelar ("recortar") esta garantía si aparece evidencia de la mala conducta de un validador.

En el caso de la minería fusionada, los nodos que aceptan deliberadamente bloques no válidos en la cadena minada mediante la fusión no pueden detectarse de forma fiable. Además, es imposible castigar a dichos nodos (incluso si fuera posible identificarlos), ya que eso requeriría una medida drástica como quemar o destruir el hardware de minería. Si bien la amenaza de que el token de la cadena minada mediante la fusión pierda valor debido a ataques a su seguridad puede parecer suficiente para desalentar el comportamiento bizantino, los mineros maliciosos tienen menos que perder, ya que es poco probable que se vea afectado el valor de la cadena original (por ejemplo, Bitcoin).

Las nociones modernas de seguridad compartida no solo han evolucionado para incorporar seguridad responsable, sino que también han pasado a utilizar una unidad de inversión diferente (el capital) como base de la seguridad compartida. En este diseño, hay un protocolo base que brinda seguridad a otros protocolos PoS basados en él; los nodos primero se unen a la red principal (bloqueando el token nativo de la red como participación) antes de participar en la protección de la red secundaria.

Este diseño puede tomar diferentes formas:

• Los validadores participan en la red primaria y en la red secundaria simultáneamente
• Se selecciona aleatoriamente un subconjunto de validadores (de la red principal) para validar y proteger la red secundaria.
• La red secundaria está protegida por un conjunto independiente de validadores vinculados a la red primaria.
• Los validadores de la red principal vuelven a delegar el capital apostado a los validadores de la red secundaria

Independientemente de los detalles de implementación, el detalle crucial para los esquemas de seguridad compartida descritos anteriormente es que el protocolo base debe tener los medios para castigar a los validadores que actúen maliciosamente en la red secundaria. Dado que hay menos capital para proteger la red secundaria, la posibilidad de que una supermayoría maliciosa secuestre el protocolo es una preocupación real.

La solución es garantizar que uno o más participantes honestos (que forman la minoría) puedan exigir cuentas a la mayoría iniciando una disputa y publicando evidencias de conductas que violan el protocolo en la capa base. Si el protocolo base (que actúa como un “juez”) acepta esas evidencias, las partes deshonestas pueden ser castigadas mediante la reducción de la garantía (que se ofrece como fianza) en la red primaria. Es importante destacar que la capa base solo tiene que verificar las evidencias proporcionadas y no necesita ejecutar un consenso adicional antes de resolver las disputas, lo que reduce la sobrecarga de coordinación.

El punto más sutil es que la mala conducta debe ser atribuible a alguna de las partes para que los mecanismos de reducción sean efectivos. En las redes basadas en PoS, los validadores deben generar un par de claves pública y privada que sirva como una identidad criptográfica única dentro del protocolo de consenso. Durante las tareas rutinarias, como proponer bloques o dar fe de (la validez de) bloques, un validador firma los datos del bloque con su clave privada, vinculándolos efectivamente a esa elección.

Esto permite bloquear un validador por diferentes acciones que podrían interpretarse como un ataque a la seguridad o actividad del protocolo (o ambas en algunos casos):

• Firma de dos bloques en conflicto durante el mismo período (formalmente conocido como “equivocación”)
• Firmar un bloque no válido (ya sea durante una propuesta o una certificación)
• Censura de una o más transacciones
• Ocultar algunas o todas las partes de los datos de un bloque

Si bien las dos primeras infracciones se pueden detectar de la misma manera (recuperando la clave pública de un validador a partir de su firma), las dos últimas requieren otros mecanismos, como listas de inclusión y códigos de borrado . En todos los casos, el uso de la criptografía permite la detección y el castigo confiables de comportamientos maliciosos que podrían degradar ciertas propiedades de seguridad deseadas en un protocolo, como la resistencia a la censura y la validez de las transacciones. Esto proporciona algo de contexto sobre el significado de "seguridad criptoeconómica", que implica combinar mecanismos criptográficos con incentivos económicos para proteger las redes descentralizadas.

Podemos ilustrar esta idea (y compararla con la minería fusionada) utilizando el ejemplo de una nueva cadena de bloques PoS que comparte la seguridad de Ethereum. Nuestro protocolo de juguete tiene las siguientes propiedades (nótese que es un ejemplo demasiado simplista utilizado con fines ilustrativos):

• Los operadores de nodos deben depositar una cantidad específica de tokens ETH como garantía en un contrato inteligente de Ethereum antes de registrarse como validadores en la red PoS.
• Durante las épocas, los proponentes de bloques en el protocolo PoS envían hashes de encabezados de bloques (que incluyen firmas de validadores) a Ethereum almacenándolos en un contrato inteligente.
• La seguridad se basa en pruebas de fraude : la cadena principal (Ethereum) no verifica las transiciones de estado, pero puede verificar un contraejemplo que muestre que una transición de estado particular no es válida.
• Se activa un mecanismo de corte en cadena si una o más partes disputan una transición de estado particular

Ahora, supongamos que una mayoría maliciosa de nodos en la red secundaria se confabula para finalizar un bloque no válido y robar fondos depositados en el contrato puente. En este escenario, un validador honesto activaría el mecanismo de recorte en cadena en Ethereum publicando una prueba de fraude e identificando a los validadores que violan el protocolo. Si las reglas del protocolo permiten recortar la participación total de un validador, entonces el costo de corromper la cadena PoS es proporcional a la cantidad apostada por la mayoría de los validadores.

Este ejemplo muestra cómo la seguridad responsable sustenta los diseños de seguridad compartida y permite que las redes más pequeñas estén protegidas por protocolos más grandes que han generado una seguridad económica significativa y cuentan con mayores niveles de descentralización y falta de confianza. También podemos ver que la mecánica de Proof-of-Stake conduce a diseños de seguridad compartida con nociones de seguridad más sólidas en comparación con la minería combinada (que utiliza el poder computacional como base de la seguridad económica).

Además, introduce la idea de un nuevo protocolo que utiliza el token de otra red para realizar staking con el fin de mitigar el “problema del bootstrapping” (donde un nuevo protocolo de blockchain tiene baja seguridad económica porque su token no ha adquirido suficiente valor). Si bien el problema del bootstrapping se puede resolver con enfoques (como la minería combinada) que utilizan la inversión en hardware como unidad de seguridad económica, este tipo de seguridad compartida no es óptima por ciertas razones (algunas de las cuales hemos identificado anteriormente):

• La inversión de capital, que se supone que impone costos significativos en caso de comportamiento malicioso para validar nodos, es implícita y difícil de aprovechar para la seguridad económica. Hacer explícita la inversión de capital en el caso de la minería combinada PoW requeriría una medida drástica como la destrucción del hardware de minería en caso de un posible comportamiento malicioso, lo que es poco realista en situaciones del mundo real y difícil de aprovechar.
• La minería combinada (o cualquier diseño de seguridad compartida donde la participación en el consenso está vinculada a la infraestructura en funcionamiento) es difícil de escalar. Por ejemplo, existe un límite superior en la cantidad de cadenas PoW que se pueden minar simultáneamente antes de que el ROI de un minero comience a disminuir.

Por el contrario, los esquemas de seguridad compartida basados en PoS que utilizan la inversión de capital como unidad de inversión tienen ciertas propiedades que son útiles para resolver el problema de poner en marcha nuevas redes de manera eficiente y eficaz:

• La inversión de capital es explícita (los participantes invierten capital en la compra de tokens para cumplir con los requisitos de garantía) y se puede aprovechar para obtener garantías sólidas y concretas de seguridad económica. Por ejemplo, es fácil visualizar que es probable que un protocolo sea más seguro cuando tiene una participación de 1 ETH que asegura transacciones por valor de 0,9 ETH que cuando una participación de 0,9 ETH asegura transacciones por valor de 1 ETH.
• Dado que la participación en el consenso está vinculada a una inversión de capital “pura”, es más fácil escalar la seguridad económica y hacer que los validadores aseguren múltiples protocolos sin incurrir en una sobrecarga de coordinación excesiva (especialmente cuando los requisitos de hardware son bajos).

No obstante, cada enfoque tendrá desventajas y la seguridad compartida a través del staking no es una excepción; por ejemplo, determinar cuánta garantía deben poner los validadores en un protocolo PoS es un problema difícil de resolver. Pondremos esto en contexto considerando esta afirmación del párrafo anterior: “ Es fácil visualizar que es probable que un protocolo sea más seguro cuando tiene 1 ETH de participación asegurando 0,9 ETH de transacciones que cuando 0,9 ETH de participación aseguran 1 ETH de transacciones”.

Si bien esta afirmación parece razonable, un análisis más profundo revela la dificultad de elegir un requerimiento de bono óptimo:

• Exigir 1 ETH a los validadores para asegurar activos por valor de 0,9 ETH disminuye la eficiencia del capital y da como resultado una sobrecolateralización.
• Asegurar transacciones por valor de 2 ETH con una participación de 1 ETH disminuye el ancho de banda económico (o “apalancamiento”) en una cadena de bloques PoS y da como resultado una subcolateralización.

En un escenario ideal, un diseñador de protocolo preferiría tener 1 ETH de participación que garantice transacciones por valor de 1 ETH. Pero tales equilibrios son difíciles de lograr en condiciones del mundo real por diferentes razones; por ejemplo, la cantidad de capital que se debe asegurar por unidad de tiempo (una función del valor marginal de las transacciones por bloque/época) es dinámica. Esto hace que establecer el bono ideal en un sistema PoS sea un problema de mecanismo muy difícil y una consideración importante para los esquemas de seguridad compartida basados en participación, como el resttaking (que analizamos en la siguiente sección).

Seguridad compartida desde el resttaking y los puntos de control

Retomando

La rehipotecación es una práctica de las finanzas tradicionales en la que un prestamista utiliza activos (previamente pignorados como garantía por un prestatario) como garantía para asegurar un nuevo préstamo. En este caso, la nueva contraparte asume los derechos sobre el activo original como garantía, de modo que si la entidad que obtuvo el nuevo préstamo incumple el pago, puede subastar el activo para recuperar los fondos.

Si se implementa correctamente, la rehipoteca puede ser útil. Para empezar, permite una mayor eficiencia y liquidez del capital al reutilizar activos (que de otro modo permanecerían inactivos) para asegurar la financiación a corto plazo de actividades generadoras de ganancias. Si la ganancia obtenida por la obtención de un préstamo supera el valor de la garantía rehipotecada, todas las partes involucradas (el prestatario original, el prestamista y el prestamista del prestamista) se benefician.

La rehipotecación implica un alto grado de riesgo (una de las razones por las que esta práctica ha caído en desuso entre las instituciones de finanzas tradicionales), especialmente para el prestatario original, que podría perder los derechos sobre su activo cuando se produzca una liquidación. El prestamista que reutilice la garantía también corre riesgos, más aún si se le exige que pague a los prestatarios después de que una nueva contraparte confisque la garantía depositada debido a impagos en los préstamos.

El otro riesgo es uno que hemos descrito brevemente anteriormente y gira en torno a la disyuntiva entre sobrecolateralización y subcolateralización. En el ejemplo destacado anteriormente, si el Banco B (el banco de John) entra en una posición de apalancamiento excesivo (en la que toma prestado más que el valor de la garantía de John) y sufre una pérdida, se vuelve difícil devolver el préstamo del Banco B (o devolver los activos de John). El Banco B puede protegerse contra este caso extremo pidiendo al Banco A (el banco de John) que tome prestado menos que el valor de la garantía de John; sin embargo, eso aumenta la ineficiencia de capital para el Banco A y reduce las ganancias de rehipotecar la garantía de John en primer lugar.

El mismo conjunto de pros y contras también se aplica al resttaking. Antes de continuar, es importante aclarar un detalle importante: la participación de un restaker siempre pasa primero por el protocolo base. Por ejemplo, un restaker en Ethereum tendrá que depositar 32 ETH en el contrato de Beacon Chain o delegar ETH a un validador operado por un servicio de staking, dependiendo de si se utiliza resttaking nativo o líquido .

A un alto nivel, el resttaking en el caso de Ethereum comprende lo siguiente:

#1: Otorgar al protocolo de reescritura derechos de propiedad (o un reclamo) sobre ETH en staking

En el resttaking nativo, se requiere que un validador cambie su dirección de retiro a un contrato inteligente administrado por el protocolo de resttaking. Por lo tanto, en lugar de que los fondos vayan directamente al validador después de salir de Beacon Chain, la participación pasa primero por el protocolo de resttaking antes de llegar al validador (pronto veremos por qué es así).

También es posible depositar representaciones fungibles (derivados) de ETH en stake en los contratos inteligentes del protocolo de resttaking (restaking líquido). Estos tokens, llamados "tokens en stake líquido", son emitidos por operadores de staking como servicio (por ejemplo, RocketPool, Lido, Coinbase, etc.) y representan un derecho a una parte de ETH en stake por un validador (incluido el rendimiento de las recompensas) y pueden canjearse en una proporción de 1:1 por tokens ETH nativos.

#2: Aceptar condiciones de recorte adicionales impuestas por el protocolo de resttaking

Un protocolo de resttaking suele funcionar como un “middleware” al que se pueden conectar varias redes y aplicaciones descentralizadas para lograr seguridad económica. Por lo general, estos protocolos incluyen protocolos que requieren algún tipo de validación por parte de un conjunto de partes (por ejemplo, una red de oráculos), pero cuyo token nativo no ha acumulado suficiente valor para ser utilizado en un entorno de Proof of Stake.

En lugar de crear un nuevo conjunto de validadores desde cero, estas aplicaciones pueden contratar los servicios de validadores existentes a través de un protocolo de re-participación. Los servicios pueden especificar condiciones de reducción únicas para la garantía rehipotecada de un validador (que el protocolo de re-participación puede aplicar ya que ahora controla el retiro del validador), lo que reduce la barrera a la seguridad económica.

Una nota importante: las condiciones de reducción de AVS son independientes de las condiciones de reducción impuestas por el consenso de Beacon Chain de Ethereum, por lo que la participación en ETH de un validador podría reducirse incluso si no cometió una infracción que pueda reducirse en Ethereum. Esto podría conducir a lo que describimos como "acumulación de riesgos": a cambio de una mayor eficiencia de capital, la red principal hereda un riesgo adicional del que heredaría de otra manera. (La acumulación de riesgos también tiene implicaciones para el protocolo central EigenLayer en sí, como veremos más adelante).

#3: Recibir recompensas adicionales

El resttaking requiere asumir un riesgo significativo (por ejemplo, un validador resttaking podría ser recortado accidentalmente debido a un error en el mecanismo de recorte en cadena), pero al igual que la rehipotecación desbloquea la liquidez en TradFi, el resttaking puede mejorar la eficiencia del capital en los ecosistemas PoS y generar un rendimiento más alto que el promedio para los stakers.

Esto se basa en el hecho de que los servicios que utilizaron capital reestablecido para la seguridad deben recompensar a los validadores por sus servicios. Por ejemplo, un validador reestablecido que participe en una red de oráculos recibirá tarifas por validar las actualizaciones de los oráculos, y el pago provendrá de otras aplicaciones de terceros que dependen de los servicios del oráculo. Como los validadores siguen recibiendo recompensas de Beacon Chain, el reestablecimiento permite obtener ingresos de múltiples protocolos PoS sin tener que volver a implementar capital nuevo en un nuevo ecosistema.

Aunque en este ejemplo nos centramos en el resttaking de Ethereum, otros protocolos de Proof of Stake también han implementado variantes del resttaking para lograr objetivos similares (reducir el costo de lanzamiento de nuevos protocolos/aplicaciones, mejorar la eficiencia del capital y escalar la seguridad económica). De hecho, la siguiente sección analiza EigenLayer (el principal protocolo de resttaking de Ethereum) antes de pasar a destacar el resttaking en otros ecosistemas:

Capa propia

EigenLayer es un protocolo de re-staking creado para extender la seguridad económica de Ethereum y proteger nuevas aplicaciones, redes y protocolos distribuidos (que se describen colectivamente como "Servicios Validados Activamente" o AVS, por sus siglas en inglés). Si has leído la sección anterior que describe el ejemplo de re-staking en Ethereum, entonces ya entiendes las operaciones de EigenLayer a un alto nivel; sin embargo, incluiremos algunos detalles más para contextualizar.

Después de volver a realizar el staking de ETH (al apuntar las credenciales de retiro asociadas con un validador a los contratos inteligentes controlados por EigenLayer), se requiere que un validador realice tareas especificadas por el AVS que desea operar. Por ejemplo, si un AVS es una cadena lateral, el validador que ha realizado el staking nuevamente debe ejecutar el software cliente para que la cadena lateral ejecute transacciones y verifique bloques, mientras obtiene recompensas por realizar estas tareas correctamente. En términos más generales, las tareas pueden variar según la naturaleza del AVS:

• Almacenamiento de datos en una red de disponibilidad de datos

• Aprobar transacciones de depósito y retiro para un puente entre cadenas o aprobar mensajes para un protocolo de mensajería entre cadenas

• Generación y verificación de pruebas de conocimiento cero para una aplicación centrada en la privacidad o una red de pagos protegida

• Almacenamiento y verificación de encabezados de bloques y ejecución de retransmisores/oráculos para protocolos de interoperabilidad entre cadenas

  
  

Los lectores astutos notarán dos cosas: (a) las tareas especificadas por un AVS pueden ser bastante arbitrarias y (b) las diferentes tareas especificadas por un AVS requieren distintos niveles de inversión y esfuerzo. Para ilustrar este último punto, es posible imaginar que almacenar encabezados de bloques en un protocolo de cadena cruzada requerirá menos espacio de disco/memoria en comparación con el almacenamiento y aprovisionamiento de datos en una red de disponibilidad de datos (incluso cuando técnicas como el muestreo de disponibilidad de datos reducen las cargas de almacenamiento en nodos individuales).

Esta es una de las razones por las que EigenLayer permite que los validadores restablecidos deleguen la ejecución de tareas especificadas por AVS a otra parte (un operador) que comparte las recompensas obtenidas del AVS con el validador. Este enfoque tiene distintos niveles de riesgo para los validadores restablecidos según el grado en que la carga de la reducción (que puede ocurrir si el operador no lleva a cabo las tareas de AVS correctamente) se comparta entre el validador restablecido y el operador externo.

Cada AVS especifica un conjunto de condiciones bajo las cuales se puede reducir la participación de un restaker de EigenLayer. Por ejemplo, una red de disponibilidad de datos que implementa mecanismos de Prueba de espacio/almacenamiento puede reducir la participación de los operadores que no almacenen datos durante el período acordado. La reducción provoca la congelación del operador dentro de EigenLayer (lo que impide una mayor participación en uno o más servicios validados activamente) y la reducción final del saldo de ETH del validador.

Para que se produzca un corte, la infracción debe ser demostrable (que es lo que permite al protocolo base (Ethereum en este caso) resolver disputas y castigar a la parte deshonesta). El diseño actual de Ethereum permite cortar hasta el 50 % de la participación de un validador (16 ETH), lo que deja a EigenLayer con derechos para cortar el 50 % restante (16 ETH) en caso de que un operador infrinja las reglas especificadas por el AVS mientras ejecuta tareas.

La mecánica de slashing de EigenLayer también sugiere un riesgo sutil de re-staking: ser slasheado por un servicio reduce el balance general de un validador en los contratos inteligentes de EigenLayer y en la Beacon Chain de Ethereum. Sin embargo, es importante destacar que aparece un escenario extremo cuando el slashing ocurre debido a un error en la lógica de slashing de un AVS en particular y no como resultado de una infracción demostrable. En este caso, la pérdida de recompensas por validar la cadena principal de Ethereum (que se supone que es mayor que las recompensas por validar el AVS) haría que el ROI por re-staking sea subóptimo desde la perspectiva de un validador.

Otro riesgo que conlleva el resttaking al estilo EigenLayer es el riesgo de sobrecolateralización y subcolateralización del validador y el concepto de acumulación de riesgos. Del ejemplo anterior de rehipotecación, vemos que la parte que rehipoteca la garantía puede estar endeudada simultáneamente con el primer prestatario (cuya garantía se utiliza para obtener un nuevo préstamo) y con el prestamista final de la cadena (que tiene un derecho sobre la garantía pignorada por el prestatario original).

Una dinámica similar puede ocurrir en construcciones de restacking como EigenLayer si un validador que ha sido restacking (voluntaria o deliberadamente) comete simultáneamente delitos susceptibles de ser cortados en la Beacon Chain de Ethereum y en uno o más AVS. Dependiendo de dónde ocurra el primer corte, es posible que a otros AVS no les quede nada para cortar, lo que permite un ataque sin riesgo a las aplicaciones protegidas por EigenLayer.

El equipo de EigenLayer ha reconocido este vector de ataque (consulte el Apéndice B: Análisis de riesgo criptoeconómico del documento técnico de EigenLayer ) y ha tomado varias medidas para abordar este riesgo. Esto incluye proporcionar una heurística formal para evaluar la subcolateralización y la sobrecolateralización de los participantes en los AVS, e indicar planes para proporcionar información de asesoramiento a los desarrolladores de AVS a través de un panel de control de gestión de riesgos en el lanzamiento.

Paracaídas Polkadot

Aunque Polkadot es conocido principalmente por permitir la interoperabilidad entre cadenas de bloques heterogéneas, depende en gran medida de la seguridad compartida. De hecho, la seguridad compartida es la razón por la que las diferentes cadenas en el ecosistema de Polkadot pueden intercambiar mensajes sin introducir suposiciones de confianza ni incurrir en riesgos de seguridad.

En Polkadot, los subconjuntos de validadores (que tienen tokens DOT en stake en la Relay Chain) se asignan aleatoriamente a parachains (es decir, “cadenas secundarias”) para verificar bloques (y la Prueba de Validez (PoV) asociada) producida por el cotejador de cada parachain. Un cotejador es el nodo responsable de ejecutar las transacciones de una parachain y crea un “parabloque” que se envía al grupo de validadores de la parachain para su verificación.

Como verificar el punto de vista de un bloque requiere un gran esfuerzo computacional, los paravalidadores (el nombre de los validadores asignados a una parachain) reciben recompensas adicionales por esta tarea. Los bloques aprobados por los paravalidadores (o, más precisamente, los compromisos criptográficos con esos bloques) se envían para su inclusión en la Relay Chain (es decir, la “cadena principal”). Un bloque de parachain se vuelve definitivo si un bloque que lo referencia es aprobado por la mayoría del conjunto restante de validadores en la Relay Chain.

El último punto es bastante importante: como la cantidad de validadores en cada parachain es baja (alrededor de cinco validadores por fragmento), el costo de corromper fragmentos individuales es bajo. Para defenderse de tales ataques, el protocolo Polkadot requiere que los parabloques se sometan a una verificación secundaria por parte de otro grupo de nodos seleccionados al azar.

Si se demuestra que un bloque no es válido o no está disponible (es decir, falta alguna parte de los datos), los nodos honestos pueden iniciar una disputa en la Relay Chain principal en la que todos los validadores de la Relay Chain deben volver a ejecutar el bloque en disputa. Una disputa termina después de que una supermayoría de ⅔ de los validadores vote por cualquiera de los lados de la disputa, y los validadores infractores serán eliminados en la cadena si la reejecución respalda el reclamo de eliminación.

Este mecanismo garantiza que todas las parachains del protocolo Polkadot compartan el mismo nivel de seguridad, independientemente del tamaño del validador establecido en cada fragmento. Además, las parachains obtienen la seguridad de la misma fuente (todos los parabloques son aprobados por la Relay Chain) y pueden confiar en la validez de los mensajes que se originan en un fragmento remoto (sin conocer necesariamente los detalles del consenso o el estado de este último).

Seguridad entre cadenas

La seguridad entre cadenas se ha descrito como la respuesta de Cosmos al resttaking y guarda similitudes con el modelo de seguridad compartida de Polkadot. De manera similar a la relación entre la Relay Chain y las parachains en Polkadot, Cosmos adopta un modelo de hub-and-spoke donde múltiples cadenas (“Cosmos Zones”) se conectan a una cadena principal (el “Cosmos Hub”) y derivan seguridad de ella. La lógica también es similar a la de Polkadot: permitir que las nuevas cadenas sigan siendo seguras sin necesidad de crear un conjunto de validadores confiables desde cero (una tarea bastante difícil) y, en cambio, compartir la seguridad económica (agrupada en una sola capa) con otras cadenas.

En su iteración actual, la seguridad entre cadenas requiere un validador (que haya depositado tokens ATOM) para validar tanto el Cosmos Hub como todas las cadenas de consumidores conectadas a él. Un validador que actúe maliciosamente en una cadena de consumidores corre el riesgo de perder su participación en la cadena del proveedor (el Cosmos Hub en este caso) debido a un slashing.

Para eliminar un validador infractor, normalmente es necesario retransmitir un paquete que contenga evidencia de un comportamiento susceptible de ser eliminado a través del canal IBC (Inter-Blockchain Communication) entre la cadena del proveedor y la cadena del consumidor. Por lo tanto, la seguridad entre cadenas puede considerarse una forma de resttaking; además, logra un objetivo fundamental: facilitar el lanzamiento de cadenas de bloques específicas para cada aplicación en el ecosistema Cosmos.

Anteriormente, los proyectos que intentaban crear cadenas de bloques soberanas debían crear un token nativo para hacer staking y atraer una cantidad suficiente de validadores para brindarles a los nuevos usuarios garantías mínimas de seguridad. Sin embargo, la seguridad entre cadenas garantiza que la seguridad del Cosmos Hub (protegido por aproximadamente $2500 millones en staking al momento de escribir este artículo) se pueda escalar para proteger cadenas más nuevas y de bajo valor sin necesidad de expandir el tamaño del conjunto de validadores existente de Cosmo.

Nota : La versión actual de la seguridad entre cadenas de Cosmos desactiva el slashing basándose únicamente en paquetes retransmitidos por cadenas de consumidores debido al riesgo de que un código malicioso en una cadena de consumidores active la transmisión de paquetes de slash falsos y slashee a validadores honestos; en cambio, delitos como la doble votación (firmar dos bloques a la misma altura) están sujetos a slashing social a través de la gobernanza. Sin embargo, el slashing social conlleva sus propios riesgos, como se vio en el reciente debate sobre el slashing de validadores por doble firma en una cadena de consumidores (que también insinúa algunas de las complejidades de desarrollar protocolos de seguridad compartidos) .

La seguridad en malla es una alternativa a la seguridad entre cadenas y busca mejorar algunas de las deficiencias de esta última. En lugar de ejecutar software tanto para las cadenas de proveedores como para las de consumidores, un validador que tenga participación en la cadena de proveedores puede delegar la participación a un validador en la cadena de consumidores. Esto alivia la carga de validar dos cadenas simultáneamente (participar en la gobernanza y el consenso) y reduce la sobrecarga para los validadores que tienen participación en la cadena (por ejemplo, reduciendo los requisitos de hardware).

Al igual que en el caso de EigenLayer (donde un validador de Ethereum puede hacer que un operador valide uno o más protocolos secundarios (AVS) en su nombre), no se requiere que un validador delegado realice ninguna inversión para validar la cadena de consumidores. Si el validador delegado no cumple con sus funciones correctamente (por ejemplo, sufre un tiempo de inactividad o crea/vota bloques no válidos), el delegador es eliminado de la cadena de consumidores según las reglas del protocolo.

La seguridad en malla también es diferente de la seguridad entre cadenas, ya que permite que las cadenas de consumidores alquilen seguridad de múltiples cadenas de proveedores (en lugar de estar restringidas al Cosmos Hub) y permite que los validadores elijan a qué cadenas delegar la participación. Si bien la última característica está planificada como parte del lanzamiento de ICS v2, es poco probable que se implemente la primera (aunque podría decirse que es más convincente).

Comité de sincronización de Ethereum

El Comité de Sincronización de Ethereum es un grupo de 512 validadores responsables de aprobar los encabezados de bloque Beacon finalizados. Se reconstituye un nuevo Comité de Sincronización cada 256 épocas (aproximadamente 27 horas), con miembros seleccionados del conjunto de validadores existente de Beacon Chain. Tenga en cuenta que se espera que los miembros continúen con sus tareas habituales de validación (incluidas la certificación y las propuestas de bloques) mientras participan en el Comité de Sincronización.

El Comité de Sincronización se implementó por primera vez durante la bifurcación Altair de Beacon Chain para permitir que los clientes ligeros verifiquen nuevos bloques (sin conocer el conjunto completo de validadores) y realicen un seguimiento de los cambios en el estado de Ethereum. Dado que participar en el Comité de Sincronización requiere más esfuerzo que simplemente participar en el consenso de Beacon Chain, los miembros reciben una pequeña recompensa (además de las recompensas habituales por completar las tareas de Beacon Chain).

Sin embargo, los miembros que aprueban encabezados de bloque no válidos no están sujetos a recortes, a diferencia de lo que ocurre en Beacon Chain. Los desarrolladores principales de Ethereum han defendido este diseño diciendo que recortar a los miembros malintencionados del Comité de Sincronización introduciría más complejidad, mientras que otros han insinuado la dificultad de la colusión entre la supermayoría de ⅔ de los miembros del Comité de Sincronización (lo que se necesitaría para engañar a los clientes ligeros para que acepten un encabezado de bloque incorrecto).

Pero con aplicaciones de alto valor (como los protocolos de comunicación entre cadenas) que dependen de clientes ligeros para rastrear el estado de Ethereum, el tema de recortar los comités de sincronización por firmar encabezados de bloques no válidos ha atraído un renovado interés (cf. una propuesta en curso del equipo de clientes de Nimbus ). Si se implementa, el recorte convertiría la participación en el comité de sincronización en una forma de re-participación mediante la cual los validadores optan por condiciones de recorte adicionales y reciben recompensas adicionales por el servicio secundario de firmar encabezados de bloques.

Para ilustrar esto, un validador podría ser reducido (hasta su saldo máximo) si viola las reglas del protocolo mientras está en el Comité de Sincronización, incluso si actúa honestamente mientras participa en el consenso de Beacon Chain. También podemos comparar el Comité de Sincronización con el sistema de paracadena de Polkadot y otras formas de seguridad compartida que toman muestras aleatorias de un subconjunto de nodos para validar un subprotocolo dentro de la red de blockchain más grande (por ejemplo, los Comités Estatales de Lagrange, las Subredes de Avalanche y el protocolo State Proofs de Algorand).

Puntos de control

Los esquemas de seguridad compartida basados en puntos de control a menudo implican que una cadena que consume seguridad publique compromisos criptográficos sobre su último estado en la cadena que proporciona seguridad a intervalos. Por ejemplo, se puede exigir a un proponente de bloques que publique el hash del encabezado del bloque más nuevo en la cadena principal antes de que se finalice.

Estos compromisos se describen como "puntos de control" porque la cadena principal garantiza la irreversibilidad del historial de la cadena secundaria que conduce hasta ese punto. En otras palabras, la cadena principal garantiza y aplica un orden temporal (canónico) de la cadena secundaria, protegiéndola contra intentos de reorganizar bloques y crear una bifurcación conflictiva (por ejemplo, para revertir transacciones antiguas y realizar un doble gasto).

La cadena principal también puede garantizar la validez de la cadena secundaria, especialmente cuando los encabezados de bloque tienen información sobre quién atestiguó o produjo un bloque en particular. Si un bloque resulta ser inválido, un nodo honesto puede iniciar un desafío en la cadena principal (con la cadena principal arbitrando la disputa) y desencadenar una reversión del estado de la cadena secundaria.

Además, si se implementa un mecanismo para gestionar las participaciones de los validadores (como un contrato inteligente) en la cadena principal, es posible hacer cumplir la seguridad responsable eliminando los validadores que violan el protocolo después de que se acepta una prueba válida de fraude en la cadena. El hecho de que la cadena principal garantice el historial canónico de la cadena secundaria es importante aquí, ya que evita que los nodos reescriban el historial (eliminando bloques) para ocultar evidencia de comportamiento malicioso.

Las cadenas laterales de confirmación (Polygon PoS), los optimiums (Arbitrum Nova/Metis), los rollups y las cadenas integradas con protocolos de puntos de control como Babylon implementan esta forma de seguridad compartida. En todos los casos, un protocolo obtiene su seguridad económica de una cadena de bloques externa al utilizarla como capa de liquidación (responsable de finalizar los bloques). Para ponerlo en contexto, Polygon PoS y Arbitrum Nova/Metis almacenan los encabezados en un contrato en cadena en Ethereum, mientras que Babylon transmite los encabezados desde las Cosmos Zones conectadas a Bitcoin.

Los rollups de capa 2 (L2) utilizan un mecanismo similar (publicando las raíces de los bloques en la cadena de bloques de capa 1), con una diferencia crucial: los datos necesarios para recrear los bloques de un rollup también se publican en la capa de liquidación. Esto significa que la capa de liquidación garantiza por completo la seguridad del rollup (eventualmente). Por el contrario, los datos necesarios para reconstruir el estado de una cadena lateral de confirmación o una cadena optimista pueden no estar disponibles, en particular en el caso de un secuenciador o un conjunto de validadores maliciosos que realicen ataques de retención de datos.

Seguridad compartida para protocolos de interoperabilidad entre cadenas

Después de haber brindado una amplia información sobre el significado y la evolución de la seguridad compartida, ahora podemos adentrarnos en nuevas fronteras en los diseños de seguridad compartida. Una de esas áreas de investigación es la seguridad compartida para protocolos entre cadenas , que busca mejorar los enfoques actuales de mensajería y conexión entre cadenas de bloques aprovechando los beneficios de la seguridad (económica) agrupada.

Esta definición puede suscitar preguntas en la mente del lector, tales como:

• ¿Por qué el enfoque explícito en los protocolos de interoperabilidad?

• ¿Qué beneficios obtiene un protocolo de interoperabilidad al integrarse con una tecnología de seguridad compartida?

  
  

Lagrange Labs está construyendo Lagrange State Committees , una solución de seguridad compartida para protocolos que requieren acceso a pruebas de estados entre cadenas con confianza minimizada. (State Committees combina el sistema de pruebas ZK Big Data de Lagrange y la infraestructura de resttaking de EigenLayer para crear una zona de seguridad compartida para protocolos de interoperabilidad entre cadenas). Como tal, nos sentimos obligados a analizar cada una de las preguntas anteriores y, en el proceso, defender la integración de aplicaciones de puenteo, indexación y mensajería con la infraestructura de State Committee.

Una breve introducción a los protocolos de interoperabilidad

En Interoperabilidad para cadenas de bloques modulares: la tesis de Lagrange , explicamos que los protocolos de interoperabilidad son cruciales para conectar cadenas de bloques aisladas y mitigar los problemas relacionados con la fragmentación de la liquidez y el estado de las aplicaciones de cadenas de bloques (y sus usuarios). Algunos ejemplos clave mencionados en ese artículo incluyen:

• Puentes que implementan mecanismos de bloqueo y acuñación o quema y acuñación y permiten transferir un activo desde una cadena de bloques nativa (donde fue emitido) para su uso en una cadena de bloques no nativa

• Protocolos de mensajería que permiten a los usuarios transmitir información de forma segura (a través de paquetes de datos) entre cadenas de bloques que no comparten una única fuente de verdad y no pueden verificar los estados de los demás.

  
  

También destacamos el valor de los diferentes tipos de soluciones de interoperabilidad de blockchain . Por ejemplo, los puentes permiten a los usuarios moverse sin problemas entre diferentes ecosistemas, ganar exposición a más aplicaciones y aumentar la eficiencia de los activos (al aprovechar las oportunidades de generación de rendimiento que existen en otras cadenas de bloques). Los protocolos de mensajería también desbloquean casos de uso más avanzados como préstamos entre cadenas, arbitraje entre cadenas y márgenes entre cadenas y entre cadenas que se basan en la transferencia de información (por ejemplo, posiciones y perfiles de deuda) entre varios dominios.

Aunque están diseñadas para distintos propósitos, todas las soluciones de interoperabilidad comparten algunas propiedades básicas. La más importante es un mecanismo para verificar que cierta información sobre las cadenas de bloques involucradas en una transacción/operación entre cadenas (proporcionada por el usuario o una aplicación) sea verdadera. Esto suele ser una afirmación de que existe un estado particular (por ejemplo, valores almacenados en el almacenamiento de un contrato inteligente, el saldo de una cuenta o el bloque finalizado más recientemente) o de que se produjo una transacción en una cadena diferente.

Tomemos el ejemplo de un puente entre Ethereum y NEAR; el operador del puente deberá validar la siguiente información sobre el estado de cada cadena cuando un usuario esté conectando un activo (por ejemplo, DAI):

• Antes de acuñar tokens nearDAI en la dirección NEAR del usuario, el operador del puente necesita una prueba de que dicho usuario depositó DAI en el contrato del puente en Ethereum.
• Antes de liberar el depósito DAI original (al hacer un puente desde NEAR a Ethereum), el operador del puente necesita una prueba de que dicho usuario quemó tokens nearDAI en NEAR y envió el recibo de "prueba de quema" requerido al contrato del puente en NEAR.

Un protocolo de mensajería entre las cadenas mencionadas anteriormente tendrá requisitos similares, pero ligeramente diferentes. Si un usuario de Ethereum solicita la ejecución de una transacción entre cadenas (“llamar al contrato X en NEAR”), el protocolo debe verificar que la solicitud de mensaje se realizó originalmente en Ethereum (normalmente llamando a un contrato en cadena).

Una forma sencilla de validar las afirmaciones sobre las transacciones entre cadenas es ejecutar un nodo completo para la cadena en cuestión. Los nodos completos que descargan transacciones de cada bloque y vuelven a ejecutarse antes de sincronizar el último estado de la cadena suelen ser la forma menos fiable de verificar las transiciones de estado en cualquier cadena de bloques. Sin embargo, ejecutar un nodo completo es arduo e innecesario; arduo porque los nodos completos requieren altos requisitos de hardware e innecesario porque un protocolo entre cadenas solo necesita información relevante para algunos conjuntos de transacciones y contratos.

Afortunadamente, los clientes ligeros proporcionan una manera fácil y eficaz de realizar un seguimiento de eventos y cambios de estado sin necesidad de ejecutar un nodo completo. Siempre que confiemos en el diseño del cliente ligero, podemos simplemente descargar encabezados de bloques para verificar información específica, como la ocurrencia de depósitos/retiros en un puente y el estado de las solicitudes de mensajes/ejecución en un protocolo de mensajería.

Para permitir la comunicación entre dos cadenas (que llamaremos cadena A y cadena B), un protocolo de interoperabilidad ejecutaría un cliente ligero de la cadena A en la cadena B que almacena los encabezados de bloque de la cadena B (y viceversa). Esto le permite verificar varias pruebas de estado/almacenamiento (encabezados de bloque, pruebas de Merkle, etc.) pasadas por los usuarios (o cualquier tercero) desde una aplicación en la cadena de origen a otra aplicación en la cadena de destino. El cliente ligero funciona como una fuente de información (un "oráculo") sobre los estados de las dos cadenas de bloques, como se ilustra en la siguiente imagen:

Sin embargo, este enfoque para verificar la validez de los estados entre cadenas se enfrenta al problema de la confianza. El artículo Trust Models de Vitalik Buterin proporciona una definición concisa de la confianza: “ La confianza es el uso de cualquier suposición sobre el comportamiento de otras personas”. El artículo también define el concepto de falta de confianza (con una salvedad):

Una de las propiedades más valiosas de muchas aplicaciones blockchain es la falta de confianza: la capacidad de la aplicación de seguir funcionando de la forma esperada sin necesidad de depender de un actor específico para que se comporte de una manera específica, incluso cuando sus intereses podrían cambiar y empujarlo a actuar de alguna manera inesperada en el futuro. Las aplicaciones blockchain nunca son completamente libres de confianza, pero algunas aplicaciones están mucho más cerca de serlo que otras. — Vitalik Buterin

En nuestro contexto (interoperabilidad de cadenas de bloques), la confianza se vuelve inevitable cuando el estado de dos o más cadenas se valida de forma independiente una de la otra. Consideremos un escenario en el que la aplicación de Bob en la cadena A recibe una prueba de que Alice inició un mensaje (“bloquear 5 ETH en la cadena B y acuñar 5 Wrapped ETH (WETH) en la cadena A”). La prueba del mensaje es una prueba de Merkle que muestra la inclusión de la transacción de Alice en un bloque, que Bob (debido a que ejecuta un cliente ligero en la cadena para la cadena B) puede verificar comparando la prueba con la raíz de Merkle de las transacciones derivadas del encabezado de un bloque válido de la cadena B.

Sin embargo, “válido” en el contexto de un bloque puede significar diferentes cosas: (a) “El encabezado del bloque pertenece a un bloque aprobado por la mayoría de los validadores de la cadena de origen”. (b) “El encabezado del bloque pertenece a un bloque cuyas transacciones son válidas de acuerdo con las reglas de validez de transacciones de la cadena de origen”.

Bob puede tratar el punto 1 como una prueba concreta de la validez de un bloque, pero esto se basa en suposiciones sobre los validadores en la cadena de origen:

• “ La mayoría de los validadores de la cadena A son honestos y no aprobarían un bloque con una o más transacciones no válidas”.
• “ La mayoría de los validadores de la cadena A son actores económicamente racionales y tienen bajos incentivos para aprobar un bloque con transacciones no válidas”.

Aquí, es fácil ver dónde cualquiera (o ambos) de estos supuestos pueden fallar; por ejemplo, si la cantidad de participación < valor de las transacciones en la cadena A (por ejemplo, la cantidad que se puede robar de un puente a través de transacciones fraudulentas), los validadores tienen incentivos para finalizar un bloque inválido, incluso si eso significa ser recortados, ya que la ganancia de un ataque supera los costos.

En general, todos los mecanismos para verificar estados entre cadenas están sujetos a suposiciones de confianza (analizaremos algunas de estas suposiciones de confianza en detalle). El objetivo clave (y este es un tema que se repite a lo largo de este artículo) es que queremos minimizar la confianza en la comunicación entre cadenas a un nivel en el que las diversas suposiciones de confianza no representen un gran riesgo de seguridad para las aplicaciones centradas en la interoperabilidad.

Este es un objetivo importante porque, como se ha demostrado, cuando se crea un protocolo de interoperabilidad para vincular diferentes cadenas de bloques y una aplicación que se ejecuta en un lado de la brecha acepta una afirmación falsa de que ocurrió algún evento arbitrario en el otro lado, pueden suceder cosas malas (realmente malas). Para ilustrarlo, se han producido exploits de puentes porque un error permitió a piratas informáticos astutos reenviar con éxito pruebas (falsas) de solicitudes de mensajes inexistentes y acuñar tokens en una cadena de destino sin depositar garantías en la cadena de origen.

Análisis de los mecanismos de seguridad entre cadenas existentes

Desde entonces, los diseñadores de protocolos han ideado soluciones al problema de la validación de información en la comunicación entre cadenas; la más común es el uso de un tercero para verificar la existencia o validez de una transacción entre cadenas. La lógica es simple: una aplicación en la cadena A podría no ser capaz de verificar el estado de la cadena B, pero podemos hacer que verifique que un grupo de personas (en quienes confiamos o esperamos que sean honestos a través de algún mecanismo) han validado una pieza de información (o afirmación) que hace referencia al estado de la cadena B.

Esto se denomina “verificación externa”, ya que otra parte externa a la cadena de bloques actúa como fuente de verdad para los eventos en cadena y (normalmente) implica que uno o más verificadores ejecuten firmas en los encabezados de bloque de la cadena de origen. Una vez que la aplicación en la cadena de destino recibe este encabezado firmado, puede verificar varias pruebas de estado proporcionadas por un usuario (saldos, eventos, depósitos/retiros, etc.) en relación con él.

Para establecer un cierto nivel de tolerancia a fallos, algunos protocolos de interoperabilidad utilizan un esquema de firma de umbral que requiere una cantidad mínima de claves privadas para ejecutar una firma para su validez (las billeteras multifirma y multipartidaria (MPC) son ejemplos comunes). Pero tener una pluralidad ( k de n ) de verificadores que den fe de los estados entre cadenas no es exactamente una solución milagrosa para la seguridad, especialmente para pequeños conjuntos de verificadores.

Por ejemplo, alguien podría comprometer a una cantidad suficiente de firmantes en un esquema multifirma y proceder a autorizar retiros fraudulentos a través de un puente entre cadenas. Una configuración de MPC es ligeramente más segura (el umbral de aprobación se puede cambiar y las claves compartidas se pueden rotar con mayor frecuencia), pero sigue siendo susceptible a ataques (especialmente en casos en los que una de las partes controla la mayoría de las claves compartidas).

Estaca

Una forma de reducir los supuestos de confianza para los protocolos de interoperabilidad y mejorar la seguridad de la comunicación entre cadenas es que los verificadores externos pongan en juego la garantía como un bono antes de asumir las tareas de verificación. El staking crea seguridad para los sistemas verificados externamente, en particular porque la garantía en juego puede reducirse si un nodo verificador ejecuta una firma en un encabezado de bloque no válido o aprueba una transacción entre cadenas no válida.

Pero incluso este enfoque conlleva problemas según si el staking está sujeto a permisos o no. Un sistema sujeto a permisos (en el que los validadores deben estar incluidos en una lista blanca) suele estar restringido a unas pocas entidades aprobadas previamente y es más fácil de desarrollar (no es necesario invertir en un diseño de incentivos exhaustivo, especialmente cuando los validadores son conocidos públicamente y tienen incentivos para actuar honestamente para preservar su reputación). También es eficiente, ya que la comunicación (necesaria para alcanzar el consenso) se produce entre unas pocas partes que ya se conocen a sí mismas.

Por supuesto, tener un sistema con permisos y participantes identificables abre la puerta a ataques adversarios; por ejemplo, un atacante podría hacerse pasar por algunos de estos validadores o sobornarlos y, de ese modo, asumir el control mayoritario. Peor aún, un sistema de prueba de autoridad (PoA) en el que los validadores no están realmente comprometidos (sino que simplemente son designados) reduce el costo de atacar el sistema a cero (los atacantes pueden simplemente comprometer a los validadores de PoA a través de esquemas de ingeniería social y secuestrar el sistema, por ejemplo).

Un sistema de staking sin permisos aumenta el costo de corromper un sistema al permitir que cualquier parte interesada (con la cantidad adecuada de capital) comience a validar operaciones entre cadenas. Si se combina con un protocolo de consenso que requiere una mayoría ≥ ⅔ para dar fe de los encabezados de bloque, el costo de corromper el sistema equivaldría efectivamente a la cantidad mínima requerida para corromper a la mayoría de los verificadores en el sistema. Además, los usuarios tienen menos suposiciones de confianza (los validadores pueden ser recortados), y un conjunto dinámico de verificadores aumenta la dificultad de comprometer nodos específicos a través de técnicas como la ingeniería social.

¿Qué podría salir mal? Mucho, en realidad. Para empezar, la cantidad de dinero que se invierte en proteger el sistema debe ser igual o mayor que el valor total de los activos en riesgo si ocurre un incidente de seguridad (que degrade la seguridad o la operatividad del protocolo de interoperabilidad). Si ocurre lo contrario ( la cantidad total de dinero que se invierte en proteger el sistema < el valor total en riesgo ), entonces incluso la amenaza de cortar el sistema se vuelve ineficaz para garantizar la seguridad, ya que el beneficio de corromper el sistema supera el costo de corromperlo.

Además, intentar implementar la propiedad de seguridad antes mencionada probablemente requeriría establecer requisitos de participación más altos para los posibles validadores. Esto, a su vez, introduce el problema de la ineficiencia de capital, ya que la seguridad depende de que los nodos validadores hagan dos cosas:

• Depositar una gran cantidad de dinero por adelantado (como apuesta) antes de participar en las tareas de validación

• Dejar el dinero sin usar durante un largo período (por seguridad, los protocolos PoS imponen demoras prolongadas en los retiros, algunos de hasta semanas o meses, para evitar casos extremos en los que un validador comete una infracción susceptible de ser recortada e intenta retirar fondos inmediatamente para evitar perder fondos por el recorte)

  
  

Otra cosa que no hemos mencionado es la carga que supone para los desarrolladores, que ahora deben razonar sobre los incentivos criptoeconómicos para desalentar el comportamiento deshonesto y diseñar una funcionalidad compleja de participación para el token del protocolo. Además de desviar la atención de actividades más importantes (como el desarrollo de productos y la participación de la comunidad), también aumenta la complejidad y la sobrecarga cognitiva del ciclo de desarrollo para los equipos que construyen la infraestructura de interoperabilidad.

Verificación optimista

La “verificación optimista” es otra forma de abordar el problema de la seguridad entre cadenas: en lugar de pedirle a una parte o grupo de confianza que certifique el estado entre cadenas, permitimos que cualquiera lo haga. Fundamentalmente, la parte que realiza afirmaciones sobre los estados entre cadenas a una aplicación de interoperabilidad de cliente (normalmente denominada “retransmisor”) no está obligada a proporcionar pruebas de que el estado certificado es válido. Esto se debe a la suposición “optimista” de que los retransmisores actuarán honestamente y solo harán afirmaciones válidas sobre los estados entre cadenas.

Pero, por supuesto, esperamos que uno o dos (o más) repetidores se vuelvan infieles, por lo que los sistemas verificados de manera optimista requieren que los repetidores publiquen una pequeña fianza antes de enviar pruebas de estado. La ejecución de transacciones (aquellas que hacen referencia a estados de cadena cruzada informados por un repetidor) también se retrasa para dar a cualquiera que esté observando el sistema tiempo suficiente para disputar reclamos inválidos dentro del período de impugnación . Si el reclamo de un repetidor resulta ser inválido, la fianza publicada se reduce y una parte de ella se destina al retador.

La verificación optimista convierte el problema de tener que confiar en una pluralidad ( k de n ) o mayoría ( m de n ) de verificadores en el problema de confiar en que un verificador ( 1 de n ) actúe honestamente. Para que los protocolos verificados de manera optimista sigan siendo seguros, basta con que haya un actor que tenga suficientes datos de estado para volver a ejecutar transacciones y crear pruebas de fraude para desafiar las transacciones fraudulentas dentro del período de demora (de ahí el supuesto de seguridad 1 of n ).

Esto reduce los gastos generales, ya que el sistema puede funcionar correctamente con un único retransmisor (aunque podríamos necesitar dos o más para garantizar su actividad). También reduce la cantidad de participación necesaria para la seguridad y fomenta la configuración de un tiempo de desvinculación de la participación más rápido (la garantía vinculada se puede retirar una vez transcurrido el período de demora).

Además, los protocolos de interoperabilidad basados en la verificación optimista se describen como “hereditarios de la seguridad de la cadena de bloques subyacente”; esto se basa en la idea de que si la cadena de bloques subyacente está activa y no censura las pruebas de fraude, un retransmisor malicioso no puede salirse con la suya con un comportamiento deshonesto. Más aún, atacar el protocolo requeriría atacar la propia cadena de bloques, ya que censurar las transacciones durante un período prolongado requiere controlar una mayoría de nodos (y, por extensión, el poder de participación/minería) en la red.

Pero incluso la verificación optimista tiene desventajas particulares. Por ejemplo, imponer un retraso en la finalización y ejecución de transacciones de enlace o solicitudes de mensajes aumenta la latencia y degrada la experiencia general del usuario. Este tipo de seguridad entre cadenas también tiene varios “trucos” sutiles con implicaciones para la seguridad, como la posibilidad de que una parte maliciosa cuestione transacciones válidas para “molestar” a los retransmisores honestos y ejecutar un tipo de ataque DDoS.

Dado que las pruebas de fraude son (en su mayoría) interactivas por naturaleza, un desafío inválido haría que los retransmisores honestos desperdiciaran recursos, incluidos los fondos gastados en tarifas de gas para transacciones dentro de la cadena. En consecuencia, los retransmisores honestos pueden perder el incentivo para retransmitir información entre cadenas, lo que potencialmente deja una oportunidad para que los retransmisores deshonestos retransmitan información entre cadenas. Exigir a los retadores que publiquen un depósito mínimo podría disuadir el duelo, pero un depósito mínimo alto podría desanimar a los observadores honestos (que carecen de capital) de desafiar las actualizaciones de estado inválidas.

Algunos protocolos resuelven este problema restringiendo los desafíos a un conjunto autorizado de observadores, pero eso nos lleva de nuevo al problema original de tener un pequeño conjunto de participantes (de confianza) para proteger un sistema. Este enfoque también puede producir varias consecuencias no deseadas, como reducir la barrera a la colusión entre los nodos observadores y mejorar las posibilidades de un atacante de corromper la mayoría de los nodos que vigilan el sistema.

Verificación criptográfica

El último enfoque para asegurar los protocolos de interoperabilidad entre cadenas que analizaremos proviene del ámbito de las pruebas criptográficas. La idea es simple: en lugar de confiar en que la gente verifique los estados entre cadenas (algo que, como hemos demostrado en secciones anteriores, puede ser peligroso en ciertos casos), podemos utilizar mecanismos de verificación criptográfica, reduciendo al mínimo los supuestos de confianza.

Aquí, uno o más actores generan pruebas SNARK (Argumento de conocimiento sucinto y no interactivo) del estado (válido) de una cadena para su uso dentro de una aplicación de interoperabilidad. Estas pruebas son verificables : podemos tomar una prueba criptográfica de un estado de cadena cruzada, como una derivada de un encabezado de bloque, y confirmar su validez. También son no interactivas : una prueba generada por una sola parte puede ser verificada por n partes diferentes sin que nadie se comunique (a diferencia de las pruebas de fraude interactivas). Los protocolos de interoperabilidad diseñados de esta manera a menudo tienen los supuestos de confianza más bajos, en la medida en que el sistema de prueba subyacente sea sólido (es decir, un adversario no puede crear pruebas válidas para reclamos inválidos, excepto por una probabilidad insignificante).

Estos protocolos también son diferentes de los sistemas verificados externamente, especialmente cuando las pruebas criptográficas verifican que cada bloque es correcto según el protocolo de consenso de una cadena. Por lo tanto, un adversario necesitaría controlar una supermayoría del conjunto de validadores de la cadena de origen (necesario para finalizar los bloques no válidos) para corromper un protocolo de interoperabilidad utilizando pruebas criptográficas del estado entre cadenas.

También es fácil ver cómo este enfoque elimina algunos de los inconvenientes asociados con algunos mecanismos de seguridad entre cadenas discutidos anteriormente:

1. Ineficiencia de capital cero : el uso de zkSNARKs para verificar estados entre cadenas elimina la necesidad de un mecanismo de participación/vinculación y la ineficiencia asociada de someter los tokens a un período de bloqueo. De manera similar, los retransmisores no necesitan emitir una fianza (a diferencia de la verificación optimista) antes de hacer afirmaciones sobre transacciones entre cadenas, ya que la prueba que acompaña verifica sucintamente la afirmación.
2. Baja latencia : sin la necesidad de implementar un período de demora (para permitir pruebas de fraude oportunas), un protocolo de interoperabilidad puede ejecutar un mensaje entre cadenas o una operación de enlace una vez que se verifica una prueba SNARK que lo asegura. Dicho esto, la generación de pruebas suele requerir un uso intensivo de recursos computacionales, por lo que un sistema verificado externamente puede ser más eficiente en comparación con un protocolo de interoperabilidad basado en SNARK.

Al evaluar la seguridad de una solución de interoperabilidad “verificada criptográficamente”, es importante observar de cerca qué información sobre los estados entre cadenas se está probando y verificando realmente. Las pruebas de conocimiento cero se han convertido en una palabra de moda a la que se han aferrado muchos protocolos para ocultar los supuestos de confianza reales que subyacen a sus protocolos.

Por ejemplo, debido a que verificar todas las firmas en el conjunto de validadores de Ethereum ( más de 925.000 validadores según las cifras actuales ) en un circuito zkSNARK puede ser costoso, algunos protocolos han adoptado históricamente otros medios para derivar pruebas del estado de Ethereum. Un ejemplo es un puente “ Ethereum to X ” (donde X puede ser cualquier blockchain) que genera una prueba de que los encabezados de bloque fueron firmados por una mayoría del Comité de Sincronización de Ethereum (que presentamos anteriormente).

Este es un enfoque más factible (en comparación con la verificación de claves públicas de miles de validadores que dieron fe de un bloque). Pero, como se explicó anteriormente, los validadores del Comité de sincronización no son castigados por aprobar encabezados de bloque incorrectos, lo que deja una probabilidad nada despreciable de que una mayoría de los miembros del Comité de sincronización puedan coludirse o ser sobornados para engañar a los clientes ligeros y poner en peligro la seguridad de los puentes/protocolos de mensajería que dependen del Comité de sincronización para obtener información.

Además, como se explica en el artículo original que presenta los Comités Estatales de Lagrange , explicamos que, en un mundo ideal en el que los Comités de Sincronización maliciosos fueran pasibles de recortes, la seguridad económica se limitaría a la cantidad máxima que se puede recortar. A continuación, se incluyen algunos extractos de esa publicación para dar contexto:

La seguridad de los puentes de clientes ligeros, los puentes ZK y las pruebas del comité de sincronización se basan en la verificación de firmas del comité de sincronización de clientes ligeros de Ethereum. Como el tamaño del comité de sincronización es fijo, la seguridad económica que lo sustenta también está limitada durante un período de 27 horas. Una vez que se implemente el recorte para los comités de sincronización de Ethereum, la seguridad económica estará limitada de la siguiente manera:

• Seguridad económica del Comité de Sincronización = 512 nodos * 32 Eth * $1650 USD/ETH = $27,033,600
• Umbral para comprometer al Comité de Sincronización = $27,033,600 * 2/3 = $18,022,400

Si bien los puentes de clientes ligeros y los puentes de clientes ligeros ZK se consideran un estándar de oro para la interoperabilidad entre cadenas, la cantidad de activos que pueden proteger con comités de sincronización aleatorios es muy limitada. Como se mostró anteriormente, la cantidad de garantía que los nodos en connivencia tendrían que quemar para comprometer simultáneamente todos los puentes de clientes ligeros de Ethereum y ZK está limitada a $18 millones.

Considere una situación en la que la suma del valor de todos los activos asegurados por todos los puentes de clientes ligeros y clientes ligeros ZK es de una cantidad k. Cuando k < $18 millones, todos los activos asegurados a través de los puentes están seguros, ya que un ataque no es económicamente viable. A medida que k crece de manera tal que k > $27 millones, se vuelve rentable para un grupo de actores maliciosos en el comité de sincronización dar fe de los bloqueos maliciosos para comprometer los activos asegurados.

Le recomendamos leer el artículo completo, en particular la sección sobre las limitaciones de los puentes de clientes ligeros de Ethereum, para obtener más contexto sobre los problemas relacionados con la dependencia de comités de sincronización aleatorios para derivar pruebas de estados entre cadenas. También le sugerimos que siga los esfuerzos de Polyhedra Network para probar el consenso PoS completo de Ethereum en un circuito ZK .

Comités estatales de Lagrange: seguridad compartida como servicio para protocolos de comunicación entre cadenas

Dado que gran parte de la introducción de este artículo se centra en la seguridad compartida, es apropiado que presentemos una solución de seguridad compartida en la que hemos estado trabajando en Lagrange Labs: Lagrange State Committees . En esta sección, exploraremos el funcionamiento interno de la red de Lagrange State Committee y comprenderemos su conexión con la pila de Big Data ZK de Lagrange y el objetivo de crear herramientas para permitir un acceso seguro y expresivo al estado en cadenas y entre cadenas.

¿Qué son los Comités Estatales de Lagrange?

La red del Comité Estatal de Lagrange (LSC) es un protocolo de cliente ligero ZK simple y eficiente para acumulaciones optimistas (ORU) que se establecen en Ethereum (por ejemplo, Optimism, Arbitrum, Base y Mantle). Los LSC son conceptualmente similares al Comité de Sincronización de Ethereum y admiten aplicaciones basadas en clientes ligeros (como puentes y capas de mensajes entre cadenas) que desean utilizar el estado de una acumulación optimista sin asumir suposiciones excesivas de confianza.

Un Comité Estatal de Lagrange es un grupo de nodos de clientes que han vuelto a depositar 32 ETH en garantías en Ethereum a través de EigenLayer. En otras palabras, una red de Comité Estatal de Lagrange es un AVS o Servicio Validado Activamente . Cada Comité Estatal de Lagrange da fe de la finalidad de los bloques para un determinado paquete optimista una vez que los lotes de transacciones asociados se finalizan en una capa de disponibilidad de datos (DA). Estas certificaciones se utilizan luego para generar pruebas de estado, que las aplicaciones pueden tratar como una fuente de verdad para el estado de ese paquete optimista en particular.

Si bien el Comité de sincronización de Ethereum está limitado a 512 nodos, cada red del Comité estatal de Lagrange admite un conjunto ilimitado de nodos. Esto garantiza que la seguridad económica no esté limitada artificialmente y que la cantidad de nodos que atestiguan el estado de una acumulación optimista pueda escalar, lo que aumenta dinámicamente la seguridad económica detrás de las pruebas del estado de Lagrange.

¿Cómo funciona la red del Comité Estatal de Lagrange?

Dos componentes clave del protocolo del Comité Estatal de Lagrange son el secuenciador y los nodos cliente (los “nodos cliente” son otro nombre para los validadores registrados en un Comité Estatal de Lagrange). El secuenciador es una entidad central responsable de coordinar las certificaciones en una red del Comité Estatal de Lagrange y de entregar las certificaciones a los probadores que producen pruebas estatales. El nodo secuenciador es en realidad una combinación de tres módulos con diferentes funciones: Sequencer , Consensus y Governance .

A intervalos específicos, el módulo Sequencer solicita a los nodos cliente certificaciones para acumular bloques resultantes de la ejecución de un lote de transacciones que se escribieron en una capa DA. En lugar de ejecutar esta rutina para cada bloque de acumulación optimista, a continuación se muestra un breve análisis de cada elemento del mensaje de bloque:

(1). Block_header : Un encabezado de un bloque de acumulación optimista (ORU) finalizado. “Finalidad” aquí significa un bloque derivado por nodos de acumulación a partir de datos de transacción finalizados en una capa DA dada. Por ejemplo, la finalidad se define por el encabezado L2 seguro para acumulaciones de pila Optimism/OP y un bloque L2 con finalidad equivalente a Ethereum para cadenas Arbitrum y Arbitrum Orbit. (Obtenga más información sobre la finalidad de la acumulación en este artículo ).

(2). current_committee : Un compromiso criptográfico con el conjunto de claves públicas asociadas con los nodos de cliente autorizados para firmar un bloque b. Se espera que un nodo de cliente construya un árbol de Merkle, con hojas que representan las claves públicas de todos los miembros activos del comité, y firme la raíz del árbol de Merkle con su clave BLS12–381.

(3) next_committee : Compromiso criptográfico con el conjunto de claves públicas asociadas a los nodos autorizados a firmar el siguiente bloque (b+1). Los nodos que deseen abandonar un comité estatal deben enviar una transacción al final del período de certificación al contrato Lagrange Service en Ethereum que maneja el registro y la cancelación del registro de operadores en el Comité Estatal AVS.

Al final de cada período de certificación, el conjunto de nodos del comité puede modificarse si los operadores solicitan abandonar o unirse antes de que comience el siguiente período de certificación. Se espera que los nodos del cliente construyan un árbol Merkle del next_committee recuperando el conjunto actual de nodos registrados en cada comité del contrato de servicio de Lagrange.

ELI5: ¿Qué son las pruebas de estado?

Una prueba de estado es una prueba criptográfica del estado de una cadena de bloques: una prueba de un encabezado de bloque de una cadena de origen (cadena A), que se puede utilizar para demostrar a la cadena de destino la existencia de un estado en la cadena de origen, como una transacción particular. En otras palabras, una prueba de estado representa una prueba del estado de la cadena de origen a una altura de bloque específica.

Para ilustrar esto con un ejemplo anterior: el encabezado de bloque de la cadena de origen (cadena A), que la aplicación de Bob en la cadena de destino (cadena B) utiliza para verificar la existencia de la transacción puente de Alice, es una prueba de estado. Representa un resumen de las modificaciones del estado de la cadena de origen entre el bloque anterior y el bloque actual. Si la prueba de Merkle de Alice se verifica con la raíz del árbol de transacciones almacenada en el encabezado de bloque de la cadena A, Bob puede aprobar con confianza la transacción puente en la cadena B (la cadena de destino), ya que la prueba de estado da fe de la ejecución de la solicitud de mensaje de Alice en la cadena de origen.

La red del Comité Estatal de Lagrange está diseñada para generar pruebas de estado para acumulaciones optimistas aseguradas por Ethereum. Las pruebas de estado se generan agregando firmas BL12–381 en la tupla descrita anteriormente ( block_header , prev_committee y next_committee ) de al menos dos tercios de los nodos del comité estatal. Luego, la prueba de estado se genera mediante un circuito SNARK basado en el peso colectivo de las firmas que dan fe de un encabezado de bloque determinado.

El enfoque de exigir a los certificadores que se comprometan con los comités de estado actuales y próximos es similar al protocolo del Comité de sincronización de Ethereum y logra un objetivo similar: permitir que los clientes ligeros verifiquen la validez de un encabezado de bloque de acumulación optimista de manera eficiente y segura. Cada prueba de estado está vinculada criptográficamente por una serie de compromisos next_committee que indican qué nodos deben firmar el siguiente bloque. Por lo tanto, es suficiente verificar una prueba SNARK que demuestre las siguientes propiedades recursivas en el objeto de bloque firmado por los nodos que realizan la certificación:

• Al menos ⅔ de los n nodos del comité estatal firmaron el encabezado del bloque b.

• El current_committee del bloque b es igual al árbol next_committee del bloque b-1.

• El bloque b-1 es el bloque génesis o es válido con respecto a estas tres condiciones.

  
  

Los protocolos de interoperabilidad y otras aplicaciones que requieren un estado de acumulación optimista seguro con una finalidad rápida (por ejemplo, puentes entre cadenas y protocolos de mensajería) pueden utilizar pruebas de estado de los Comités Estatales de Lagrange con suposiciones de confianza mínimas. Es importante destacar que la red del Comité Estatal de Lagrange puede garantizar la seguridad de las pruebas de estado mediante la implementación de la eliminación determinista de los certificadores maliciosos y las pruebas de validez inductiva .

¿Cómo interactúa la red del Comité Estatal de Lagrange con ZK Big Data Stack?

En la primera publicación de la serie sobre la suite de productos de Lagrange, destacamos la relación entre las diferentes partes de la pila de big data de ZK : los comités de estado de Lagrange, Recproofs, zkMapReduce y el coprocesador de Lagrange. Cada uno de estos componentes, cuando se combinan, brindan en conjunto un acceso seguro y eficiente a los datos de estado y un cálculo expresivo y dinámico sobre los datos de estado:

#1. La red del Comité Estatal de Lagrange se integra con los demás componentes de ZK Big Data Stack para lograr un mejor rendimiento

Utilizamos Recproofs y zkMapReduce para crear pruebas de clave pública agregada (APK) actualizables para los comités estatales, lo que nos permite evitar el costoso y lento proceso de desagregar y volver a agregar claves públicas de no firmantes cada vez que se debe crear una nueva firma agregada.

La agregación eficiente de claves públicas BLS de operadores en el AVS de los Comités Estatales de Lagrange facilita mayores tasas de participación en el AVS sin aumentar el costo computacional de verificar las certificaciones de los nodos de los comités estatales. Es por eso que los Comités Estatales de Lagrange pueden admitir un conjunto potencialmente ilimitado de nodos y exhibir seguridad superlineal a medida que se agrupa más capital en los comités estatales. Puede obtener más información sobre esta propiedad en nuestra publicación sobre cómo escalar la confianza programable en EigenLayer con ZK Big Data .

La integración de los comités estatales de Lagrange con la pila de big data de ZK también tiene beneficios más directos para las aplicaciones de cliente que aprovechan las pruebas de estado de Lagrange. Por ejemplo, podemos usar la función zkMapReduce del coprocesador de Lagrange para combinar múltiples pruebas de estado de n cadenas de acumulación optimista en una única prueba de estado de múltiples cadenas . Esto permite una "verificación anidada", donde una única transacción en cadena verifica simultáneamente el estado de múltiples acumulaciones optimistas y reduce los costos de verificación para los servicios de cliente.

#2: El coprocesador Lagrange se integra con la red del Comité Estatal de Lagrange para impulsar la computación fuera de la cadena sin confianza

El coprocesador Lagrange, que analizaremos en profundidad en una publicación posterior, permite realizar cálculos baratos y escalables sobre datos en cadena al realizar cálculos fuera de la cadena. Los protocolos de interoperabilidad entre cadenas que se integran con los Comités Estatales de Lagrange también pueden integrarse con el coprocesador Lagrange para facilitar la expansión de sus ofertas entre cadenas a fin de incluir cálculos verificables.

Por ejemplo, un desarrollador que crea una aplicación de préstamos multicadena puede querer calcular la suma de las garantías depositadas por un usuario en n acumulaciones diferentes. Nuestro amigable desarrollador puede aprovechar el coprocesador Lagrange para calcular este valor, utilizando cualquier fuente de encabezado de bloque en la que ya se base el protocolo multicadena.

Por qué la red de Comités Estatales de Lagrange es un elemento innovador para la interoperabilidad en los planes de acción optimistas

Seguridad superlineal compartida para clientes optimistas de rollup light

Actualmente, los protocolos de interoperabilidad que admiten la conexión entre cadenas de rollup optimistas son responsables de verificar el estado de las cadenas de origen de forma independiente. La seguridad de estos protocolos de interoperabilidad depende del mecanismo para verificar que un encabezado de bloque sea correcto.

Algunos protocolos de comunicación entre cadenas intentan reducir los supuestos de confianza implementando el staking nativo y solicitando a un conjunto de verificadores que vinculen la garantía antes de dar fe de los encabezados de bloque de las cadenas de origen. Sin embargo, esto fragmenta la seguridad económica entre diferentes protocolos entre cadenas, ya que el costo de corromper un subconjunto ( k de n ) del conjunto de validadores de cada protocolo es menor.

Por el contrario, los comités de estado de Lagrange permiten que varios protocolos de cadena cruzada obtengan seguridad de un único conjunto dinámico de validadores que pueden escalar a un tamaño ilimitado. Esto cambia el status quo (donde cada protocolo de interoperabilidad es responsable de manera independiente de verificar la precisión de los estados de cadena cruzada) a uno donde múltiples aplicaciones pueden consumir el estado de cadena cruzada de una única fuente.

A diferencia de otros protocolos de clientes ligeros, la red del Comité Estatal de Lagrange admite un conjunto dinámico e ilimitado de nodos de certificación. Por lo tanto, el peso económico de las firmas que protegen cada certificación puede escalar dinámicamente a medida que se acumulan más participaciones en los comités estatales, lo que permite un aumento superlineal de la seguridad y aumenta la dificultad de atacar protocolos integrados entre cadenas de forma aislada.

Esto convierte al Comité Estatal de Lagrange en una "zona de seguridad compartida" a la que cualquier protocolo de cadena cruzada (independientemente de su tamaño) puede conectarse para lograr la máxima seguridad, de manera similar a cómo la Relay Chain en Polkadot y Cosmos Hub en Cosmos protegen las redes secundarias en el ecosistema de múltiples cadenas. Además, la integración con el middleware de resttaking de EigenLayer permite que la red del Comité Estatal de Lagrange extienda la seguridad económica de Ethereum para proteger una cantidad arbitraria de protocolos de comunicación de cadena cruzada descendentes.

Reducción de gastos generales para equipos de desarrollo de productos de cadena cruzada

En la actualidad, un desarrollador que crea un protocolo de interoperabilidad entre cadenas debe desarrollar una infraestructura para ejecutar observadores de forma independiente a fin de verificar el estado de cada paquete optimista que respaldan. A medida que aumenta la cantidad de paquetes optimistas integrados, aumenta la sobrecarga de infraestructura para administrar la seguridad en cada cadena de origen.

La integración con el Comité Estatal de Lagrange permite al desarrollador externalizar su seguridad y, en cambio, concentrar los recursos en optimizar las características de su producto. Para poner esto en contexto: cada prueba de estado de Lagrange es lo suficientemente liviana como para ser verificada de manera eficiente en cualquier cadena compatible con EVM.

Seguridad adicional para los protocolos de interoperabilidad existentes

Las pruebas de estado de Lagrange son independientes de la capa de transporte utilizada para transportarlas a una o más cadenas de destino, lo que permite que las aplicaciones de interoperabilidad apilen sin problemas las pruebas de estado de Lagrange con los mecanismos de seguridad existentes. Por ejemplo, un oráculo de cadena cruzada o un protocolo de mensajería de cadena cruzada con un conjunto de verificadores independientes puede verificar una prueba de estado de Lagrange como una medida de seguridad adicional antes de retransmitir solicitudes de mensajes de cadena cruzada desde acumulaciones optimistas.

Además, un protocolo de interoperabilidad existente, una vez integrado con la red del Comité Estatal de Lagrange, puede agregar soporte para acumulaciones optimistas sin requerir que los validadores aumenten la cantidad de cadenas que monitorean. Al usar pruebas de estado de la red del Comité Estatal de Lagrange, los validadores solo tienen que retransmitir solicitudes de mensajes entre acumulaciones. Un contrato de puerta de enlace en la cadena de destino puede entonces validar la existencia de mensajes transmitidos por los retransmisores verificando una prueba de estado de Lagrange.

¿Cómo se compara la red del Comité Estatal de Lagrange con otros mecanismos de seguridad entre cadenas?

Los comités estatales de Lagrange se comparan favorablemente con la infraestructura de interoperabilidad existente que utiliza mecanismos de participación/reducción de bonos, validación autorizada y verificación optimista (entre otros) para mejorar la seguridad de las pruebas de estado entre cadenas. A continuación, se muestran algunas comparaciones:

Verificación externa mediante validadores sin permiso

El modelo de resttaking de Lagrange mitiga un problema clave en los mecanismos de seguridad entre cadenas que implementan staking PoS puro para seguridad: la acumulación de riesgos . Tomemos, por ejemplo, un protocolo entre cadenas que requiere que los validadores compren y bloqueen el token nativo de un protocolo durante el período de vinculación. A medida que cambia la popularidad del token nativo del protocolo entre cadenas, la volatilidad del precio del activo afecta la seguridad económica total de la red.

La volatilidad de los precios es un problema menor para la red del Comité Estatal de Lagrange, ya que la seguridad de los nodos del comité se basa en garantías reestructuradas a través de EigenLayer. Además, las garantías reestructuradas han reducido los costos de oportunidad para los posibles validadores, lo que significa una mayor participación en los comités estatales y un mayor nivel de seguridad económica para los protocolos de interoperabilidad. Para los usuarios, esto significa tarifas más bajas y más seguridad en comparación con los protocolos de interoperabilidad que impulsan su seguridad de forma independiente.

También observamos que los protocolos de consenso utilizados en la Prueba de Participación tradicional imponen limitaciones en el número de validadores (por ejemplo, Tendermint BFT limita la participación a 100-200 validadores) e impiden que los protocolos PoS tradicionales escalen la seguridad económica con la frecuencia necesaria. Por el contrario, la red del Comité Estatal de Lagrange utiliza un mecanismo de certificación que admite un conjunto potencialmente ilimitado de nodos que participan en el consenso. Esto garantiza que la red pueda aumentar dinámicamente el número de certificadores y, por extensión, brindar garantías más sólidas de seguridad económica para las aplicaciones del cliente.

Verificación externa por validadores autorizados

Los protocolos de cadena cruzada basados en Proof-of-Authority (PoA) dependen de las certificaciones para bloquear los encabezados de un pequeño conjunto de nodos autorizados. Estos enfoques han demostrado ser inseguros históricamente con incidentes de alto perfil, incluido el ataque a Ronin (5 de los 7 validadores comprometidos) y el ataque al puente Harmony One (2 de los 5 validadores comprometidos).

El uso de un sistema de validación sin permiso como la red del Comité Estatal de Lagrange reduce un poco la eficiencia en comparación con un operador centralizado o un conjunto de validadores que firman encabezados. Pero dada la cantidad de riesgo, consideramos que es una compensación sensata. Los sistemas de validación sin permiso también reducen la superficie de ataque para las empresas que, en la mayoría de los casos, pueden terminar ejecutando una mayoría de validadores en un sistema con permiso.

Puente canónico

La red del Comité Estatal de Lagrange elimina la latencia del envío de mensajes entre cadenas desde acumulaciones optimistas. Cada LSC actúa como un "modo rápido" para puentes y protocolos de mensajería cuyos usuarios desean realizar puentes desde una acumulación optimista sin esperar a que se agote la ventana de desafío. Las acumulaciones optimistas también se benefician directamente de la propiedad de finalidad rápida de LSC, ya que resuelve un problema clave de la experiencia de usuario para los usuarios de L2.

Esta garantía se deriva de la observación de que: (a) el mecanismo de corte está diseñado para aumentar el costo de las acciones adversas, y (b) el corte de nodos coludidos en una LSC puede ocurrir en la cadena en modo lento , ya que hay un retraso de tiempo variable en el retiro de la participación. En resumen, los participantes en una LSC siempre tienen el incentivo de dar fe de los estados correctos entre cadenas, lo que permite que las aplicaciones entre cadenas utilicen pruebas de estado de una LSC de inmediato y con suposiciones de confianza mínimas respaldadas por el puente canónico del rollup.

Conclusión

Este artículo ha abarcado muchos temas y esperamos que su lectura haya sido educativa (y valiosa) para los desarrolladores, inversores, entusiastas y usuarios del ámbito de la interoperabilidad. A lo largo de este artículo, hemos explorado la definición de seguridad compartida, lo que significa para el diseño de protocolos seguros y cómo la interoperabilidad entre cadenas puede beneficiarse de la integración con una infraestructura de seguridad compartida.

También hemos explorado los Comités Estatales de Lagrange: nuestra solución de seguridad como servicio compartida diseñada teniendo en cuenta los protocolos de comunicación entre cadenas. Los Comités Estatales de Lagrange son parte de nuestra visión de permitir una interoperabilidad segura, eficiente y con confianza minimizada, y serán parte de una pila más grande que permitirá a los desarrolladores crear potentes aplicaciones entre cadenas para los usuarios.

El futuro de las cadenas múltiples es inevitable y es importante que los usuarios puedan pasar de usar una cadena a miles de cadenas sin experimentar una pérdida significativa de seguridad. Soluciones como los Comités Estatales de Lagrange (junto con otros avances en seguridad entre cadenas) son fundamentales para este objetivo. Con la interoperabilidad recibiendo más atención que nunca, un mundo donde moverse entre cadenas sea seguro y eficiente está muy al alcance de los usuarios de criptomonedas de todo el mundo.

Expresiones de gratitud

Emmanuel Awosika ( 2077 Research ), Omar Yehia ( Lagrange Labs ), Ismael Hishon-Rezaizadeh ( Lagrange Labs ) y Amir Rezaizadeh ( Lagrange Labs ) contribuyeron a este artículo. Emmanuel fue contratado por Lagrange Labs para ayudar a redactar este artículo.

Una versión de este artículo fue publicada previamente aquí .