Lea más sobre ¿Por qué los Rollups necesitan un comité de seguridad?

AUTOR ORIGINAL: PATRICK MCCORRY

Compilación original: Luffy, Foresight News

Cualquier base de datos que interactúe con criptoactivos algún día elegirá Rollup como pila tecnológica. Hay una serie de buenas razones para que los desarrolladores tomen una decisión de este tipo:

• Auditoría en tiempo real
• Certificado de solvencia por defecto
• El depósito en garantía de los fondos de los usuarios es opcional
• Un participante honesto protege todo el sistema

Lo más importante es que todos los esfuerzos de diseño e implementación de Rollup se centran en proteger a los usuarios, sus fondos y todas sus interacciones de operadores de sistemas potencialmente desconocidos y poderosos.

Incluso si todo el sistema está fuera de línea, los usuarios pueden recuperar sus fondos por su cuenta.

Si los Rollups se pueden implementar ampliamente como una pila tecnológica, entonces podemos tener la capacidad de romper las barreras de confianza y permitir interacciones financieras para cualquier persona en la comunidad global, lo que conducirá a una nueva era de comercio electrónico global, contratación remota y prestación de servicios sin fricciones.

Se necesita mucho esfuerzo para que un rollup funcione correctamente.

¿Qué pasa con las multifirmas?

Eso suena bien, pero todo el sistema está controlado en última instancia por multisig. Si el firmante está comprometido o es malicioso, puede robar fácilmente todos los fondos.

Entonces, ¿a quién le importan los Rollups? en algún lugar de CT.

Es cierto que todos los rollups actuales tienen multifirma y tienen derecho a actualizar el contrato inteligente subyacente, pero como veremos, es un mecanismo conservador que protege los fondos de los usuarios y forma parte de una arquitectura de sistema más amplia.

Responsabilidades del Comité de Seguridad

Multisig es un término técnico que se refiere a un sistema que requiere que varios firmantes autoricen una acción. Por ejemplo, K de los N firmantes completan la firma digital para que se permita la transacción.

En el contexto de los rollups, a menudo se hace referencia a la multifirma como un comité de seguridad, donde los firmantes tienen el poder de actualizar todos los contratos inteligentes relacionados.

Echemos un vistazo al Consejo de Seguridad en Arbitrum (ya que lo conozco muy bien) para tener una idea de los tipos de responsabilidades que puede tener esta organización:

*Veto. Si el Comité de Seguridad cree que una propuesta aprobada por la DAO de Arbitrum viola los estatutos de Arbitrum y puede dañar el ecosistema de Arbitrum, puede cancelar la propuesta. Por ejemplo, cancele una propuesta que se aprobó debido a un ataque de gobernanza. *Mantenimiento. Actualice el conjunto de contratos inteligentes de Arbitrum para realizar cambios menores que sean menos impactantes y que no requieran la participación de Arbitrum DAO. *Emergencias. Responder rápidamente en caso de emergencia, y si creen que los fondos de los usuarios están en riesgo inminente, pueden actualizar urgentemente el contrato inteligente.

Por supuesto, lo más importante es que el primer deber del comité de seguridad es responder a las emergencias y actuar rápidamente para proteger los fondos de los usuarios.

Los miembros del comité de seguridad deben ser personas de mucha confianza.

Existe una confianza en los firmantes para poder reaccionar rápidamente, para poder actualizar el contrato inteligente en caso de una emergencia y para hacer todo lo posible para mantener seguros los fondos en el contrato inteligente.

Seleccione el umbral multifirma correcto

Hay dos factores importantes a tener en cuenta a la hora de decidir establecer un comité de seguridad:

• ¿Cuántos firmantes hay?
• ¿Cuál es el número mínimo de firmantes requerido para aprobar una acción?
• Esto puede parecer una pregunta trivial, después de todo, son solo dos números, pero hay un acto de equilibrio que debe considerarse:
• Brecha de seguridad: los miembros de K pueden confabularse para cambiar los contratos inteligentes y robar los fondos de los usuarios.
• Violación activa: Los miembros de N-K+ 1 se confabulan para evitar cualquier cambio en el contrato inteligente, especialmente si se encuentra una vulnerabilidad crítica.

