Comparación de Seguridad Replicada, Opt-In y de Malla
https://medium.com/the-interchain-foundation/comparing-replicated-opt-in-and-mesh-security-a24d67e04b81
Comparación de Seguridad Replicada, Opt-In y de Malla
El Cosmos Hub está liderando el desarrollo de la seguridad compartida con el lanzamiento de la Seguridad Replicada. En nuestra reflexión actual, la Seguridad Replicada se sitúa junto a otras dos variedades principales de seguridad compartida: la Seguridad Opt-In y la Seguridad de Malla. En este artículo, exploraremos:
Cómo se comparan estas diferentes variedades de Seguridad Interchain entre sí.
Cómo está posicionado el Hub con respecto a la Seguridad de Malla.
Cómo el Hub debe aprovechar esta posición.
Y cómo el Hub puede llevar conceptos emocionantes de la Seguridad Opt-In a la Seguridad de Malla.
Seguridad Replicada
En la Seguridad Replicada, cada validador en el Hub (o casi todos los validadores) ejecuta una cadena de consumo. Esto proporciona garantías muy sólidas. Cada cadena de consumo de Seguridad Replicada tiene exactamente la misma seguridad que el Cosmos Hub. Dado que se requiere que cada validador ejecute cada cadena de consumo, cada cadena de consumo debe ser aprobada por la gobernanza del Cosmos Hub. Por otro lado, no necesitan reunir su propio conjunto de validadores. Dado que cada cadena de consumo comparte el mismo conjunto de validadores, deberían ser posibles características como IBC sincrónico. Esto podría permitir transacciones IBC instantáneas y características como préstamos flash entre cadenas de consumo de Seguridad Replicada. Actualmente, existen algunas preocupaciones de rendimiento en cuanto a la Seguridad Replicada. Debido a que Tendermint actualmente tiene un alto costo de rendimiento de alrededor de $600 al mes y cada cadena de consumo requiere que cada validador ejecute un nodo Tendermint por separado, cada cadena de consumo aprobada debe ser lo suficientemente rentable como para mantener este costo. A medida que mejora el rendimiento de Tendermint, esto se convertirá en menos problema.
Seguridad Opt-In permitirá a los validadores optar por ejecutar cadenas de consumo individualmente. Esto tiene dos beneficios principales. En primer lugar, si un validador no cree que una cadena de consumo sea rentable, no necesita ejecutarla. En segundo lugar, permite el lanzamiento sin permiso de cadenas de consumo sin una propuesta de gobernanza. Sin embargo, también tiene desventajas. La historia de seguridad no es tan simple como en la Seguridad Replicada. A medida que los validadores optan y optan, la seguridad de una cadena de consumo dada podría fluctuar de un día a otro. Además, las cadenas de consumo de Seguridad Opt-In (junto con las cadenas de consumo de Seguridad de Malla) son vulnerables a algo llamado "problema del subconjunto". Si bien todo el conjunto de validadores y delegadores del Hub puede considerarse seguro, cualquier subconjunto dado podría ser malicioso. En un ejemplo extremo, si solo un validador ha optado por participar, controlaría toda la cadena. El problema del subconjunto se puede mitigar utilizando pruebas de fraude que permiten que los validadores sean castigados en el Hub por producir bloques inválidos, pero el problema siempre existirá en cuanto a la disponibilidad. Un subconjunto malicioso del Hub que opte por una cadena de consumo siempre podrá detenerla sin ser castigado. La Seguridad Opt-In brilla realmente cuando se trata de lanzar cadenas de consumo. A diferencia de la Seguridad Replicada, no se requiere una propuesta de gobernanza. Y a diferencia de la Seguridad de Malla, las cadenas de consumo no necesitan su propio conjunto de validadores. Utilizando la Seguridad Opt-In en el Hub, las cadenas de consumo deberían poder atraer un nivel muy respetable de seguridad a su proyecto con una sola transacción sin permisos.
Seguridad de Malla
La Seguridad de Malla funciona de manera un poco diferente en el sentido de que permite a los delegadores delegar en validadores de otras cadenas. El conjunto de validadores del Cosmos Hub no estaría involucrado en absoluto en la ejecución de una cadena de consumo. Si un validador en otra cadena comete una violación de consenso, cualquiera que le haya delegado sufre una sanción. Este diseño permite que las cadenas aumenten la seguridad entre sí de manera bidireccional, por eso se llama Seguridad de Malla. Al igual que la Seguridad Opt-In, la Seguridad de Malla tiene el problema del subconjunto y, por lo tanto, necesita pruebas de fraude para funcionar de manera segura. A diferencia de la Seguridad Replicada y la Seguridad Opt-In, la Seguridad de Malla requiere que las cadenas de consumo tengan sus propios conjuntos de validadores. Esto hace que sea menos fácil de implementar para las nuevas cadenas que se lanzan, pero puede resultar más atractiva para las cadenas que ya tienen sus propios conjuntos de validadores.
La posición del Hub con respecto a la Seguridad de Malla Existe la idea errónea de que la Seguridad de Malla compite con el Hub. Nada podría estar más lejos de la verdad. El Hub está muy bien posicionado para participar en una malla de seguridad. Tiene una participación muy alta, por lo que cualquier cadena segura mediante una malla que agregue al Hub como proveedor de seguridad verá un gran aumento en su nivel total de seguridad. En un mundo de Seguridad de Malla, la posición predeterminada del Hub es de gran éxito. Sin embargo, hay dos cosas que deben ser ciertas para que este éxito se haga realidad.
Los usuarios deben tener información precisa sobre la seguridad En primer lugar, los usuarios deben tener información precisa sobre cuánta seguridad tienen realmente diferentes blockchains. Hasta ahora, no se ha prestado mucha atención a esto porque actualmente es trivial derivar la seguridad de una cadena de su participación total. Si una cadena tiene $100 millones en juego, entonces se necesitarán ~$66 millones (⅔+) para controlar la cadena y ~$33 millones (⅓+) para censurar transacciones o detener la cadena. Estos números son tan simples de derivar que la mayoría de las personas ni siquiera piensan en ellos. Sin embargo, con la Seguridad de Malla, no es tan simple. Un enfoque ingenuo sería simplemente sumar los tokens apostados de todas las cadenas que brindan seguridad a una cadena dada y considerar eso como la apuesta total. Pero esto no tiene en cuenta el poder de voto y no es preciso. Hemos creado un modelo matemático que tiene en cuenta todos los factores. Es importante que los exploradores de bloques y las carteras utilicen una métrica precisa para la seguridad, ya que eso permitirá a los usuarios evaluar con precisión el nivel de seguridad de las cadenas que utilizan seguridad de malla. Hemos creado un complemento de JavaScript que puede ser utilizado por carteras y exploradores de bloques, y se les debe animar a usarlo. Aquí tienes un ejemplo. Intenta eliminar al Hub como proveedor de Seguridad de Malla y observa cuánto disminuye la seguridad.
El Hub debe implementar la Seguridad de Malla En segundo lugar, y más importante aún, el Hub debe implementar efectivamente la Seguridad de Malla. Esto es obvio pero debe ser discutido. Actualmente, la Seguridad de Malla se está desarrollando como una aplicación CosmWasm. Actualmente, el Hub no ejecuta CosmWasm. Discutiré tres posibles soluciones.
Agregar CosmWasm al Hub
Esta es la solución más simple y fácil. Hacer esto hará que el Hub utilice la misma implementación de Seguridad de Malla exacta que todas las demás cadenas, y le permitirá adoptar mejoras de inmediato. Cabe señalar que existe un precedente de gobernanza que rechazó CosmWasm en el Hub, consulte la propuesta #69. Considerando el evento pasado, una nueva propuesta todavía podría encontrar resistencia dentro de la comunidad.
Desarrollar una implementación alternativa de Seguridad de Malla en Go
Esto sería un esfuerzo de ingeniería considerable y duplicaría gran parte del trabajo que ya se está realizando en la implementación de CosmWasm. El riesgo aquí es que la implementación en Go quede rezagada con respecto a la implementación principal de CosmWasm, poniendo al Hub en desventaja. Existe una pequeña posibilidad de que la implementación en Go se convierta en la implementación principal, pero tratar de luchar en lugar de aprovechar las ventajas del Hub parece ser una asignación inadecuada de esfuerzo. Tal vez otras cadenas que no ejecutan CosmWasm podrían usar esto también, pero eso no parece beneficiar al Hub en absoluto.
Ejecutar Seguridad de Malla en una cadena de consumo de Seguridad Replicada
Podría ser posible ejecutar Seguridad de Malla escrita en CosmWasm en una cadena de consumo de Seguridad Replicada que ejecute CosmWasm, sin que el Hub mismo necesite ejecutar CosmWasm. Esto requeriría algunos cambios en la Seguridad Replicada. Esta cadena de consumo debería ser una cadena de consumo de confianza. Debería tener la capacidad de recortar la participación de los delegados individuales enviando un paquete IBC, sin verificación adicional. Es posible construir esto en la Seguridad Replicada, pero es probable que requiera algunos cambios menores en el lado del consumidor para enviar un paquete de recorte en lugar de recortar directamente a los validadores. También existe la posibilidad de que a medida que evoluciona la Seguridad de Malla, esta cadena de consumo de confianza necesite cambios adicionales en la Seguridad Replicada, lo que agrega una sobrecarga adicional.
¿Cuál de estas opciones es la mejor? La opción 1 es simple y logra exactamente lo que necesitamos, aunque puede tener algunos problemas de gobernanza, y ejecutar CosmWasm en el Hub es en efecto una decisión importante, aunque en este punto ha sido probada exhaustivamente en producción.
La opción 3 es más complicada pero nos permite seguir utilizando la Seguridad de Malla principal con algunos cambios. Sin embargo, los cambios que se realicen en la Seguridad de Malla pueden requerir cambios en la Seguridad Replicada que ejecuta la cadena de consumo de Seguridad de Malla de confianza. Esto podría ser mucho más trabajo que la opción 1.
La opción 2 es con mucho la mayor cantidad de trabajo y conlleva el riesgo de que la implementación en Go del Hub quede rezagada con respecto a la Seguridad de Malla principal. Hay beneficios en tener una implementación en Go, por ejemplo, para otras cadenas que no desean ejecutar CosmWasm, o simplemente para el aumento del nivel de especificación técnica que exigen dos implementaciones, pero estos beneficios no benefician directamente al Hub. Además, tener múltiples implementaciones de un protocolo descentralizado no es trivial. Hasta donde yo sé, ni Tendermint ni IBC tienen implementaciones completamente interoperables en diferentes lenguajes.
Como insinué anteriormente, una de las cosas más emocionantes de la Seguridad Opt-In es su capacidad para actuar como plataforma de lanzamiento para nuevos proyectos de Cosmos. Los nuevos proyectos podrán crear una transacción sin permisos que establezca su proyecto como una cadena de consumo de Seguridad Opt-In. Luego, los validadores del Hub pueden optar por validar estas cadenas. Las cadenas de consumo Opt-In podrán lanzar sin permisos una cadena con un alto nivel de seguridad proveniente de un conjunto diverso de validadores que utilizan el Cosmos Hub.
La Seguridad Opt-In estará lista pronto, pero la Seguridad de Malla probablemente llevará un poco más de tiempo. El Hub puede expandir esta plataforma de lanzamiento de cadenas sin permisos a la Seguridad de Malla cuando esté lista. Las cadenas aseguradas por Malla comenzarán con una transacción sin permisos en el Cosmos Hub. Esto permitirá a los validadores del Hub optar por formar parte del conjunto de validadores de la nueva cadena asegurada por malla y permitirá a los delegadores de Atom delegar en ellos.
El Hub es el mejor lugar para hacer esto, ya que las nuevas cadenas aseguradas por malla podrán comenzar con un conjunto de validadores de calidad y un alto nivel de seguridad. Una vez que se lance la cadena, podrá conectarse con otras cadenas de Seguridad de Malla.
Last updated