Desde el evento de Multichain, la forma correcta de gestionar la Billetera de cálculo más largo.
Recientemente, el CEO de un protocolo de cadena cruzada fue llevado por la policía, lo que resultó en que su equipo global no pudiera ser contactado y se revocaron las claves de acceso a los servidores de nodos de cálculo más largo. Este evento reveló la razón detrás de las anomalías en la operación de dicho protocolo, y también planteó una pregunta importante: ¿por qué, a pesar de utilizar tecnología de cálculo más largo, aún se enfrenta a tales riesgos?
La respuesta en realidad es muy simple, aunque el protocolo utiliza tecnología de cálculo múltiple para gestionar los fondos, la descentralización de la tecnología no equivale a la descentralización de la gestión. La verdadera descentralización requiere alcanzar una unidad en la aplicación tecnológica y en la forma de gestión.
Casos similares no son infrecuentes. Por ejemplo, Bitcoin es descentralizado, pero si un minero monopoliza toda la potencia de cálculo, entonces el significado de la descentralización del algoritmo se pierde; Ethereum también es descentralizado, pero su fundador sigue enfatizando la importancia de la tecnología de verificación distribuida para evitar la aparición de tendencias centralizadoras.
Al profundizar en los detalles del anuncio, se puede descubrir que la raíz del problema del protocolo radica en que todos los nodos del servidor en realidad funcionan bajo la cuenta personal del servidor en la nube del CEO. Esta centralización del servicio de nodos es esencialmente equivalente a un monopolio de un solo minero sobre toda la potencia de cálculo, lo que equivale a que el CEO utiliza una billetera de firma única para controlar todos los activos. Por lo tanto, el problema del protocolo es que el CEO no debería tener el control de todos los fragmentos de cálculo más largo y no ha proporcionado una solución de respaldo en situaciones extremas.
Entonces, ¿cómo se pueden aprovechar al máximo las características de la tecnología de cálculo más largo? Principalmente hay tres puntos:
Aumentar la transparencia y prevenir conflictos de interés;
Seguir estrictamente el método de custodia descentralizada para evitar la concentración excesiva de poder;
Elaborar un plan de respuesta para situaciones extremas.
Prevención de conflictos de interés: rechazar operaciones opacas
En este evento, una cadena pública también se vio seriamente afectada. El fundador de dicha cadena pública afirmó en un foro que anteriormente había recibido muchas garantías sobre la descentralización de los servidores, el acceso y la distribución geográfica. Sin embargo, después se demostró que estas garantías no se cumplieron, y la parte de la cadena pública tampoco pudo o no quiso verificar, eligiendo confiar de manera simple, lo que resultó en pérdidas indirectas.
Se puede ver que el esquema de cálculo multipartito de este protocolo de cadena cruzada es esencialmente una "caja negra". La aparición de esta "caja negra" se debe a que el protocolo es tanto el constructor del servicio como el usuario del servicio, y esta superposición de roles inevitablemente trae consigo falta de transparencia y un espacio potencial para el abuso. La forma de resolver este problema es introducir un tercero completamente neutral, que no tenga conflictos de interés, es decir, utilizar servicios de cálculo multipartito de terceros con suficiente credibilidad, en lugar de construir servicios propios.
Los conflictos de interés son comunes en el ámbito de Web3, por ejemplo, algunos intercambios centralizados asumen simultáneamente las funciones de proporcionar servicios de intercambio y custodiar activos para los usuarios, y pueden obtener ganancias al utilizar estos fondos, como participar en minería en cadena, hacer mercado o invertir.
Volviendo al evento, si el protocolo de cadena cruzada utiliza un servicio de computación multiparte de terceros con suficiente credibilidad, al menos en la medida en que el protocolo lo permita, el proveedor de servicios puede ofrecer verificaciones de información sobre soluciones de custodia para las partes relevantes, eliminando así la "caja negra".
Custodia descentralizada: evitar el riesgo de un solo punto
El análisis posterior indica que el riesgo de punto único del CEO es la causa directa de este incidente. Lo correcto sería asegurar la distribución de servidores, acceso y ubicación geográfica.
Un esquema ideal de cálculo multiparte debería adoptar firmas multiparte 3-3 (también puede soportar configuraciones de firma de umbral t-n), donde dos partes son co-administradas por la plataforma, asegurando la seguridad a través de cifrado de alta intensidad y un entorno de ejecución confiable, y se requiere la participación de las tres partes para completar la firma de la transacción, evitando así el riesgo de punto único para el usuario.
Además, dado que los negocios suelen ser jerárquicos, el acceso también debería ser jerárquico. Se puede adoptar un diseño de derivación de claves privadas en varios niveles, que facilite a los administradores controlar la visión global, al mismo tiempo que sea compatible con la gestión de permisos específicos por parte del personal de primera línea, evitando así que un riesgo de punto único bloquee todos los procesos comerciales.
Por último, se deben adoptar soluciones como almacenamiento distribuido en línea de múltiples ubicaciones, copias de seguridad en frío fuera de línea de múltiples niveles, y servicios de recuperación de respaldo integrados de instituciones profesionales, para asegurar el más alto nivel de garantía de distribución geográfica. Esta serie de mecanismos puede minimizar al máximo la pérdida de activos o la indisponibilidad del servicio causada por riesgos de punto único, incluyendo aspectos de clave privada, personal y entorno externo.
Establecer un plan de recuperación social en situaciones extremas
Es necesario reconocer que no hay ningún plan que sea perfecto. Asegurar la descentralización de los servidores, el acceso y la ubicación geográfica puede resolver algunos problemas, pero no todos. Muchos riesgos aún existen, como los factores de fuerza mayor en el mundo físico. En situaciones inevitables, necesitamos pensar en cómo responder cuando ocurran estas circunstancias extremas.
Basado en esto, se puede imaginar un "modo SOS" para riesgos de fuerza mayor en el mundo físico. Este servicio puede ofrecerse como un servicio opcional no estándar a los usuarios que lo necesiten, y se diseñará de manera personalizada según las necesidades reales. Además de la fragmentación tradicional de claves privadas, se establecerán varios fragmentos SOS, que se gestionarán por separado de los fragmentos de claves privadas ordinarias.
En condiciones normales, las fragmentaciones SOS no desempeñarán ninguna función. Sin embargo, en situaciones específicas, las fragmentaciones SOS se activarán, como la activación manual por parte del administrador de fragmentos de clave privada en caso de emergencia, la desconexión de fragmentos de clave privada que alcance un umbral de tiempo determinado, la iniciación de un evento de emergencia por parte de la fragmentación SOS, o la aprobación a través de votación de gobernanza según reglas establecidas. Al activar el "modo SOS", la fragmentación SOS reemplazará a la fragmentación de clave privada para llevar a cabo la transferencia o disposición de activos en situaciones de emergencia.
Para evitar que los titulares de fragmentos de SOS actúen de mala fe, se pueden agregar algunas condiciones restrictivas, como establecer un retraso en la activación del modo "SOS", durante el cual los fragmentos de clave privada normales pueden anular el "modo SOS"; o establecer un período de bloqueo después de la transferencia de activos de emergencia en el modo "SOS", durante el cual no se puede realizar ninguna transferencia adicional, para prevenir la pérdida de activos.
A través de estas medidas, podemos aprovechar al máximo las ventajas de la tecnología de cálculo más largo, al mismo tiempo que reducimos al mínimo los diversos riesgos, asegurando la seguridad de los activos y la efectividad de la gestión.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
14 me gusta
Recompensa
14
7
Republicar
Compartir
Comentar
0/400
HashBrownies
· 07-23 21:33
La gestión centralizada y la Descentralización son inherentemente conflictivas.
Ver originalesResponder0
ChainComedian
· 07-23 17:58
La concentración de poder es la mayor vulnerabilidad.
Ver originalesResponder0
PrivacyMaximalist
· 07-21 04:18
No hay suficiente descentralización si hay transparencia.
Ver originalesResponder0
StrawberryIce
· 07-21 04:18
No vayas a hacer otro proyecto y salir corriendo.
Ver originalesResponder0
PumpBeforeRug
· 07-21 04:17
Así que es el dilema de la seguridad otra vez.
Ver originalesResponder0
BlockchainFries
· 07-21 04:12
Gestión de riesgos es una broma.
Ver originalesResponder0
GateUser-75ee51e7
· 07-21 04:10
¡El fallo de un solo punto es realmente aterrador!
La gestión correcta de la Billetera de cálculo más largo: transparencia, Descentralización y respuesta a situaciones extremas
Desde el evento de Multichain, la forma correcta de gestionar la Billetera de cálculo más largo.
Recientemente, el CEO de un protocolo de cadena cruzada fue llevado por la policía, lo que resultó en que su equipo global no pudiera ser contactado y se revocaron las claves de acceso a los servidores de nodos de cálculo más largo. Este evento reveló la razón detrás de las anomalías en la operación de dicho protocolo, y también planteó una pregunta importante: ¿por qué, a pesar de utilizar tecnología de cálculo más largo, aún se enfrenta a tales riesgos?
La respuesta en realidad es muy simple, aunque el protocolo utiliza tecnología de cálculo múltiple para gestionar los fondos, la descentralización de la tecnología no equivale a la descentralización de la gestión. La verdadera descentralización requiere alcanzar una unidad en la aplicación tecnológica y en la forma de gestión.
Casos similares no son infrecuentes. Por ejemplo, Bitcoin es descentralizado, pero si un minero monopoliza toda la potencia de cálculo, entonces el significado de la descentralización del algoritmo se pierde; Ethereum también es descentralizado, pero su fundador sigue enfatizando la importancia de la tecnología de verificación distribuida para evitar la aparición de tendencias centralizadoras.
Al profundizar en los detalles del anuncio, se puede descubrir que la raíz del problema del protocolo radica en que todos los nodos del servidor en realidad funcionan bajo la cuenta personal del servidor en la nube del CEO. Esta centralización del servicio de nodos es esencialmente equivalente a un monopolio de un solo minero sobre toda la potencia de cálculo, lo que equivale a que el CEO utiliza una billetera de firma única para controlar todos los activos. Por lo tanto, el problema del protocolo es que el CEO no debería tener el control de todos los fragmentos de cálculo más largo y no ha proporcionado una solución de respaldo en situaciones extremas.
Entonces, ¿cómo se pueden aprovechar al máximo las características de la tecnología de cálculo más largo? Principalmente hay tres puntos:
Prevención de conflictos de interés: rechazar operaciones opacas
En este evento, una cadena pública también se vio seriamente afectada. El fundador de dicha cadena pública afirmó en un foro que anteriormente había recibido muchas garantías sobre la descentralización de los servidores, el acceso y la distribución geográfica. Sin embargo, después se demostró que estas garantías no se cumplieron, y la parte de la cadena pública tampoco pudo o no quiso verificar, eligiendo confiar de manera simple, lo que resultó en pérdidas indirectas.
Se puede ver que el esquema de cálculo multipartito de este protocolo de cadena cruzada es esencialmente una "caja negra". La aparición de esta "caja negra" se debe a que el protocolo es tanto el constructor del servicio como el usuario del servicio, y esta superposición de roles inevitablemente trae consigo falta de transparencia y un espacio potencial para el abuso. La forma de resolver este problema es introducir un tercero completamente neutral, que no tenga conflictos de interés, es decir, utilizar servicios de cálculo multipartito de terceros con suficiente credibilidad, en lugar de construir servicios propios.
Los conflictos de interés son comunes en el ámbito de Web3, por ejemplo, algunos intercambios centralizados asumen simultáneamente las funciones de proporcionar servicios de intercambio y custodiar activos para los usuarios, y pueden obtener ganancias al utilizar estos fondos, como participar en minería en cadena, hacer mercado o invertir.
Volviendo al evento, si el protocolo de cadena cruzada utiliza un servicio de computación multiparte de terceros con suficiente credibilidad, al menos en la medida en que el protocolo lo permita, el proveedor de servicios puede ofrecer verificaciones de información sobre soluciones de custodia para las partes relevantes, eliminando así la "caja negra".
Custodia descentralizada: evitar el riesgo de un solo punto
El análisis posterior indica que el riesgo de punto único del CEO es la causa directa de este incidente. Lo correcto sería asegurar la distribución de servidores, acceso y ubicación geográfica.
Un esquema ideal de cálculo multiparte debería adoptar firmas multiparte 3-3 (también puede soportar configuraciones de firma de umbral t-n), donde dos partes son co-administradas por la plataforma, asegurando la seguridad a través de cifrado de alta intensidad y un entorno de ejecución confiable, y se requiere la participación de las tres partes para completar la firma de la transacción, evitando así el riesgo de punto único para el usuario.
Además, dado que los negocios suelen ser jerárquicos, el acceso también debería ser jerárquico. Se puede adoptar un diseño de derivación de claves privadas en varios niveles, que facilite a los administradores controlar la visión global, al mismo tiempo que sea compatible con la gestión de permisos específicos por parte del personal de primera línea, evitando así que un riesgo de punto único bloquee todos los procesos comerciales.
Por último, se deben adoptar soluciones como almacenamiento distribuido en línea de múltiples ubicaciones, copias de seguridad en frío fuera de línea de múltiples niveles, y servicios de recuperación de respaldo integrados de instituciones profesionales, para asegurar el más alto nivel de garantía de distribución geográfica. Esta serie de mecanismos puede minimizar al máximo la pérdida de activos o la indisponibilidad del servicio causada por riesgos de punto único, incluyendo aspectos de clave privada, personal y entorno externo.
Establecer un plan de recuperación social en situaciones extremas
Es necesario reconocer que no hay ningún plan que sea perfecto. Asegurar la descentralización de los servidores, el acceso y la ubicación geográfica puede resolver algunos problemas, pero no todos. Muchos riesgos aún existen, como los factores de fuerza mayor en el mundo físico. En situaciones inevitables, necesitamos pensar en cómo responder cuando ocurran estas circunstancias extremas.
Basado en esto, se puede imaginar un "modo SOS" para riesgos de fuerza mayor en el mundo físico. Este servicio puede ofrecerse como un servicio opcional no estándar a los usuarios que lo necesiten, y se diseñará de manera personalizada según las necesidades reales. Además de la fragmentación tradicional de claves privadas, se establecerán varios fragmentos SOS, que se gestionarán por separado de los fragmentos de claves privadas ordinarias.
En condiciones normales, las fragmentaciones SOS no desempeñarán ninguna función. Sin embargo, en situaciones específicas, las fragmentaciones SOS se activarán, como la activación manual por parte del administrador de fragmentos de clave privada en caso de emergencia, la desconexión de fragmentos de clave privada que alcance un umbral de tiempo determinado, la iniciación de un evento de emergencia por parte de la fragmentación SOS, o la aprobación a través de votación de gobernanza según reglas establecidas. Al activar el "modo SOS", la fragmentación SOS reemplazará a la fragmentación de clave privada para llevar a cabo la transferencia o disposición de activos en situaciones de emergencia.
Para evitar que los titulares de fragmentos de SOS actúen de mala fe, se pueden agregar algunas condiciones restrictivas, como establecer un retraso en la activación del modo "SOS", durante el cual los fragmentos de clave privada normales pueden anular el "modo SOS"; o establecer un período de bloqueo después de la transferencia de activos de emergencia en el modo "SOS", durante el cual no se puede realizar ninguna transferencia adicional, para prevenir la pérdida de activos.
A través de estas medidas, podemos aprovechar al máximo las ventajas de la tecnología de cálculo más largo, al mismo tiempo que reducimos al mínimo los diversos riesgos, asegurando la seguridad de los activos y la efectividad de la gestión.