Gestion correcte des portefeuilles de calcul plus long à partir des événements Multichain
Récemment, le PDG d'un certain protocole inter-chaînes a été emmené par la police, ce qui a rendu son équipe mondiale inaccessible, et les clés d'accès opérationnelles des serveurs de plus long calcul ont été révoquées. Cet événement a révélé la raison de l'anomalie dans le fonctionnement de ce protocole, tout en soulevant une question importante : pourquoi, malgré l'utilisation de la technologie de plus long calcul, fait-on encore face à de tels risques ?
La réponse est en fait très simple, bien que le protocole utilise la technologie de calcul plus long pour gérer les fonds, la décentralisation de la technologie n'est pas équivalente à la décentralisation de la gestion. Une véritable décentralisation nécessite une unité dans l'application de la technologie et les méthodes de gestion.
Des cas similaires ne sont pas rares. Par exemple, le Bitcoin est décentralisé, mais si un mineur monopolise toute la puissance de calcul, alors la décentralisation de l'algorithme perd son sens ; l'Ethereum est également décentralisé, mais son fondateur continue de souligner l'importance des technologies de validation distribuée pour éviter l'apparition de tendances centralisatrices.
En examinant de plus près les détails de l'annonce, on peut constater que la source des problèmes du protocole réside dans le fait que tous les serveurs de nœuds fonctionnent en réalité sous le compte personnel de serveur cloud du PDG. Cette centralisation des services de nœuds est essentiellement la même qu'un monopole de puissance de calcul par un seul mineur, ce qui équivaut à ce que le PDG contrôle tous les actifs à l'aide d'un portefeuille à signature unique. Par conséquent, le problème du protocole est que le PDG ne devrait pas avoir le contrôle de toutes les partitions de calcul plus long et n'a pas fourni de solutions de sauvegarde dans des situations extrêmes.
Alors, comment tirer pleinement parti des caractéristiques de la technologie de calcul plus long ? Il y a principalement trois points :
Améliorer la transparence, prévenir les conflits d'intérêts ;
Suivre strictement une méthode de conservation décentralisée pour éviter une concentration excessive du pouvoir ;
Élaborer un plan de réponse aux situations extrêmes.
Prévention des conflits d'intérêt : Refuser les opérations opaques
Dans cet incident, une certaine blockchain publique a également été gravement affectée. Le fondateur de cette blockchain a déclaré sur le forum qu'il avait précédemment reçu de nombreuses garanties concernant la décentralisation des serveurs, l'accès et la distribution géographique. Cependant, il s'est avéré par la suite que ces garanties n'avaient pas été tenues, et que cette blockchain n'avait pas pu ou n'avait pas voulu vérifier, choisissant de faire confiance de manière simple, et a finalement subi des pertes connexes.
On peut voir que le schéma de calcul multipartite de ce protocole inter-chaînes est en réalité une "boîte noire". La raison de cette "boîte noire" est que ce protocole est à la fois le constructeur du service et l'utilisateur du service, ce qui entraîne inévitablement un manque de transparence et un espace potentiel pour des méfaits. La solution à ce problème est d'introduire un tiers complètement neutre, sans conflit d'intérêts, c'est-à-dire d'utiliser un service de calcul multipartite tiers ayant suffisamment de crédibilité, plutôt que de construire un service soi-même.
Les conflits d'intérêts sont courants dans le domaine du Web3, par exemple, certaines bourses centralisées assument à la fois la fonction de fournir des services de trading et celle de garder les actifs des utilisateurs, et peuvent tirer profit de ces fonds, par exemple en participant à des opérations de minage sur la chaîne, en réalisant des opérations de market-making ou en investissant.
Revenons à cet événement. Si le protocole inter-chaînes utilise un service de calcul multi-parties tiers ayant une crédibilité suffisante, au moins dans la mesure où le protocole le permet, le fournisseur de services peut offrir des solutions d'hébergement pour la vérification des informations aux parties concernées, éliminant ainsi la "boîte noire".
Custodie décentralisée : éviter le risque de point unique
L'analyse post-événement a montré que le risque de point unique du CEO était la cause directe de cet événement. La bonne pratique devrait être d'assurer la distribution des serveurs, des accès et des emplacements géographiques.
Une solution idéale de calcul multipartite devrait utiliser une signature multipartite 3-3 (qui peut également prendre en charge des configurations de signature à seuil t-n), où deux parties sont co-gérées par la plateforme, garantissant la sécurité grâce à un cryptage de haute sécurité et à un environnement d'exécution fiable. Les trois parties doivent participer ensemble pour compléter la signature de la transaction, évitant ainsi le risque de point unique pour l'utilisateur.
De plus, étant donné que les activités sont généralement hiérarchisées, les droits d'accès devraient également être hiérarchisés. Un design de dérivation de clé privée multi-niveaux peut être adopté, ce qui permet aux gestionnaires de contrôler l'ensemble tout en permettant aux opérateurs de première ligne de gérer des autorisations spécifiques, évitant ainsi le risque de point de défaillance qui pourrait bloquer tous les processus d'affaires.
Enfin, des solutions telles que le stockage distribué multi-actif en ligne, les sauvegardes hors ligne à plusieurs niveaux, et l'intégration de services de sauvegarde et de récupération d'institutions professionnelles doivent être adoptées pour garantir le meilleur niveau de répartition géographique. Cette série de mécanismes peut minimiser au maximum les pertes d'actifs ou l'indisponibilité des services dues à des risques de point unique, y compris au niveau des clés privées, du personnel et de l'environnement externe.
Élaborer un plan de récupération sociale en cas de situation extrême
Il faut reconnaître qu'aucun plan n'est parfait. Assurer la décentralisation des serveurs, de l'accès et de la localisation peut résoudre certains problèmes, mais pas tous. De nombreux risques demeurent, tels que les facteurs de force majeure dans le monde physique. Dans les situations inévitables, nous devons réfléchir à la manière de réagir lorsque de telles extrêmes se produisent.
Sur cette base, on peut envisager un "mode SOS" pour les risques de force majeure dans le monde physique. Ce service peut être proposé comme un service optionnel non standard aux utilisateurs ayant des besoins, et conçu sur mesure en fonction des besoins réels. En plus des traditionnels fragments de clé privée, plusieurs fragments SOS seront également mis en place, qui seront gérés séparément des fragments de clé privée ordinaires.
En temps normal, les fragments SOS n'ont aucun effet. Cependant, dans des cas spécifiques, les fragments SOS seront activés, par exemple, en cas d'urgence lorsque le gestionnaire de fragments de clé privée les active manuellement, lorsque les fragments de clé privée sont déconnectés pendant un certain seuil de temps, lorsque les fragments SOS déclenchent activement un événement d'urgence, ou lorsque le vote de gouvernance selon des règles établies est approuvé. Après l'activation du "mode SOS", les fragments SOS remplaceront les fragments de clé privée pour permettre le transfert ou la disposition d'actifs en cas d'urgence.
Pour éviter que les détenteurs de fragments SOS ne commettent des abus, il est possible d'ajouter certaines conditions restrictives, telles que la mise en place d'un délai d'activation pour le mode "SOS", pendant lequel les fragments de clé privée ordinaires peuvent annuler le "mode SOS" ; ou après le transfert d'urgence des actifs en mode "SOS", établir une période de verrouillage, durant laquelle aucun transfert supplémentaire ne peut être effectué, afin d'éviter la perte d'actifs.
Grâce à ces mesures, nous pouvons maximiser l'utilisation des avantages de la technologie de calcul plus long tout en réduisant au maximum divers risques, garantissant ainsi la sécurité des actifs et l'efficacité de la gestion.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
7
Reposter
Partager
Commentaire
0/400
HashBrownies
· 07-23 21:33
La gestion centralisée est en conflit avec la Décentralisation.
Voir l'originalRépondre0
ChainComedian
· 07-23 17:58
La concentration du pouvoir est la plus grande vulnérabilité.
Voir l'originalRépondre0
PrivacyMaximalist
· 07-21 04:18
Avec de la transparence, ce n'est pas assez décentralisé.
Voir l'originalRépondre0
StrawberryIce
· 07-21 04:18
Ne fais pas encore un Rug Pull.
Voir l'originalRépondre0
PumpBeforeRug
· 07-21 04:17
C'est encore le paradoxe de la sécurité, n'est-ce pas ?
Voir l'originalRépondre0
BlockchainFries
· 07-21 04:12
Gestion des risques est une blague.
Voir l'originalRépondre0
GateUser-75ee51e7
· 07-21 04:10
Une panne unique est vraiment terrifiante, n'est-ce pas ?
Gestion correcte du portefeuille de calcul plus long : transparence, Décentralisation et gestion des situations extrêmes
Gestion correcte des portefeuilles de calcul plus long à partir des événements Multichain
Récemment, le PDG d'un certain protocole inter-chaînes a été emmené par la police, ce qui a rendu son équipe mondiale inaccessible, et les clés d'accès opérationnelles des serveurs de plus long calcul ont été révoquées. Cet événement a révélé la raison de l'anomalie dans le fonctionnement de ce protocole, tout en soulevant une question importante : pourquoi, malgré l'utilisation de la technologie de plus long calcul, fait-on encore face à de tels risques ?
La réponse est en fait très simple, bien que le protocole utilise la technologie de calcul plus long pour gérer les fonds, la décentralisation de la technologie n'est pas équivalente à la décentralisation de la gestion. Une véritable décentralisation nécessite une unité dans l'application de la technologie et les méthodes de gestion.
Des cas similaires ne sont pas rares. Par exemple, le Bitcoin est décentralisé, mais si un mineur monopolise toute la puissance de calcul, alors la décentralisation de l'algorithme perd son sens ; l'Ethereum est également décentralisé, mais son fondateur continue de souligner l'importance des technologies de validation distribuée pour éviter l'apparition de tendances centralisatrices.
En examinant de plus près les détails de l'annonce, on peut constater que la source des problèmes du protocole réside dans le fait que tous les serveurs de nœuds fonctionnent en réalité sous le compte personnel de serveur cloud du PDG. Cette centralisation des services de nœuds est essentiellement la même qu'un monopole de puissance de calcul par un seul mineur, ce qui équivaut à ce que le PDG contrôle tous les actifs à l'aide d'un portefeuille à signature unique. Par conséquent, le problème du protocole est que le PDG ne devrait pas avoir le contrôle de toutes les partitions de calcul plus long et n'a pas fourni de solutions de sauvegarde dans des situations extrêmes.
Alors, comment tirer pleinement parti des caractéristiques de la technologie de calcul plus long ? Il y a principalement trois points :
Prévention des conflits d'intérêt : Refuser les opérations opaques
Dans cet incident, une certaine blockchain publique a également été gravement affectée. Le fondateur de cette blockchain a déclaré sur le forum qu'il avait précédemment reçu de nombreuses garanties concernant la décentralisation des serveurs, l'accès et la distribution géographique. Cependant, il s'est avéré par la suite que ces garanties n'avaient pas été tenues, et que cette blockchain n'avait pas pu ou n'avait pas voulu vérifier, choisissant de faire confiance de manière simple, et a finalement subi des pertes connexes.
On peut voir que le schéma de calcul multipartite de ce protocole inter-chaînes est en réalité une "boîte noire". La raison de cette "boîte noire" est que ce protocole est à la fois le constructeur du service et l'utilisateur du service, ce qui entraîne inévitablement un manque de transparence et un espace potentiel pour des méfaits. La solution à ce problème est d'introduire un tiers complètement neutre, sans conflit d'intérêts, c'est-à-dire d'utiliser un service de calcul multipartite tiers ayant suffisamment de crédibilité, plutôt que de construire un service soi-même.
Les conflits d'intérêts sont courants dans le domaine du Web3, par exemple, certaines bourses centralisées assument à la fois la fonction de fournir des services de trading et celle de garder les actifs des utilisateurs, et peuvent tirer profit de ces fonds, par exemple en participant à des opérations de minage sur la chaîne, en réalisant des opérations de market-making ou en investissant.
Revenons à cet événement. Si le protocole inter-chaînes utilise un service de calcul multi-parties tiers ayant une crédibilité suffisante, au moins dans la mesure où le protocole le permet, le fournisseur de services peut offrir des solutions d'hébergement pour la vérification des informations aux parties concernées, éliminant ainsi la "boîte noire".
Custodie décentralisée : éviter le risque de point unique
L'analyse post-événement a montré que le risque de point unique du CEO était la cause directe de cet événement. La bonne pratique devrait être d'assurer la distribution des serveurs, des accès et des emplacements géographiques.
Une solution idéale de calcul multipartite devrait utiliser une signature multipartite 3-3 (qui peut également prendre en charge des configurations de signature à seuil t-n), où deux parties sont co-gérées par la plateforme, garantissant la sécurité grâce à un cryptage de haute sécurité et à un environnement d'exécution fiable. Les trois parties doivent participer ensemble pour compléter la signature de la transaction, évitant ainsi le risque de point unique pour l'utilisateur.
De plus, étant donné que les activités sont généralement hiérarchisées, les droits d'accès devraient également être hiérarchisés. Un design de dérivation de clé privée multi-niveaux peut être adopté, ce qui permet aux gestionnaires de contrôler l'ensemble tout en permettant aux opérateurs de première ligne de gérer des autorisations spécifiques, évitant ainsi le risque de point de défaillance qui pourrait bloquer tous les processus d'affaires.
Enfin, des solutions telles que le stockage distribué multi-actif en ligne, les sauvegardes hors ligne à plusieurs niveaux, et l'intégration de services de sauvegarde et de récupération d'institutions professionnelles doivent être adoptées pour garantir le meilleur niveau de répartition géographique. Cette série de mécanismes peut minimiser au maximum les pertes d'actifs ou l'indisponibilité des services dues à des risques de point unique, y compris au niveau des clés privées, du personnel et de l'environnement externe.
Élaborer un plan de récupération sociale en cas de situation extrême
Il faut reconnaître qu'aucun plan n'est parfait. Assurer la décentralisation des serveurs, de l'accès et de la localisation peut résoudre certains problèmes, mais pas tous. De nombreux risques demeurent, tels que les facteurs de force majeure dans le monde physique. Dans les situations inévitables, nous devons réfléchir à la manière de réagir lorsque de telles extrêmes se produisent.
Sur cette base, on peut envisager un "mode SOS" pour les risques de force majeure dans le monde physique. Ce service peut être proposé comme un service optionnel non standard aux utilisateurs ayant des besoins, et conçu sur mesure en fonction des besoins réels. En plus des traditionnels fragments de clé privée, plusieurs fragments SOS seront également mis en place, qui seront gérés séparément des fragments de clé privée ordinaires.
En temps normal, les fragments SOS n'ont aucun effet. Cependant, dans des cas spécifiques, les fragments SOS seront activés, par exemple, en cas d'urgence lorsque le gestionnaire de fragments de clé privée les active manuellement, lorsque les fragments de clé privée sont déconnectés pendant un certain seuil de temps, lorsque les fragments SOS déclenchent activement un événement d'urgence, ou lorsque le vote de gouvernance selon des règles établies est approuvé. Après l'activation du "mode SOS", les fragments SOS remplaceront les fragments de clé privée pour permettre le transfert ou la disposition d'actifs en cas d'urgence.
Pour éviter que les détenteurs de fragments SOS ne commettent des abus, il est possible d'ajouter certaines conditions restrictives, telles que la mise en place d'un délai d'activation pour le mode "SOS", pendant lequel les fragments de clé privée ordinaires peuvent annuler le "mode SOS" ; ou après le transfert d'urgence des actifs en mode "SOS", établir une période de verrouillage, durant laquelle aucun transfert supplémentaire ne peut être effectué, afin d'éviter la perte d'actifs.
Grâce à ces mesures, nous pouvons maximiser l'utilisation des avantages de la technologie de calcul plus long tout en réduisant au maximum divers risques, garantissant ainsi la sécurité des actifs et l'efficacité de la gestion.