El reto consiste en establecer un umbral que mantenga la seguridad de los fondos en tiempos de paz y actúe rápidamente en caso de emergencia cuando los fondos de los usuarios se vean amenazados.

Consideremos un ejemplo específico. Supongamos que el umbral se establece en 9/10, donde 9 firmantes deben firmar conjuntamente un mensaje. Se trata de un umbral de seguridad estricto, ya que 9 firmantes deben confabularse para robar los fondos. La desventaja, sin embargo, es que dos signatarios cualesquiera pueden bloquear cualquier acción en caso de emergencia. Por ejemplo, si dos signatarios viajan lejos en un vuelo transatlántico, el Comité de Seguridad no podrá cumplir con sus obligaciones.

Por supuesto, si el umbral de seguridad es bajo, digamos 2/10, entonces solo se necesita que dos firmantes se confabulen (o la clave privada se vea comprometida) para que se roben los fondos de los usuarios.

Es probable que la percepción de la integridad de una persona cambie con el tiempo

Elegir el umbral adecuado es más una cuestión social que técnica, y creo que es más un arte que una ciencia. La seguridad depende en gran medida de la integridad del firmante individual. Como veremos en breve, hay formas de reducir la confianza en la multifirma, pero esto conlleva una serie de compensaciones.

Miembro del Comité de Seguridad

El rollup principal actualiza instantáneamente el umbral multifirma requerido para todos los contratos inteligentes

La mayoría de los Rollups tienen un grupo de firmantes anónimos en sus comités de seguridad. Sospechamos que esto puede deberse a:

• La etapa de desarrollo del rollup,
• Para proteger la seguridad personal de los miembros,
• Creer que el anonimato es la mejor opción para proteger los fondos de los usuarios.
• Por otro lado, hay tres proyectos Rollup que han anunciado públicamente su pertenencia al comité de seguridad:
• Arbitrum: Los firmantes son elegidos públicamente, y la lista actual se puede ver en Tally. Solo tres firmantes están asociados con el proyecto Arbitrum (dos de Offchain Labs y uno de la Fundación Arbitrum).
• Base: 2/2 multisig, uno controlado por Base y el otro controlado por Optimismo.
• Polygon zkEVM: Aún no está implementado, pero han anunciado que actualizarán su multisig a 10/13, que incluye dos miembros de Polygon Labs y un consultor de Polygon Labs.
• zkSync Lite: zkSync Lite debe distinguirse de ZkSync Era, cuyo comité de seguridad se anuncia públicamente y no incluye afiliados directos del proyecto Rollup (a excepción de los inversores en zkSync).

En Arbitrum, y en el próximo Polygon, solo un puñado de signatarios están directamente asociados con el proyecto Rollup, y el número es lo suficientemente pequeño como para garantizar que los afiliados no puedan confabularse para bloquear las acciones tomadas por el Comité de Seguridad. En zkSync Lite, además de los inversores de zkSync, nombran firmantes que son independientes del proyecto.

En todos los casos, Rollup otorga un gran valor a los firmantes que no están directamente relacionados con el proyecto.

Sin embargo, parece haber una falta de consenso sobre lo que constituye una buena multifirma, lo que nos lleva a varios problemas de diseño:

• ¿Deberían permitirse miembros anónimos?
• ¿Los miembros deben ser de diferentes geografías?
• ¿Los miembros deben ser individuos o corporaciones?
• ¿Los miembros deben ser nombrados o elegidos?
• ¿Cuántos miembros de la misma empresa (o país) se deben permitir?
• ¿Existe un tamaño mínimo y un umbral que se considere adecuado?

La regla general debe ser elegir miembros con un alto grado de integridad para que el público tenga confianza en la seguridad del sistema. Al menos, creo que la mayoría de los proyectos probablemente lo hagan, incluso si esto no siempre es verificable públicamente.

P.D. Seis miembros del Comité de Seguridad de Arbitrum están actualmente pre-nombrados, pero serán reemplazados en las elecciones de marzo.

