Les contrats proxy sont un outil important pour les développeurs de contrats intelligents. Aujourd'hui, il existe de nombreux modes de proxy et règles d'utilisation correspondantes dans le système de contrat. Nous avons précédemment décrit les meilleures pratiques de sécurité des contrats de proxy évolutifs.
Dans cet article, nous présenterons un autre modèle de proxy populaire dans la communauté des développeurs, le modèle de proxy en diamant.
Les contrats proxy Diamond, également appelés "diamants", sont un modèle de conception pour les contrats intelligents Ethereum introduits par la proposition d'amélioration Ethereum (EIP) 2535.
Le mode diamant permet à un contrat d'avoir des fonctionnalités illimitées en divisant ses fonctionnalités en contrats plus petits (également appelés à juste titre "aspects"). Diamond agit comme un proxy, acheminant les appels de fonction vers l'aspect approprié.
La conception du modèle en diamant peut résoudre le problème de la limitation de la taille maximale des contrats du réseau Ethereum. En décomposant un gros contrat en aspects plus petits, le modèle en losange permet aux développeurs de créer des contrats intelligents plus complexes et riches en fonctionnalités sans être affectés par les contraintes de taille.
Diamond Brokerage offre une flexibilité énorme par rapport aux contrats évolutifs traditionnels. Ils permettent de mettre à niveau des parties contractuelles, d'ajouter, de remplacer ou de supprimer des parties sélectionnées de fonctions sans toucher aux autres parties.
Cet article fournit une vue d'ensemble d'EIP-2535, y compris une comparaison avec le mode proxy transparent et le mode proxy UUPS largement utilisés, et ses considérations de sécurité pour la communauté des développeurs.
Dans le cadre de l'EIP-2535, un « diamant » est un contrat proxy dont la mise en œuvre fonctionnelle est assurée par différents contrats logiques, appelés « aspects ».
Imaginez qu'un vrai diamant ait différentes faces, appelées facettes, et que les contrats de diamant Ethereum correspondants aient également différentes facettes. Chaque contrat de fonction d'emprunt de diamants est un côté ou une facette différente.
La norme diamant utilise une analogie pour étendre les capacités de la "coupe diamant" pour ajouter, remplacer ou supprimer des facettes et des caractéristiques.
De plus, le Diamond Standard fournit une fonctionnalité appelée "Diamond Loupe" qui renvoie des informations sur les facettes et la présence du diamant.
Par rapport au modèle de procuration traditionnel, le « losange » équivaut au contrat de procuration, et les différents « aspects » correspondent à la réalisation du contrat. Différents aspects d'un agent diamant peuvent partager des fonctions internes, des bibliothèques et des variables d'état. Les composants clés d'un diamant sont les suivants :
Un contrat central qui agit comme un proxy, achemine les appels de fonction vers l'aspect approprié. Il contient un mappage des sélecteurs de fonction aux adresses "d'aspect".
Un contrat unique qui met en œuvre une fonction spécifique. Chaque facette contient un ensemble de fonctions qui peuvent être appelées par le diamant.
est un ensemble de fonctions standard définies dans EIP-2535 qui fournissent des informations sur les sélecteurs de facettes et de fonctions utilisés dans les diamants. Diamond Loupe permet aux développeurs et aux utilisateurs d'inspecter et de comprendre la structure des diamants.
Fonctions pour ajouter, remplacer ou supprimer des facettes dans un diamant et leurs sélecteurs de fonction correspondants. Seules les adresses autorisées (par exemple, le propriétaire du diamant ou un contrat à plusieurs signatures) peuvent effectuer la taille du diamant.
Comme pour les agents traditionnels, lorsqu'un appel de fonction est effectué sur un agent diamant, la fonction de repli de l'agent (fonction de repli) est déclenchée. La principale différence avec le proxy diamant est que dans la fonction de secours, il existe un mappage selectorToFacet, qui stocke et détermine quelle adresse de contrat logique a l'implémentation de la fonction appelée. Il utilise ensuite un appel délégué pour exécuter la fonction, tout comme un proxy traditionnel.
Tous les proxys utilisent la fonction fallback() pour déléguer les appels de fonction à des adresses externes. Vous trouverez ci-dessous la mise en œuvre du proxy diamant et la mise en œuvre du proxy traditionnel.
Il convient de noter que leurs blocs de code d'assemblage sont très similaires, de sorte que la seule différence est l'adresse d'aspect dans l'appel de délégué proxy diamant et l'adresse impl dans l'appel de délégué proxy traditionnel.
La principale différence est que dans le proxy diamant, l'adresse de l'aspect est déterminée par le hashmap du msg.sig (sélecteur de fonction) de l'appelant à l'adresse de l'aspect, tandis que dans le proxy traditionnel, l'adresse impl ne dépend pas de l'entrée de l'appelant.
Fonction de repli de l'agent diamant
Fonction de secours proxy traditionnelle
Le mappage SelectorToFacet détermine quel contrat contient l'implémentation de chaque sélecteur de fonction. Les travailleurs du projet ont souvent besoin d'ajouter, de remplacer ou de supprimer ce mappage du sélecteur de fonction au contrat d'implémentation. EIP-2535 déclare : Pour y parvenir, il doit y avoir une fonction diamondCut(). Vous trouverez ci-dessous un exemple d'interface.
Chaque structure FacetCut contient une adresse de facette et un tableau de sélection de fonctionnalités à quatre octets à mettre à jour dans le contrat de proxy en diamant. FaceCutAction permet d'ajouter, de remplacer et de supprimer des sélecteurs de fonctionnalités. L'implémentation de la fonction diamondCut() doit inclure un contrôle d'accès adéquat, empêcher les collisions d'emplacements, récupérer en cas d'échec, etc.
Afin d'interroger les fonctions et les facettes d'un agent diamanté, nous utilisons la "loupe diamantée". "Diamond Loupe" est un aspect spécial qui implémente l'interface suivante définie dans EIP-2535 :
La fonction facets() doit renvoyer les adresses de toutes les facettes et leurs sélecteurs de fonction à quatre octets. La fonction facetFunctionSelectors() doit renvoyer tous les sélecteurs de fonction pris en charge par un aspect particulier. La fonction facetAddresses() doit renvoyer toutes les adresses de facette utilisées par un diamant.
La fonction facetAddress() doit renvoyer un aspect qui prend en charge le sélecteur donné, ou address( 0 ) s'il n'est pas trouvé. Notez qu'il ne doit pas y avoir plus d'une adresse d'aspect avec le même sélecteur de fonctionnalité.
Étant donné que les proxys diamant délèguent différents appels de fonction à différents contrats de mise en œuvre, il est essentiel de gérer correctement les emplacements de stockage pour éviter les conflits. EIP-2535 mentionne plusieurs méthodes de gestion des emplacements de stockage.
Cet aspect peut déclarer des variables d'état dans la structure. Cet aspect peut utiliser n'importe quel nombre de structures, chacune avec un emplacement de stockage différent. Chaque structure a un emplacement spécifique dans le stockage contractuel. Les aspects peuvent déclarer leurs propres variables d'état, mais ils ne peuvent pas entrer en conflit avec les emplacements de stockage des variables d'état déclarées par d'autres aspects. Une bibliothèque d'échantillons et un contrat de stockage de diamants sont fournis dans EIP-2535, comme illustré dans la figure suivante :
App Store est une version plus spécialisée de Diamond Store. Ce modèle est utilisé pour partager plus facilement et plus facilement les variables d'état des aspects. Une structure de magasin d'applications est définie pour contenir n'importe quel nombre et type de variables d'état requises par une application. Un aspect déclare toujours la structure AppStorage comme première et unique variable d'état, à la position 0 de l'emplacement de stockage. Différents aspects peuvent alors accéder aux variables de cette structure.
Il existe également d'autres stratégies de gestion des emplacements de stockage, y compris un hybride de Diamond Storage et AppStorage. Par exemple, certaines structures sont partagées entre différents aspects, et certaines sont spécifiques à un aspect spécifique. Dans tous les cas, il est très important d'éviter les collisions accidentelles d'emplacements.
Comparaison avec le proxy transparent et le proxy UUPS
Les deux principaux modes proxy actuellement utilisés par la communauté des développeurs Web3 sont le mode proxy transparent et le mode proxy UUPS. Dans cette section, nous comparons brièvement le mode proxy diamant avec les modes proxy transparent et proxy UUPS.
Les solutions proxy et évolutives sont des systèmes plus complexes, et OpenZeppelin fournit des bases de code et une documentation complète pour les proxys évolutifs UUPS, Transparent et Beacon. Cependant, pour le modèle de proxy diamant, bien qu'OpenZeppelin ait affirmé ses avantages, ils ont quand même décidé de ne pas inclure l'implémentation diamant EIP-2535 dans leur bibliothèque.
Par conséquent, les développeurs utilisant des bibliothèques tierces existantes ou implémentant eux-mêmes cette solution doivent l'implémenter avec un soin extrême. Ici, nous avons compilé une liste de contrôle des meilleures pratiques de sécurité à prendre en compte par la communauté des développeurs.
En décomposant la logique contractuelle en modules plus petits et plus faciles à gérer, les développeurs peuvent plus facilement tester et auditer leur code.
De plus, cette approche permet aux développeurs de se concentrer sur des aspects spécifiques de la création et de la maintenance des contrats, plutôt que de gérer une base de code complexe et monolithique. Le résultat final est une base de code plus flexible et modulaire qui peut facilement être mise à jour et modifiée sans affecter les autres parties du contrat.
Source : Aavegotchi Github
Lorsque le contrat de proxy de diamant est déployé, il doit ajouter l'adresse du contrat DiamondCutFacet au contrat de proxy de diamant et implémenter la fonction diamondCut(). La fonction diamondCut() est utilisée pour ajouter, supprimer ou remplacer des facettes et des fonctions, sans DiamondCutFacet et diamondCut(), l'agent diamant ne peut pas fonctionner correctement.
La source: Casque Diamond-3-Hardhat de Mugen
Lors de l'ajout d'une nouvelle variable d'état à une structure de stockage dans un contrat intelligent, elle doit être ajoutée à la fin de la structure. L'ajout d'une nouvelle variable d'état au début ou au milieu d'une structure entraînera l'écrasement des données de variable d'état existantes par la nouvelle variable d'état, et toute variable d'état après la nouvelle variable d'état peut faire référence au mauvais emplacement de mémoire.
Le modèle AppStorage exige qu'une et une seule structure soit déclarée pour le proxy diamant, et que cette structure soit partagée par tous les aspects. Si plusieurs structures sont nécessaires, le modèle DiamondStorage doit être utilisé.
Ne placez pas une structure directement à l'intérieur d'une autre structure, sauf si vous êtes sûr de ne pas avoir l'intention d'ajouter d'autres variables d'état à la structure interne. Il n'est pas possible d'ajouter de nouvelles variables d'état aux structures internes dans une mise à niveau sans écraser les emplacements de stockage de variables déclarés après la structure.
La solution de contournement consiste à ajouter de nouvelles variables d'état à la structure mappée en mémoire au lieu de placer la "struct" directement dans la "struct". Les emplacements de stockage variables dans une carte sont calculés différemment et ne sont pas contigus dans le stockage.
La taille du tableau sera affectée par la taille de la structure. Lorsqu'une nouvelle variable d'état est ajoutée à une structure, elle modifie la taille et la disposition de cette structure.
Cela peut causer des problèmes si la structure est utilisée comme élément dans un tableau. Si la taille et la disposition de la structure changent, la taille et la disposition du tableau changeront également, ce qui peut entraîner des problèmes d'indexation ou d'autres opérations qui reposent sur une taille et une disposition cohérentes de la structure.
Comme pour les autres modèles de proxy, chaque variable doit avoir un emplacement de stockage unique. Sinon, deux structures différentes au même endroit s'écraseraient.
La fonction initialize() est généralement utilisée pour définir des variables importantes, telles que les adresses des rôles privilégiés. S'il n'est pas initialisé lors du déploiement du contrat, un acteur malveillant peut appeler et contrôler le contrat.
Il est recommandé d'ajouter un contrôle d'accès approprié à la fonction d'initialisation/de paramétrage, ou de s'assurer que la fonction est appelée lorsque le contrat est déployé et ne peut pas être appelée à nouveau.
Si un aspect du contrat est capable d'appeler la fonction selfdestruction(), il a le potentiel de détruire l'intégralité du contrat, entraînant une perte de fonds ou de données. Ceci est extrêmement dangereux en mode proxy diamant, car plusieurs aspects peuvent accéder au stockage et aux données du contrat de proxy.
Actuellement, nous voyons de plus en plus de projets adopter le modèle proxy du diamant dans leurs contrats intelligents. Il offre une flexibilité et d'autres avantages par rapport aux proxys traditionnels.
Cependant, la flexibilité supplémentaire peut également signifier une surface d'attaque plus large pour les attaquants. Nous espérons que cet article aidera la communauté des développeurs à comprendre les mécanismes du modèle de proxy diamant et ses considérations de sécurité.
Dans le même temps, l'équipe du projet doit effectuer des tests rigoureux et des audits tiers pour réduire le risque de vulnérabilités liées à la mise en œuvre des contrats d'agence diamantaire.
CertiK continuera à publier de tels articles techniques pour aider davantage de développeurs à développer en toute sécurité. Suivez-nous pour obtenir plus d'informations et d'informations similaires!
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Marchandises sèches : meilleures pratiques de sécurité pour les contrats d'agence de diamants
Les contrats proxy sont un outil important pour les développeurs de contrats intelligents. Aujourd'hui, il existe de nombreux modes de proxy et règles d'utilisation correspondantes dans le système de contrat. Nous avons précédemment décrit les meilleures pratiques de sécurité des contrats de proxy évolutifs.
Dans cet article, nous présenterons un autre modèle de proxy populaire dans la communauté des développeurs, le modèle de proxy en diamant.
Les contrats proxy Diamond, également appelés "diamants", sont un modèle de conception pour les contrats intelligents Ethereum introduits par la proposition d'amélioration Ethereum (EIP) 2535.
Le mode diamant permet à un contrat d'avoir des fonctionnalités illimitées en divisant ses fonctionnalités en contrats plus petits (également appelés à juste titre "aspects"). Diamond agit comme un proxy, acheminant les appels de fonction vers l'aspect approprié.
La conception du modèle en diamant peut résoudre le problème de la limitation de la taille maximale des contrats du réseau Ethereum. En décomposant un gros contrat en aspects plus petits, le modèle en losange permet aux développeurs de créer des contrats intelligents plus complexes et riches en fonctionnalités sans être affectés par les contraintes de taille.
Diamond Brokerage offre une flexibilité énorme par rapport aux contrats évolutifs traditionnels. Ils permettent de mettre à niveau des parties contractuelles, d'ajouter, de remplacer ou de supprimer des parties sélectionnées de fonctions sans toucher aux autres parties.
Cet article fournit une vue d'ensemble d'EIP-2535, y compris une comparaison avec le mode proxy transparent et le mode proxy UUPS largement utilisés, et ses considérations de sécurité pour la communauté des développeurs.
Dans le cadre de l'EIP-2535, un « diamant » est un contrat proxy dont la mise en œuvre fonctionnelle est assurée par différents contrats logiques, appelés « aspects ».
Imaginez qu'un vrai diamant ait différentes faces, appelées facettes, et que les contrats de diamant Ethereum correspondants aient également différentes facettes. Chaque contrat de fonction d'emprunt de diamants est un côté ou une facette différente.
La norme diamant utilise une analogie pour étendre les capacités de la "coupe diamant" pour ajouter, remplacer ou supprimer des facettes et des caractéristiques.
De plus, le Diamond Standard fournit une fonctionnalité appelée "Diamond Loupe" qui renvoie des informations sur les facettes et la présence du diamant.
Par rapport au modèle de procuration traditionnel, le « losange » équivaut au contrat de procuration, et les différents « aspects » correspondent à la réalisation du contrat. Différents aspects d'un agent diamant peuvent partager des fonctions internes, des bibliothèques et des variables d'état. Les composants clés d'un diamant sont les suivants :
Un contrat central qui agit comme un proxy, achemine les appels de fonction vers l'aspect approprié. Il contient un mappage des sélecteurs de fonction aux adresses "d'aspect".
Un contrat unique qui met en œuvre une fonction spécifique. Chaque facette contient un ensemble de fonctions qui peuvent être appelées par le diamant.
est un ensemble de fonctions standard définies dans EIP-2535 qui fournissent des informations sur les sélecteurs de facettes et de fonctions utilisés dans les diamants. Diamond Loupe permet aux développeurs et aux utilisateurs d'inspecter et de comprendre la structure des diamants.
Fonctions pour ajouter, remplacer ou supprimer des facettes dans un diamant et leurs sélecteurs de fonction correspondants. Seules les adresses autorisées (par exemple, le propriétaire du diamant ou un contrat à plusieurs signatures) peuvent effectuer la taille du diamant.
Comme pour les agents traditionnels, lorsqu'un appel de fonction est effectué sur un agent diamant, la fonction de repli de l'agent (fonction de repli) est déclenchée. La principale différence avec le proxy diamant est que dans la fonction de secours, il existe un mappage selectorToFacet, qui stocke et détermine quelle adresse de contrat logique a l'implémentation de la fonction appelée. Il utilise ensuite un appel délégué pour exécuter la fonction, tout comme un proxy traditionnel.
Tous les proxys utilisent la fonction fallback() pour déléguer les appels de fonction à des adresses externes. Vous trouverez ci-dessous la mise en œuvre du proxy diamant et la mise en œuvre du proxy traditionnel.
Il convient de noter que leurs blocs de code d'assemblage sont très similaires, de sorte que la seule différence est l'adresse d'aspect dans l'appel de délégué proxy diamant et l'adresse impl dans l'appel de délégué proxy traditionnel.
La principale différence est que dans le proxy diamant, l'adresse de l'aspect est déterminée par le hashmap du msg.sig (sélecteur de fonction) de l'appelant à l'adresse de l'aspect, tandis que dans le proxy traditionnel, l'adresse impl ne dépend pas de l'entrée de l'appelant.
Fonction de repli de l'agent diamant
Fonction de secours proxy traditionnelle
Le mappage SelectorToFacet détermine quel contrat contient l'implémentation de chaque sélecteur de fonction. Les travailleurs du projet ont souvent besoin d'ajouter, de remplacer ou de supprimer ce mappage du sélecteur de fonction au contrat d'implémentation. EIP-2535 déclare : Pour y parvenir, il doit y avoir une fonction diamondCut(). Vous trouverez ci-dessous un exemple d'interface.
Chaque structure FacetCut contient une adresse de facette et un tableau de sélection de fonctionnalités à quatre octets à mettre à jour dans le contrat de proxy en diamant. FaceCutAction permet d'ajouter, de remplacer et de supprimer des sélecteurs de fonctionnalités. L'implémentation de la fonction diamondCut() doit inclure un contrôle d'accès adéquat, empêcher les collisions d'emplacements, récupérer en cas d'échec, etc.
Afin d'interroger les fonctions et les facettes d'un agent diamanté, nous utilisons la "loupe diamantée". "Diamond Loupe" est un aspect spécial qui implémente l'interface suivante définie dans EIP-2535 :
La fonction facets() doit renvoyer les adresses de toutes les facettes et leurs sélecteurs de fonction à quatre octets. La fonction facetFunctionSelectors() doit renvoyer tous les sélecteurs de fonction pris en charge par un aspect particulier. La fonction facetAddresses() doit renvoyer toutes les adresses de facette utilisées par un diamant.
La fonction facetAddress() doit renvoyer un aspect qui prend en charge le sélecteur donné, ou address( 0 ) s'il n'est pas trouvé. Notez qu'il ne doit pas y avoir plus d'une adresse d'aspect avec le même sélecteur de fonctionnalité.
Étant donné que les proxys diamant délèguent différents appels de fonction à différents contrats de mise en œuvre, il est essentiel de gérer correctement les emplacements de stockage pour éviter les conflits. EIP-2535 mentionne plusieurs méthodes de gestion des emplacements de stockage.
Cet aspect peut déclarer des variables d'état dans la structure. Cet aspect peut utiliser n'importe quel nombre de structures, chacune avec un emplacement de stockage différent. Chaque structure a un emplacement spécifique dans le stockage contractuel. Les aspects peuvent déclarer leurs propres variables d'état, mais ils ne peuvent pas entrer en conflit avec les emplacements de stockage des variables d'état déclarées par d'autres aspects. Une bibliothèque d'échantillons et un contrat de stockage de diamants sont fournis dans EIP-2535, comme illustré dans la figure suivante :
App Store est une version plus spécialisée de Diamond Store. Ce modèle est utilisé pour partager plus facilement et plus facilement les variables d'état des aspects. Une structure de magasin d'applications est définie pour contenir n'importe quel nombre et type de variables d'état requises par une application. Un aspect déclare toujours la structure AppStorage comme première et unique variable d'état, à la position 0 de l'emplacement de stockage. Différents aspects peuvent alors accéder aux variables de cette structure.
Il existe également d'autres stratégies de gestion des emplacements de stockage, y compris un hybride de Diamond Storage et AppStorage. Par exemple, certaines structures sont partagées entre différents aspects, et certaines sont spécifiques à un aspect spécifique. Dans tous les cas, il est très important d'éviter les collisions accidentelles d'emplacements.
Comparaison avec le proxy transparent et le proxy UUPS
Les deux principaux modes proxy actuellement utilisés par la communauté des développeurs Web3 sont le mode proxy transparent et le mode proxy UUPS. Dans cette section, nous comparons brièvement le mode proxy diamant avec les modes proxy transparent et proxy UUPS.
1.EPI-2535 : #Facets,% 20 State% 20 iables% 20 et% 20 Diamond% 20 Stockage
2.EPI-1967 :
4.Implémentation d'OpenZeppelin :
Les solutions proxy et évolutives sont des systèmes plus complexes, et OpenZeppelin fournit des bases de code et une documentation complète pour les proxys évolutifs UUPS, Transparent et Beacon. Cependant, pour le modèle de proxy diamant, bien qu'OpenZeppelin ait affirmé ses avantages, ils ont quand même décidé de ne pas inclure l'implémentation diamant EIP-2535 dans leur bibliothèque.
Par conséquent, les développeurs utilisant des bibliothèques tierces existantes ou implémentant eux-mêmes cette solution doivent l'implémenter avec un soin extrême. Ici, nous avons compilé une liste de contrôle des meilleures pratiques de sécurité à prendre en compte par la communauté des développeurs.
En décomposant la logique contractuelle en modules plus petits et plus faciles à gérer, les développeurs peuvent plus facilement tester et auditer leur code.
De plus, cette approche permet aux développeurs de se concentrer sur des aspects spécifiques de la création et de la maintenance des contrats, plutôt que de gérer une base de code complexe et monolithique. Le résultat final est une base de code plus flexible et modulaire qui peut facilement être mise à jour et modifiée sans affecter les autres parties du contrat.
Source : Aavegotchi Github
Lorsque le contrat de proxy de diamant est déployé, il doit ajouter l'adresse du contrat DiamondCutFacet au contrat de proxy de diamant et implémenter la fonction diamondCut(). La fonction diamondCut() est utilisée pour ajouter, supprimer ou remplacer des facettes et des fonctions, sans DiamondCutFacet et diamondCut(), l'agent diamant ne peut pas fonctionner correctement.
La source: Casque Diamond-3-Hardhat de Mugen
Lors de l'ajout d'une nouvelle variable d'état à une structure de stockage dans un contrat intelligent, elle doit être ajoutée à la fin de la structure. L'ajout d'une nouvelle variable d'état au début ou au milieu d'une structure entraînera l'écrasement des données de variable d'état existantes par la nouvelle variable d'état, et toute variable d'état après la nouvelle variable d'état peut faire référence au mauvais emplacement de mémoire.
Le modèle AppStorage exige qu'une et une seule structure soit déclarée pour le proxy diamant, et que cette structure soit partagée par tous les aspects. Si plusieurs structures sont nécessaires, le modèle DiamondStorage doit être utilisé.
Ne placez pas une structure directement à l'intérieur d'une autre structure, sauf si vous êtes sûr de ne pas avoir l'intention d'ajouter d'autres variables d'état à la structure interne. Il n'est pas possible d'ajouter de nouvelles variables d'état aux structures internes dans une mise à niveau sans écraser les emplacements de stockage de variables déclarés après la structure.
La solution de contournement consiste à ajouter de nouvelles variables d'état à la structure mappée en mémoire au lieu de placer la "struct" directement dans la "struct". Les emplacements de stockage variables dans une carte sont calculés différemment et ne sont pas contigus dans le stockage.
La taille du tableau sera affectée par la taille de la structure. Lorsqu'une nouvelle variable d'état est ajoutée à une structure, elle modifie la taille et la disposition de cette structure.
Cela peut causer des problèmes si la structure est utilisée comme élément dans un tableau. Si la taille et la disposition de la structure changent, la taille et la disposition du tableau changeront également, ce qui peut entraîner des problèmes d'indexation ou d'autres opérations qui reposent sur une taille et une disposition cohérentes de la structure.
Comme pour les autres modèles de proxy, chaque variable doit avoir un emplacement de stockage unique. Sinon, deux structures différentes au même endroit s'écraseraient.
La fonction initialize() est généralement utilisée pour définir des variables importantes, telles que les adresses des rôles privilégiés. S'il n'est pas initialisé lors du déploiement du contrat, un acteur malveillant peut appeler et contrôler le contrat.
Il est recommandé d'ajouter un contrôle d'accès approprié à la fonction d'initialisation/de paramétrage, ou de s'assurer que la fonction est appelée lorsque le contrat est déployé et ne peut pas être appelée à nouveau.
Si un aspect du contrat est capable d'appeler la fonction selfdestruction(), il a le potentiel de détruire l'intégralité du contrat, entraînant une perte de fonds ou de données. Ceci est extrêmement dangereux en mode proxy diamant, car plusieurs aspects peuvent accéder au stockage et aux données du contrat de proxy.
Actuellement, nous voyons de plus en plus de projets adopter le modèle proxy du diamant dans leurs contrats intelligents. Il offre une flexibilité et d'autres avantages par rapport aux proxys traditionnels.
Cependant, la flexibilité supplémentaire peut également signifier une surface d'attaque plus large pour les attaquants. Nous espérons que cet article aidera la communauté des développeurs à comprendre les mécanismes du modèle de proxy diamant et ses considérations de sécurité.
Dans le même temps, l'équipe du projet doit effectuer des tests rigoureux et des audits tiers pour réduire le risque de vulnérabilités liées à la mise en œuvre des contrats d'agence diamantaire.
CertiK continuera à publier de tels articles techniques pour aider davantage de développeurs à développer en toute sécurité. Suivez-nous pour obtenir plus d'informations et d'informations similaires!