Elk upgradebaar smart contract werkt onder de motorkap hetzelfde: gebruikers roepen een proxy contract aan dat de state bewaart, en de proxy stuurt elke aanroep door naar een apart implementatiecontract met de logica. Upgraden betekent de proxy naar een nieuwe implementatie laten wijzen. De verschillen tussen proxy-patronen zitten in waar de upgradelogica staat en hoeveel contracts één implementatie delen.
De belangrijkste proxy-patronen
Transparent proxy. De upgradelogica staat in de proxy, en alleen een admincontract mag die aanroepen. Eenvoudig te doorgronden en veel gebruikt, maar elke aanroep betaalt iets extra gas voor de admincontrole, en de proxy zelf is groter.
UUPS (Universal Upgradeable Proxy Standard). De upgradelogica staat in de implementatie in plaats van in de proxy. Proxies zijn goedkoper om te deployen en aan te roepen. Het risico: wordt een nieuwe implementatie zonder upgradefunctie gedeployed, dan kan het contract nooit meer worden geüpgraded. Goede tooling en tests voorkomen dat.
Beacon proxy. Veel proxies wijzen naar één beacon, en de beacon wijst naar de implementatie. Door de beacon te upgraden, worden alle proxies tegelijk geüpgraded. Ideaal als u veel exemplaren van hetzelfde contract deployt, zoals één vault of account per gebruiker.
Diamond (EIP-2535). Eén proxy stuurt verschillende functies naar verschillende implementatiecontracts, facets genoemd. Zo omzeilt u de maximale contractgrootte en bouwt u zeer modulaire systemen, ten koste van flink meer complexiteit. Wij raden het alleen aan als het systeem het echt nodig heeft.
Valkuilen waar wij op letten
- Storage-botsingen: proxy en implementatie delen dezelfde opslag. Wij volgen de storage slots van EIP-1967 en controleren de indeling automatisch vóór elke upgrade.
- Onbeveiligde initializers: een initializer die iedereen kan aanroepen, op de proxy of op de kale implementatie, is een bekende aanvalsroute.
- Botsende function selectors: een proxyfunctie met dezelfde selector als een implementatiefunctie kan die overschaduwen. De transparent- en UUPS-patronen zijn ontworpen om dit te voorkomen; zelfgebouwde proxies vaak niet.
- Self-destruct en delegatecall in implementaties: gevaarlijke patronen die elke proxy die van de implementatie afhangt onbruikbaar kunnen maken.
Veelgestelde vragen over proxy-patronen
Welk proxy-patroon moeten wij gebruiken?
Voor de meeste losse contracts is UUPS een goede standaard: goedkopere en eenvoudigere proxies. Transparent proxies blijven een degelijke keuze als u de upgradelogica liever buiten de implementatie houdt. Gebruik beacons voor veel identieke exemplaren, en diamonds alleen als modulariteit of contractgrootte dat echt vereist.
Kunnen wij later van proxy-patroon wisselen?
Niet rechtstreeks; het patroon is onderdeel van de gedeployde contracts. Wisselen betekent een migratie naar nieuwe proxies, dus het loont om aan het begin goed te kiezen.
Werken proxies op Solana?
Solana heeft ze niet nodig: programma's zijn standaard upgradebaar via een upgrade authority, en state staat in aparte accounts. Zie Solana ontwikkeling.
Wie is eigenaar van de code?
Het eigendom van de broncode wordt contractueel vastgelegd, en de code kan volledig van u zijn, inclusief documentatie en tests.
Onderdeel van onze smart contract ontwikkeling. Audit gepland? Zie smart contract audit ondersteuning.
Kies het juiste patroon
Vertel ons wat u bouwt en hoe het zich moet ontwikkelen. Wij adviseren een proxy-patroon en implementeren het veilig.