Comment les SuperVaults utilisent des preuves de merkle pour verrouiller ce que le code peut toucher à vos fonds 🔐 Chaque coffre DeFi doit interagir avec des protocoles externes - dépôts dans des sources de rendement, approbations de jetons, rachats. Mais comment s'assurer que seules les opérations approuvées peuvent s'exécuter ? Les SuperVaults résolvent cela avec une couche de validation de preuve de merkle. L'idée principale - Chaque action autorisée est une feuille dans un arbre de merkle : hash(hookAddress + encodedArgs) Vous voulez déposer des USDC dans Yearn ? Cette combinaison exacte - l'adresse du hook de dépôt + le coffre Yearn + USDC - doit exister en tant que feuille dans l'arbre. Pas de preuve = la transaction échoue. Mais ce n'est pas tout, les supervaults ont un modèle de sécurité à deux niveaux : 1️⃣ Arbre Global (par chaîne) - Opérations génériques que tout coffre peut effectuer. Dépôts, approbations, échanges. Rien de complexe ici. 2️⃣ Arbre du Gestionnaire (par coffre) - Opérations spécifiques à la stratégie qui peuvent déplacer des fonds. Rachats, transferts. Chaque coffre a son propre arbre avec des destinations sur liste blanche. Cette séparation signifie que même si quelqu'un compromet la configuration globale, il ne peut pas ajouter des destinations de retrait arbitraires. Celles-ci vivent dans des arbres de gestionnaires spécifiques aux coffres. Ce qui est validé - Pas chaque paramètre - juste ceux critiques pour la sécurité. Pour un hook d'approbation, nous validons (jeton, dépensier) mais pas le montant. Les arguments de merkle sont la frontière de confiance. Les mises à jour de la racine ont un délai de verrouillage. On ne peut pas simplement pousser une racine malveillante et vider dans le même bloc. Les changements sont proposés → attendus → exécutés. Cela donne aux systèmes de surveillance le temps de signaler des mises à jour suspectes. Pourquoi les arbres de merkle - - Taille de preuve O(log n) - un arbre avec 10 000 opérations approuvées nécessite toujours ~13 hachages pour prouver l'appartenance - Déterministe - la même configuration produit toujours la même racine - La vérification on-chain est bon marché - il suffit de hacher le chemin de preuve et de le comparer à la racine stockée. Le résultat : un coffre qui peut interagir avec des dizaines de protocoles et des milliers de combinaisons de jetons/sources de rendement, mais uniquement les combinaisons exactes approuvées dans la configuration. Tout le reste échoue.