<h1>Smart Contract Upgradability</h1>
Smart contract upgradability enables evolving a deployed contract’s behavior without a full redeploy, preserving state and external interactions. It relies on proxy-based architectures and rigorous governance.
La Smart Contract Upgradability est une capacité qui permet aux contrats déployés de recevoir des modifications à leur logique sous-jacente sans perdre leur état stocké ni interrompre les interactions en cours. Ceci est généralement réalisé en séparant le stockage de la logique et en acheminant les appels via une couche upgradeable telle qu'un proxy. Le proxy stocke tout l'état tandis que les appels de délégation exécutent la logique d'un contrat d'implémentation. Les patterns upgradeable incluent les transparent proxies et UUPS, souvent implémentés avec des frameworks tels que OpenZeppelin Upgrades. Les considérations clés sont la préservation de la disposition du stockage, la garantie d'une initialisation sûre au lieu des constructeurs, et la mise en œuvre d'un contrôle d'accès et d'une gouvernance robustes pour les upgrades. Les risques de sécurité incluent le compromis des clés d'administrateur, les vetos d'upgrade et les mauvaises configurations. La vérification et les tests sont essentiels, la vérification formelle servant de discipline de correction plutôt que de mécanisme d'upgrade en soi. Les conseils pratiques incluent l'audit des chemins d'upgrade, la répétition des canary upgrades et l'utilisation de chaînes d'outils établies qui imposent la compatibilité du stockage et la sécurité de l'initialisation.
graph LR
Center["<h1>Smart Contract Upgradability</h1>"]:::main
Rel_smart_contract_wallets["smart-contract-wallets"]:::related -.-> Center
click Rel_smart_contract_wallets "/terms/smart-contract-wallets"
Rel_smart_contract_security_auditing["smart-contract-security-auditing"]:::related -.-> Center
click Rel_smart_contract_security_auditing "/terms/smart-contract-security-auditing"
Rel_smart_contract_exploits["smart-contract-exploits"]:::related -.-> Center
click Rel_smart_contract_exploits "/terms/smart-contract-exploits"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explique-moi comme si j'avais 5 ans
Generated ELI5 content
🤓 Expert Deep Dive
Generated expert content
❓ Questions fréquentes
Why is smart contract upgradability important?
It enables security patches and feature updates without breaking existing state or user interactions.
What are common upgrade patterns?
Proxy based patterns such as Transparent Proxy and UUPS, with storage preserved in the proxy and logic in the implementation. Standards like EIP 1967 guide slot layout.
What are main risks?
Admin key compromise, storage layout mismatch, upgrade vetting failures, and governance risks can lead to breaches or broken state.
How can I upgrade securely?
Use battle tested frameworks like OpenZeppelin Upgrades, perform thorough testing, adopt timelocks or multisig governance, and validate storage compatibility.
How does initialization differ from constructors?
Upgradeable contracts use initializer functions to set up state since constructors execute only on deployment and do not run after upgrades.
Is formal verification required for upgrades?
Formal verification helps establish correctness but is not required for upgrading; it complements testing and review.