Un rapide point sur les risques habituels de recentralisation abusive dans un projet “blockchain” basé sur un smart contract.
Le choix d’une chaîne fragile et/ou centralisée
Le premier risque se situe dans le choix ou la création de la blockchain hébergeant le contrat intelligent . Si vous créez votre propre blockchain, il vous faudra entretenir la motivation des acteurs chargés de la maintenance des nœuds et validateurs de votre chaîne, qu’elle soit indépendante ou autre (sidechain, parachain…). Le choix de la technologie de consensus ou de l’ouverture plus ou moins grande de la blockchain ou sa gouvernance peut nuire à la disponibilité des fonctions de votre contrat intelligent.
En choisissant une blockchain ouverte publique mâture existante, vous pouvez vous dégager de ces écueils habituels mais il reste possible de saboter plus ou moins volontairement la décentralisation de votre solution.
Une solution décentralisée laissant une place importante à l’application décentralisée (dApp) peut diminuer sa dépendance à une chaine en supportant plusieurs chaines. Notre propre application (wallet d’identité décentralisée) a été testé sur Ethereum et BSC (Binance Smart Chain). La première chaîne officiellement supportée à la sortie de notre application sera la BSC et il a été évoqué de supporter une seconde chaine dans les mois à venir. Flare avait d’abord été envisagé mais la solution n’est toujours pas mature et d’autres chaînes compatibles EVM sont en cours d’évaluation.
Le risque des fonctions réservées à un administrateur central
C’est un exercice parfois difficile pour un développeur de smart contract que d’envisager sa propre disparition ou de se retirer les droits (pour éviter toute possibilité de sabotage). Il est pourtant indispensable de comprendre ce qui ne fonctionnerait plus si l’administrateur du contrat n’était plus en capacité d’intervenir ou s’il devenait menaçant.
Dans l’architecture décentralisée des solutions d’identités sur blockchain, la liberté de pouvoir créer des identités et des chaînes de confiance est essentiel et par conséquent :
- Un utilisateur doit pouvoir créer son identité (DID Document)
- Un émetteur doit pouvoir créer son identité (DID Document)
- Un vérificateur doit pouvoir créer son identité (DID Document)
- Un émetteur doit pouvoir prouver son existence légale sans que l’administrateur soit toujours sollicité. Dans notre solution, cela signifie la possibilité pour chaque émetteur de lier son DID Document avec un certificat traditionnel issu d’autorités de certifications indépendantes.
- Un émetteur doit pouvoir créer des traces horodatées
- La création de certaines alertes doit être partageable (service de publication ouvert pour les infos de révocation)
La possible fausse bonne idée des contrats “proxy”
L’utilisation d’un premier “smart contract” en proxy / frontal de la véritable implémentation pour rendre possible des mises à jour est une mauvaise idée si cette capacité de changer de version est centralisée dans les mains d’un seul administrateur qui peut tout aussi bien introduire de nouvelles erreurs ou même rendre la solution inutilisable. Nous n’utiliserons pas de contrat proxy.
Les parcours sans accompagnement doivent être possibles
Dans un smart contract, le paiement de l’accès à certaines fonctions peut être automatisé en rendant ces fonctions “payables”. Cela permet de concevoir plus facilement deux parcours pour de potentiels partenaires :
- un parcours “accompagné” après une prise de contact directe ou indirecte (via un intégrateur)
- un parcours “indépendant” sans même une prise de contact, en lisant la documentation et en créant les transactions nécessaires directement.
Dans les deux cas, les fonctions sont payables en utilisant le token du projet (ici notre token SYL). Les différents tarifs peuvent être en partie modifiés.
Ainsi, le service est maintenu, même si l’entreprise “administratrice” du contrat n’est plus joignable, quelle qu’en soit la raison.
Les derniers pouvoirs limités de l’administrateur
Même avec toutes ces limitations, l’administrateur pourrait encore abuser de deux pouvoirs encore présents :
- Le changement nocif de tarification des fonctions payantes du smart contract (une fourchette de modification par défaut peut servir à limiter les abus).
- La validation/certification d’un émetteur (même s’il le méritait pas).
Ces derniers risques peuvent être mitigés par l’administration via une solution de multi-signature, le paramétrage d’oracles externes et/ou d’une solution de DAO. Nous reparlerons de ces protections supplémentaires dans un futur billet.
[1] How to Write Upgradable Smart Contracts (Smart Contract Versioning)
https://medium.com/swlh/how-to-write-upgradable-smart-contracts-smart-contract-versioning-5ff5ce035732
