Jump Crypto : Comment garantir l'indépendance de la gouvernance par délégation de jetons via le code ?
TechFlow SélectionTechFlow Sélection
Jump Crypto : Comment garantir l'indépendance de la gouvernance par délégation de jetons via le code ?
Le titulaire peut accorder librement des autorisations, et l'agent peut voter indépendamment.
Dédié à des analyses Web3 approfondies
Auteurs : Nihar Shah, Joe Howarth
Traduction : aididiaojp.eth, Foresight News
TL;DR
-
Bien que les programmes de délégation de jetons permettent une gouvernance robuste, leur indépendance est limitée car les détenteurs peuvent révoquer immédiatement leurs pouvoirs de vote.
-
Pour les détenteurs exigeant une indépendance, tels que les institutions, nous proposons d'intégrer des périodes de verrouillage explicites dans les contrats de délégation.
-
Nous illustrons cela via un contrat Maker enrichi de fonctionnalités supplémentaires : possibilité de contourner le verrouillage si la décision est mutuelle, ou activation d'une voie d'urgence par le détenteur.
Introduction
Ces deux dernières années, le concept de délégation de jetons est devenu de plus en plus populaire. Il permet aux détenteurs de transférer leur droit de vote sur la chaîne à des tiers. De grands protocoles comme Maker, Compound et Uniswap utilisent cette méthode pour gérer leur gouvernance communautaire. La délégation améliore la qualité de la gouvernance et stimule le développement de communautés dynamiques incluant des groupes étudiants, des organisations à but non lucratif et des leaders communautaires.
La délégation présente deux avantages spécifiques. Le premier avantage direct est d’améliorer l’efficacité de la gouvernance. Sans programme de délégation, certains membres ayant peu d’intérêt ou manquant de temps devraient malgré tout examiner des dizaines de propositions complexes pour participer au vote. Grâce à la délégation, des représentants spécialisés peuvent prendre des décisions plus éclairées, cohérentes et significatives. Comme dans les démocraties représentatives, ce modèle s’avère souvent supérieur à la démocratie directe — y compris dans l’écosystème cryptographique.
Depuis l’année dernière, un second avantage commence à se dégager : la neutralité. Certains détenteurs détiennent de grandes quantités de jetons et peuvent aussi posséder des actifs dans des protocoles concurrents. Ils peuvent vouloir contribuer à construire une communauté décentralisée et impartiale, et la délégation constitue alors un moyen de prouver leur neutralité.
Ce deuxième avantage ne repose pas uniquement sur le mécanisme de délégation lui-même, mais nécessite des conditions spécifiques assurant l’indépendance du représentant vis-à-vis du détenteur. Par exemple, Jeff Amico d’a16z a souligné dans un article l’importance cruciale de « permettre à chaque représentant de voter indépendamment du détenteur selon son propre jugement ». Or, la plupart des systèmes actuels de délégation n’imposent pas cette indépendance, qui peut même être sciemment compromise avant des votes importants.
Cet article propose une solution simple basée sur le code : intégrer une période de verrouillage dans le protocole, empêchant le détenteur de révoquer le pouvoir de vote du représentant pendant cette période. Nous fournissons également une implémentation de référence compatible avec le protocole Maker, incluant des options de contournement bilatéral (non urgent) ou unilatéral (urgence).
Perdu dans la délégation : la révocation du mandat
Bien que perçue comme prometteuse, la délégation de jetons n’est pas sans critiques. En théorie comme en pratique, ces programmes peuvent violer les principes normatifs de délégation et affaiblir les objectifs d’une gouvernance solide.
Par exemple, Chris Blec de DeFi Watch insiste activement sur la clarté des choix et interactions dans les programmes de délégation préconisés par a16z. Selon lui, lorsque des propositions sont approuvées uniquement par un ou deux représentants, cela soulève des questions sur les liens entre votants et détenteurs.
Ces risques sont bien réels. Prenons le cas du sondage 819 de Maker, plus connu sous le nom de « LOVE vote ». Ce scrutin portait sur le choix d’un superviseur de prêt et a suscité un débat communautaire intense autour de la décentralisation versus efficacité. Extrêmement controversé, il a battu tous les records de participation dans l’histoire de Maker — record toujours valide lors de la rédaction de cet article. Luca Prosperi a documenté en détail le processus, centré principalement sur les aspects liés à la délégation.
Cela montre qu’il est possible de contourner le système de délégation lors de propositions critiques. Par exemple, Rune Christensen, fondateur de Maker, a modifié ses délégations pendant la période de vote, influençant ainsi le résultat. Bien qu’il se soit publiquement opposé à la proposition, il avait presque entièrement délégué ses jetons MKR. Pendant la fenêtre de vote de deux semaines, il a révoqué les mandats des représentants ayant voté pour ou se sont abstenus, puis a réattribué ces jetons à d’autres représentants inactifs. Cette redistribution semble avoir été une tactique destinée à masquer le désaccord fondamental entre Christensen et les représentants favorables à la proposition. Trois jours après la fin du vote, Christensen a réaffecté les mandats aux représentants ayant précédemment voté « pour ». Ce schéma est illustré ci-dessous :
Solution juridique
Les programmes de délégation doivent être renforcés. Une approche consiste à utiliser des contrats juridiques pour garantir l’indépendance et l’exécution du mandat, par exemple en imposant une durée minimale de délégation. Cela réduit le risque que le détenteur retire brutalement le pouvoir de vote en cas de conflit d’intérêt. Plus généralement, cela limite la pression exercée par le détenteur sur son représentant.
Ce principe est appliqué via des contrats juridiques publiés dans un dépôt GitHub. L'article 6 du contrat précise : « Afin d’éviter que le représentant ne remplisse pas ses obligations de gouvernance, la durée initiale du présent accord est de [N] mois à compter de la date d’entrée en vigueur, et le détenteur ne peut résilier cet accord qu’à l’expiration de cette période. »
Toutefois, les mécanismes juridiques sont suboptimaux. Même si nous ne remettons pas en cause la bonne foi d’a16z, ceux qui l’imitent pourraient ne pas avoir les mêmes intentions. L’exécution des contrats juridiques est coûteuse, introduit des asymétries de pouvoir et repose sur des négociations opaques. Entre les mains de détenteurs indifférents, ces contrats offrent peu de contrôle réel.
En raison de leur dépendance excessive à l’égard d’hypothèses de transparence et d’exécution, les contrats juridiques constituent un mécanisme inadapté pour généraliser et renforcer les programmes de délégation.
Proposition : du code, pas du droit
Nous proposons ici une solution simple : utiliser un contrat intelligent plutôt qu’un contrat juridique. Autrement dit, intégrer directement une période de verrouillage dans le contrat intelligent afin de protéger l’indépendance du représentant. Cette approche est hautement transparente a priori, facilement vérifiable a posteriori, et surtout, techniquement simple à mettre en œuvre.
Nous utilisons le contrat Maker comme exemple. La logique centrale de délégation réside dans le contrat VoteDelegate.sol, notamment les fonctions lock et free, qui suffisent largement aux besoins. Le détenteur utilise la fonction lock pour bloquer ses jetons et attribuer son pouvoir de vote, et la fonction free pour récupérer ses jetons et droits associés.
Quelques modifications simples peuvent être apportées. Premièrement, une variable _lockupPeriod est définie lors de l’appel au constructeur du contrat. Deuxièmement, le détenteur appelle la fonction initialUnlock pour déclencher un compte à rebours. Troisièmement, la fonction free est légèrement modifiée pour vérifier que la période de verrouillage est respectée.
En intégrant une période de verrouillage, les programmes de délégation deviennent plus fiables et transparents, avec l’indépendance du représentant garantie par le code, non par le droit.
Fonction de contournement d'urgence
Bien sûr, la période de verrouillage n’est pas toujours souhaitable, et le contrat intelligent peut être adapté en conséquence.
Premièrement, le représentant et le détenteur peuvent convenir mutuellement de mettre fin à la délégation. Une fonction de contournement peut alors être fournie, implémentée par une simple fonction delegatorBypassLockup permettant au représentant d’abandonner immédiatement le pouvoir de vote. (Notez que le paramètre isDelegatorBypassEnabled peut activer cette fonction au lancement du contrat.)
Deuxièmement, il peut exister des situations d’urgence où le détenteur souhaite contourner unilatéralement le verrouillage, par exemple si le représentant agit de manière irresponsable ou hostile — bien que ces cas soient rares.
Une bonne solution consiste à autoriser le détenteur à brûler irrévocablement une partie de ses jetons pour accéder à une sortie d’urgence. Lors de l’initialisation, le propriétaire définit un paramètre EmergencyUnlockBurnPercent (pouvant aller jusqu’à 100 %). La fonction free est alors modifiée pour vérifier si le détenteur choisit cette voie. Dans ce cas, seule la fraction non brûlée des jetons est restituée, le reste étant détruit. Voici un extrait illustrant cette logique :
Dépôt complet
L’ensemble des modifications et fonctions discutées dans cet article est disponible dans un dépôt public GitHub, incluant toutes les adaptations nécessaires à l’architecture Maker. Nous invitons aux retours et suggestions, et considérons que ce contrat est déjà déployable en production.
Vision future : la composable
Les programmes de délégation peuvent devenir encore plus riches. Nous pensons que la composable des contrats de délégation ouvrira la prochaine vague d’innovation. Et si un représentant pouvait lui-même déléguer son droit de vote à un autre ?
Cette relation pourrait renforcer l’indépendance du représentant final. Par exemple, un détenteur pourrait confier ses jetons à un groupe étudiant, qui à son tour délègue ces droits à des membres individuels figurant sur une liste de gouvernance, sans révéler leurs identités au détenteur initial. Ainsi, même s’il voulait exercer une pression indirecte, le détenteur ne saurait pas à qui s’adresser ni qui a voté contre ses intérêts.
La composable peut aussi s’associer à des contrats plus sophistiqués pour permettre des interactions créatives entre détenteurs et représentants. Par exemple, un détenteur pourrait être autorisé à retirer unilatéralement ses jetons du représentant, mais ne les recevoir qu’après expiration de la période minimale de verrouillage. Des contrats composites rendraient cela possible.
Conclusion
Le verrouillage ne convient pas à tous. Ceux attirés par l’efficacité initiale de la délégation trouveront le verrouillage inutile. Toutefois, il est très utile pour les détenteurs souhaitant préserver une posture neutre (fondateurs, institutions, etc.).
Ce qui compte, c’est la clarté : certains détenteurs veulent accorder une grande indépendance à leurs représentants, tandis que d’autres préfèrent des relations plus contrôlées. Actuellement, tous sont contraints d’utiliser le même contrat intelligent, exprimant leurs intentions via des déclarations publiques ou des documents juridiques hétéroclites. Notre proposition permet à chaque détenteur de choisir son cadre idéal — durée de verrouillage, fonction de contournement mutuel, paramètres d’autodestruction d’urgence. Tout se déroule sur la chaîne, visible par tous, sans besoin de surveillance.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