Debilitar los poderes de la Comisión

Hasta ahora, solo hemos considerado un comité que tiene el poder de actualizar el contrato inteligente de inmediato, pero hay formas de limitar los poderes del comité:

Retardo de tiempo. Todas las acciones autorizadas por la Comisión no se realizarán y surtirán efecto hasta que haya transcurrido el tiempo T.

Solo pausa. Todos los activos en poder del puente de cadena cruzada nativo pueden ser congelados por el comité. Esto puede suspender las siguientes funciones:

• Entregar el mensaje de L2 a L1 (es decir, retirar dinero),
• Completar la clasificación de las transacciones pendientes,
• Completar nuevos puntos de control/certificados,
• Aceptar nuevos datos acumulativos (es decir, transacciones pendientes).

Comisión de derivación (eliminada). Abandona el comité y confía en otro mecanismo de gobernanza, como una DAO, para aprobar la actualización.

Esto, por supuesto, limita la capacidad de la Comisión para actuar con rapidez y su capacidad para responder eficazmente a las emergencias que amenazan los fondos de los usuarios.

Si la vulnerabilidad se ha revelado al comité de forma privada, pero aún no ha sido explotada por los piratas informáticos, el comité de seguridad tiene la opción de actualizar el contrato inteligente y corregir el error. Agregar un retraso de tiempo a una actualización aumenta el riesgo de que un atacante investigue una actualización divulgada públicamente, encuentre una vulnerabilidad y, a continuación, la explote.

Por ejemplo, CVE-2018-17144 en el BTC se anunció inicialmente como una vulnerabilidad DDoS en un intento de ocultar una vulnerabilidad de inflación de tokens más grave. La velocidad de la actualización es fundamental para evitar que se explote.

Evaluar las defensas del mecanismo de solo pausa

Consideremos un escenario potencial para que un atacante aproveche activamente una vulnerabilidad:

• Mensajes maliciosos L2 → L1. Un atacante puede crear mensajes arbitrarios que se originen en un contrato inteligente en un rollup y reenviar el mensaje al contrato inteligente en el ETH a través de un puente nativo entre cadenas.
• Transiciones de estado no válidas. Un atacante puede ejecutar una transacción en un paquete acumulativo que infringe las reglas de la función de transición de estado y, por lo general, debe considerarse no válida.
• Lagunas legales en la retirada. Un atacante puede retirar fondos del puente nativo entre cadenas simplemente emitiendo una transacción en el ETH Fang (Capa 1).

En los tres casos, la demora solo le da al atacante más tiempo para continuar robando los fondos y reduce la ventana de oportunidad para que el comité defienda el sistema. La función de lapso de tiempo no protege contra ataques activos y solo se puede usar para mantenimiento de rutina y tareas no urgentes.

Solo evaluaremos la capacidad de pausar el sistema y la medida en que se puede suspender el sistema.

En el caso de mensajes maliciosos L2 → L1, la función de pausa puede mitigar el ataque sin interferir con las actividades comerciales. El comité debe suspender la mensajería y/o finalizar la funcionalidad de los nuevos puntos de control. Se argumenta que debe haber un retraso de tiempo antes de que se ejecute el mensaje L2 → L1 para que el comité tenga tiempo de detectar errores y reaccionar ante emergencias.

Defenderse contra transiciones de estado no válidas es más complicado porque la finalidad de la transacción tiene diferentes capas en los resúmenes. Si solo consideramos las transacciones acumuladas sin tener en cuenta los efectos secundarios, entonces la mejor defensa para el comité de seguridad sería detener la capacidad de finalización de los puntos de control, pero continuar permitiendo que se ordenen las transacciones. Esto da tiempo para corregir errores, reactivar la finalización del punto de control y simplemente ignorar las transacciones no válidas.

Sin embargo, si la actividad comercial en el Rollup no está desactivada, la experiencia del usuario será caótica y el Rollup puede parecer que está gravemente roto hasta que se actualice el software del cliente.

