De meeste smart contracts hebben functies die niet iedereen mag aanroepen: nieuwe tokens minten, het contract pauzeren, fees wijzigen, de code upgraden of geld opnemen. Toegangscontrole bepaalt wie wat mag aanroepen. Ontbreekt die of klopt die niet, dan kan iedereen die functies aanroepen, en precies daar begint een hele categorie hacks.
Ownable of rolgebaseerd?
Het eenvoudigste model is één owner die alles mag. Dat is prima voor een klein contract tijdens de ontwikkeling, maar in productie betekent het dat één sleutel het hele systeem beheert. Rolgebaseerde toegangscontrole verdeelt de macht over aparte rollen, zoals een minter, een pauzeerder, een feebeheerder en een upgrader, elk toegewezen aan het account dat die rol nodig heeft en niets meer.
Meestal bouwen wij op de goed gereviewde implementaties van OpenZeppelin en ontwerpen wij de rolstructuur rond hoe uw organisatie werkelijk werkt.
Principes die wij toepassen
- Least privilege: elke rol kan alleen wat nodig is. Een operationele bot die in een noodgeval pauzeert, hoeft niet ook te kunnen minten.
- Machtige rollen in een multisig: admin- en upgraderollen zitten in een multisig, niet in de wallet van één persoon.
- Langzame wijzigingen voor grote besluiten: rolwijzigingen en kritieke parameters gaan via een timelock, zodat gebruikers ze zien aankomen.
- Noodpauze: een pauzefunctie die een snel reagerende rol kan activeren, terwijl het opheffen van de pauze meer handtekeningen vraagt.
- Veilige overdracht: eigendomsoverdracht in twee stappen, zodat adminrechten niet door een typfout naar een verkeerd adres gaan.
- Geteste rechten: tests die niet alleen controleren dat de juiste accounts kunnen handelen, maar ook dat elk ander account wordt geweigerd.
Veelgemaakte fouten
Een functie die beperkt had moeten zijn, maar dat niet was. Een initialisatiefunctie in een upgradebaar contract die iedereen kan aanroepen. Een deployer-wallet die maanden na de launch nog alle rollen heeft. Dit is eenvoudig te voorkomen bij het ontwerp en pijnlijk om achteraf te ontdekken.
Veelgestelde vragen over toegangscontrole in smart contracts
Wat is het verschil tussen Ownable en AccessControl?
Ownable geeft alle rechten aan één owner-adres. AccessControl definieert meerdere rollen, elk met eigen rechten en een eigen beheerder. Voor productiesystemen met meer dan één soort bevoorrechte actie is rolgebaseerde toegangscontrole bijna altijd de betere keuze.
Kunnen rollen na deployment worden gewijzigd?
Ja, als het contract daarvoor is ontworpen. Rollen kunnen worden toegekend en ingetrokken door de beheerder van die rol. Wij raden aan die beheerder achter een multisig te plaatsen en, bij gevoelige rollen, achter een timelock.
Moeten wij het eigendom opgeven (renounce)?
Alleen als het contract echt nooit meer een adminactie nodig heeft. Renouncen maakt een contract onveranderlijk, wat vertrouwen geeft maar ook de mogelijkheid wegneemt om op problemen te reageren. Vaak is een multisig met timelock de betere balans.
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.
Zet de rechten goed neer
Vertel ons welke acties uw contracts nodig hebben en wie ze mag uitvoeren. Wij ontwerpen een rolstructuur die veilig en werkbaar is.