Een proxycontract is een smart contract dat alle aanroepen doorstuurt naar een apart implementatiecontract met de eigenlijke logica. Omdat gepubliceerde smart-contractcode niet kan worden gewijzigd, zijn proxy's de standaardmanier om contracten upgradebaar te maken: gebruikers en andere contracten werken altijd met het vaste adres van de proxy, terwijl de eigenaar de proxy naar een nieuwe implementatie kan laten verwijzen om fouten te herstellen of functies toe te voegen. De gegevens blijven in de proxy, zodat saldi en instellingen een upgrade overleven.
Hoe werkt een proxycontract?
- delegatecall: de proxy stuurt elke aanroep door met
delegatecallvan de EVM, die de code van de implementatie uitvoert in de context van de proxy, met de opslag en het saldo van de proxy. - Implementatieadres: de proxy bewaart het adres van de huidige implementatie in een vaste opslagplek, gestandaardiseerd in EIP-1967, zodat het nooit botst met de eigen variabelen van de logica.
- Upgrade: een bevoegd account wijzigt dat adres naar een nieuwe implementatie; vanaf de volgende aanroep geldt de nieuwe logica.
- Initializers in plaats van constructors: omdat de constructor van de implementatie nooit in de context van de proxy draait, gebeurt de inrichting in een
initialize-functie die zo beveiligd moet zijn dat die maar één keer kan worden aangeroepen.
Veelgebruikte proxypatronen
- Transparent proxy: de upgradelogica zit in de proxy en is alleen toegankelijk voor de beheerder, zodat aanroepen van beheerder en gebruikers strikt gescheiden blijven.
- UUPS (ERC-1822): de upgradelogica zit in de implementatie, waardoor de proxy lichter en goedkoper is; een implementatie zonder upgradelogica beëindigt de upgradebaarheid.
- Beacon proxy: veel proxy's lezen hun implementatie uit één beaconcontract, zodat een hele set contracten in één stap kan worden geüpgraded.
- Diamond (ERC-2535): één proxy stuurt verschillende functies naar verschillende implementatiecontracten ("facets"), voor zeer grote systemen.
Risico's en bestuur
Upgradebaarheid is macht: wie de upgrade beheert, kan veranderen wat het contract doet, ook hoe het met het geld van gebruikers omgaat. Die sleutel hoort daarom in een multisig, bij voorkeur achter een timelock zodat gebruikers wijzigingen zien aankomen, of onder bestuur van een DAO. Technische valkuilen zijn botsingen in de opslagindeling tussen versies, niet-geïnitialiseerde implementatiecontracten en botsende functieselectors. Tools zoals de OpenZeppelin Upgrades-plugins controleren de compatibiliteit van de opslag automatisch. Sommige projecten schakelen de upgradebaarheid bewust uit zodra een systeem volwassen is. Zie onze proxypatronen voor smart contracts en upgradebare contracten.
Veelgestelde vragen over proxycontracten
Waarom kan een smart contract niet gewoon worden bijgewerkt?
Gepubliceerde bytecode op Ethereum is onveranderlijk. Een proxy houdt adres en gegevens vast en verwisselt de logica erachter, wat hetzelfde effect geeft als een update.
Wat is het verschil tussen een transparent proxy en UUPS?
Bij een transparent proxy zit de upgradefunctie in de proxy zelf. Bij UUPS zit die in het implementatiecontract. Dat bespaart gas, maar elke nieuwe versie moet de upgradefunctie dan correct bevatten.
Zijn upgradebare contracten minder veilig?
Ze voegen een vertrouwensaanname toe: gebruikers moeten vertrouwen op wie kan upgraden. Met een multisig, timelock en transparant bestuur is dat risico aanvaardbaar te maken; zonder die maatregelen is een upgradesleutel één kwetsbaar punt.
Wat is een storage collision?
Wanneer een nieuwe implementatie haar variabelen anders indeelt dan de oude, waardoor bestaande gegevens als de verkeerde variabele worden gelezen. Regels voor de opslagindeling en automatische controles voorkomen dat.