Esto nos lleva al siguiente escenario. ¿Cómo debería reaccionar el comité si consideramos cómo las transacciones no válidas en los rollups pueden afectar a otros sistemas? La mejor línea de defensa es congelar la capacidad del puente nativo entre cadenas para finalizar el orden de las transacciones o apagar el secuenciador por completo.

Esto se debe a que ciertos sistemas, como los puentes rápidos entre cadenas que transfieren fondos de un rollup a otro, pueden autorizar la transferencia de fondos una vez que creen que las transacciones del rollup (incluidas las transacciones no válidas) están ordenadas. En este ejemplo, puede permitir que un atacante explote un protocolo DeFi en un Rollup y luego transfiera fondos rápidamente transfiriéndolos a otro Rollup a través de un puente rápido entre cadenas.

En el momento en que la comisión corrige el incumplimiento y restablece la transacción no válida, es posible que el daño ya esté hecho. Los LP tanto en los protocolos DeFi como en los puentes entre cadenas pueden asumir el coste de un ataque.

Finalmente, si la vulnerabilidad permite a un atacante retirar fondos directamente del puente nativo entre cadenas, similar al Nomad Hack, el comité de seguridad puede ser impotente para detenerlo.

En última instancia, hay un problema general con el mecanismo de suspensión. Tenemos que asumir que existe un sistema de gobernanza más amplio que puede aprobar actualizaciones y reactivar paquetes acumulativos. Si asumimos que el sistema de gobernanza es una DAO con un sistema de votación en cadena que se ejecuta en Rollup, entonces surgen problemas de implementación complicados.

Por ejemplo, si el puente entre cadenas de mensajes L2→L1 está en pausa, los resultados de la votación de la DAO no se pueden pasar del rollup al puente de cadena cruzada nativo en el ETH, y debe haber una forma alternativa para que la DAO envíe la aprobación y realice la actualización.

Eliminación gradual del Consejo de Seguridad

Hay quienes en la comunidad creen que el comité de seguridad debería eliminarse gradualmente, pero en mi opinión, esto plantea dos problemas:

Falsa sensación de seguridad. Los atacantes que son conscientes del exploit esperan hasta que el comité de seguridad se elimine antes de ejecutar el ataque. Con el tiempo, esto puede erosionar nuestra confianza en la seguridad de nuestros sistemas.

Las opciones de recuperación son limitadas. Sin un comité de seguridad, la comunidad no puede defenderse de los atacantes. La única opción disponible es ejecutar un hackeo de sombrero blanco paralelo y, con suerte, recuperar algunos de los fondos.

En mi opinión, los comités de seguridad siempre serán necesarios, pero los poderes que se les otorgan deben reducirse gradualmente.

Con esto en mente, la pregunta de diseño debería ser:

¿Cómo podemos conseguir que el comité de seguridad suspenda el sistema con un impacto mínimo para los usuarios, al tiempo que permite que la comunidad en general participe en la decisión de cómo corregir errores y reactivar el sistema?

En otras palabras, necesitamos un programa que realmente permita a la comunidad intervenir y restaurar el sistema, y luego limitar el poder de suspensión del Consejo de Seguridad.

En el espacio de la cadena de bloques de capa 1, se puede llegar directamente a la comunidad mediante el uso de bifurcaciones activadas por el usuario, pero este método no funciona para contratos inteligentes en cuadrados ETH (como Rollups) porque no hay necesidad de bifurcar todo el ETH. En algunos casos, la comunidad ETH puede decidir colectivamente salvar el Rollup, como TheDAO en 2016, pero el Rollup nunca debe confiar ni esperar tal resultado.

Otra idea interesante en esta línea es implementar un ETH para que la Corte Suprema decida sobre las actualizaciones de contratos inteligentes y habilite bifurcaciones similares a la activación del usuario.

Como se mencionó anteriormente, si el Rollup delega su seguridad a la DAO, entonces debe haber una implementación que permita a la DAO votar directamente en el ETH. Esto es muy complicado, especialmente si el protocolo de votación existe en Rollup.

Por último, creo que es necesario realizar un examen exhaustivo de los tipos de situaciones que pueden requerir una respuesta del Consejo a fin de facilitar el debate en torno a su necesidad.

¿Por qué preocuparse por los rollups si tienes multisigs?

Hemos dedicado bastante tiempo a comprender las responsabilidades, el diseño y las necesidades del comité de seguridad, pero es importante volver a la pregunta original de este artículo:

¿Es Rollup solo una multifirma?

La respuesta es no.

Para ayudar a entender por qué, lo mejor es dar un paso atrás y entender lo que el sistema blockchain realmente quiere hacer.

Un protocolo de cadena de bloques es una herramienta que permite a los usuarios calcular una copia de una base de datos y estar seguros de que tienen la misma base de datos que todos los demás.

Con esto en mente, hay dos componentes en cualquier sistema blockchain:

• Protocolo Blockchain. La combinación de software, criptografía y sistemas distribuidos brinda confianza a cualquier persona en la integridad de una base de datos.
• Sistema de gobernanza. Un mecanismo de coordinación que permite que todas las partes interesadas trabajen juntas y acuerden cambios en el protocolo blockchain.

El objetivo de cualquier sistema de cadena de bloques, incluido Rollup, es garantizar que el protocolo de cadena de bloques siempre se ejecute con un tiempo de actividad extremadamente confiable del 99,9999%. Un operador de sistema de confianza debe tener poca o ninguna interferencia con el funcionamiento diario del sistema. En última instancia, son el software, la criptografía y los sistemas distribuidos los responsables en última instancia de proteger los saldos de los usuarios, el código de los contratos inteligentes y el estado.

A veces es necesario cambiar el protocolo blockchain para mejorar los intereses de los usuarios. Es posible que la comunidad desee solucionar problemas de configuración, agregar nuevas funciones o reaccionar a vulnerabilidades críticas que amenacen la integridad del sistema. Esto requiere intervención humana y solo se puede llamar el 0,0001% de las veces.

Los sistemas de gobernanza son responsables de implementar la intervención humana, y a lo largo de los años han surgido varios enfoques:

• Partidos políticos totalitarios: Los partidos unilaterales pueden decidir individualmente cómo mejorar el sistema (muchos proyectos, incluido BTC, comenzaron de esta manera).

• Consenso aproximado: La mayoría de los participantes dijeron que estaban listos para implementar la actualización, determinar el día de la marca y, a continuación, realizar la actualización el día de la marca (BTC/ETH).
• Acuerdo de votación: Todos los partidos participan en la elección y votan explícitamente sobre si aprueban o no la escalada.
• Sin interferencias: Los contratos inteligentes pueden ser inmutables y el sistema nunca se puede cambiar.

Además de lo anterior, la comunidad también puede decidir designar un comité de seguridad como una opción complementaria a la gobernanza para actuar rápidamente en caso de emergencia.

El Consejo de Seguridad no detiene el ataque. Se trata de un mecanismo pasivo que funciona junto con la gobernanza cuando se atacan los fondos de los usuarios de un protocolo blockchain o la fiabilidad/rendimiento del sistema.

Finalmente

Todas las discusiones en torno a los protocolos, la gobernanza y los comités de seguridad de blockchain son cruciales. La existencia de esta discusión es lo que hace que las criptomonedas sean tan especiales.

Este es un buen ejemplo de ingeniería de confianza: una disciplina de ingeniería que se centra en identificar, medir y reducir/eliminar elementos de confianza en un sistema.

En criptomonedas, nos enfocamos en construir sistemas que no solo protejan a los usuarios de poderosos operadores de sistemas, sino que también les permitan operar de manera confiable (segura) en las condiciones más adversas.

Es por eso que es saludable que los miembros de la comunidad sean escépticos sobre el papel del comité de seguridad, pero tienen la responsabilidad de encontrar mejores soluciones durante las emergencias para proteger los fondos de los usuarios de manera reactiva.

Espero que este artículo deje claro por qué los comités de seguridad son útiles, son necesarios hoy en día, pero son solo una pequeña parte de la arquitectura más amplia de los sistemas de contratos inteligentes.