Éric Zhang
Gouvernance quadratique : qu’est-ce qui fonctionne et qu’est-ce qui ne fonctionne pas ?
11 juillet 2022
Éric Zhang
– Une exploration approximative des contraintes du monde réel du vote quadratique et des solutions possibles
Pour TL;DR, passez à Conclusion.
La gouvernance quadratique s'est avérée utile dans la gouvernance DAO, le financement open source et au-delà. Parallèlement, il présente également un grand potentiel pour être utilisé dans des systèmes de gouvernance non cryptographiques tels que la gouvernance d'entreprise et même les élections politiques.
La forme primitive de gouvernance quadratique est le vote quadratique (QV)(https://en.wikipedia.org/wiki/Quadratic_voting). L'idée derrière QV est de permettre aux participants d'un système de gouvernance d'exprimer leur degré de préférences tout en limitant les préférences extrêmes (notamment celles des baleines). Pour atteindre cet objectif, Glen Weyl et al(https://www.aeaweb.org/articles?id=10.1257/pandp.20181002). a proposé qu'un crédit de vote (appelé à l'origine « crédit vocal ») soit attribué aux électeurs qui participent à la gouvernance, et que le processus de vote consomme des crédits vocaux. Le coût des crédits vocaux par vote augmente si l'on continue de voter pour une proposition, ce qui limite le niveau d'influence que les baleines peuvent imposer sur les résultats du vote. Le vote quadratique a été expérimenté dans les mondes crypto et non crypto. Récemment, le tour de vote de la communauté ETHDenver (https://dorahacks.io/grant/ethdenver22) a utilisé le vote quadratique pour la distribution de fonds de contrepartie. Dans le monde réel, le Colorado Democratic Caucus)(https://en.wikipedia.org/wiki/Quadratic_voting#Applications) a utilisé le vote quadratique pour décider des priorités législatives.
Le financement quadratique (QF)(https://vitalik.ca/general/2019/12/07/quadratic.html) combine le vote avec le don et crée un algorithme pour calculer la distribution des fonds de contrepartie via les dons individuels. Le financement quadratique a été adopté par DoraHacks, Gitcoin et certains autres protocoles de financement crypto-natifs. Plus de 30 cycles de financement quadratiques ont été hébergés sur DoraHacks.io(https://dorahacks.io/grant). Le financement quadratique permet aux membres de la communauté de n'importe quel écosystème de s'engager dans des propositions et des BUIDLers à un stade précoce. Cependant, il souffre simultanément de plusieurs problèmes, notamment une augmentation des inégalités de répartition, la forge d’identité, les attaques des sybils et la collusion.
En fin de compte, tout dépend de l’échelle des systèmes de gouvernance. Considérez les systèmes de gouvernance comme des machines de distribution. Si un système ne distribue que 100 $, il n’y aura probablement pas beaucoup de faux comptes. Lorsqu'il distribuera 100 000 $, il y aura probablement des attaques de robots et de sybils. Lorsqu’il distribue 10 000 000 $, il est très probable qu’une collusion sophistiquée, des attaques de sybil et d’autres problèmes surgissent.
Dans cet article, explorons les contraintes des systèmes de gouvernance quadratiques basés sur des pratiques du monde réel et discutons des solutions potentielles à ces problèmes. En fin de compte, plus nous résolvons de problèmes, plus nous pouvons étendre la gouvernance quadratique.
Défis des systèmes de gouvernance quadratiques
En pratique, un système de gouvernance quadratique peut être construit avec un modèle en trois phases : inscription, vote et correspondance.
Un cycle QV/QF en trois phases
Bien que cela semble simple et direct, si vous construisez réellement un tel système et l’utilisez dans une véritable gouvernance, vous serez confronté à des problèmes à presque chaque étape. Examinons maintenant le système et décrivons certains des obstacles que nous et d’autres avons déjà rencontrés.
Inscrivez-vous : si le système met les électeurs sur liste blanche ? Si oui, comment les électeurs peuvent-ils être inscrits sur la liste blanche ? Si non, comment prévenir les abus d’utilisateurs malveillants ?
Vote : les électeurs votent pour un certain ensemble d'objectifs (BUIDL, projets, propositions, biens publics ou tout ce qui doit être sélectionné/financé).
Match/Distribution : s'il existe un pool de financement à distribuer, il sera adapté aux objectifs en fonction des résultats du vote. Une analyse et des ajustements post-vote pourraient s’appliquer.
En plus des questions ci-dessus, il y a bien d’autres problèmes auxquels il faut réfléchir. Lorsque le système évoluera, les participants travailleront-ils les uns avec les autres pour s'entendre ? Et comment prévenir la collusion ?
Il peut également y avoir des problèmes plus subtils et spécifiques à des cas d'utilisation, pour n'en nommer que quelques-uns :
Comment vérifier en continu la légitimité d’une cible pour obtenir un financement lors d’un tour de table QF ?
Comment vérifier l’identité des électeurs tout en préservant la vie privée des électeurs ?
Comment connaître les votes de Sybil et gérer ces votes si des attaques de Sybil se produisent déjà ?
Comment lutter contre les inégalités s’il existe d’énormes écarts de financement entre les objectifs ?
Quelle est la complexité des solutions à ces problèmes ?
Dans cet article, nous nous concentrons sur trois catégories de problèmes les plus pertinents pour faire évoluer la gouvernance quadratique : la vérification d'identité / l'attaque Sybil, la collusion et l'inégalité de distribution.
Sybil Résistance et identité électorale
La résistance de Sybil a été jusqu’à présent l’un des sujets les plus discutés en matière de vote quadratique et de financement quadratique. Par rapport aux systèmes 1p1v ou 1stake1vote, le fractionnement de compte peut générer plus de votes dans le vote quadratique et une plus grande zone de support dans le financement quadratique, donc plus de fonds de contrepartie.
En théorie, les attaques sybil peuvent être totalement évitées si le système est sécurisé et si la population électorale est petite, car vous pouvez mettre tout le monde sur liste blanche et connaître tout le monde avant qu'ils ne commencent à voter. Un exemple concret est le vote au congrès. Chaque représentant est connu et il n’y en a qu’un petit groupe, ne dépassant généralement pas quelques centaines de personnes. Il n’est pas coûteux du tout de mettre tout le monde sur liste blanche lorsque tout le monde se connaît. Par conséquent, lorsque le Colorado Democratic Caucus a utilisé le vote quadratique, il n’aurait dû y avoir aucune crainte d’attaques de sybilles ou de falsification d’identité.
Cependant, la situation est différente lorsqu'un plus grand groupe de personnes utilise le vote quadratique, ou dans le cas d'un financement quadratique, où les contributeurs communautaires peuvent venir de n'importe où. Notamment, les méthodes d'authentification Web2 telles que l'enregistrement GitHub/e-mail ne sont PAS du tout un moyen de prévenir les attaques Sybil, car elles peuvent être facilement créées, et même l'historique du compte peut être falsifié. Avec une population électorale importante, les systèmes de gouvernance quadratiques sont particulièrement vulnérables aux attaques de sybil, car forger des identités et des comptes pour voter fait une grande différence !
Pour répondre aux attaques sybil, des systèmes d'analyse sybil post-round(https://medium.com/block-science/operationalizing-the-gitcoindao-anti-sybil-process-7f2595544f44) ont été développés. Ces systèmes analysent principalement les données de vote et identifient les comptes Sybil potentiels et les comportements Sybil, puis les suppriment. Bien que l'analyse post-tour soit utile, elle présente quelques problèmes.
L’analyse ne peut avoir lieu qu’après la fin du vote et prend du temps. La communauté doit attendre pendant une période de grâce, et le ressentiment pourrait augmenter.
Le dilemme de l’open source. Un système de détection de sybil open source sera soumis à d'autres attaques, et souvent le développement de nouvelles attaques sybil est plus facile que le développement d'outils anti-sybil. D’un autre côté, un système de détection de sybil de source proche ne sera pas entièrement fiable.
Les attaquants peuvent toujours trouver des moyens de déjouer le système, tandis que le système d'analyse sybil ne peut pas être amélioré et modifié rapidement, mais l'attaquant le peut.
Changer/ajuster les résultats pourrait entraîner des différends et de la méfiance
Par conséquent, il est important de gérer les attaques de sybils avant et pendant le vote. La question est : comment pouvons-nous vérifier l'identité des électeurs ? (https://0xparc.org/blog/zk-id-1)
Examinons maintenant quelques approches existantes/à venir : KYC, liste blanche, vérification de compte social, NFT/Soul-bound tokens (SBT) et zk-identity.(https://0xparc.org/blog/zk-id-2)
Dans le même temps, étant donné que chaque méthode de vérification d'identité comporte ses propres compromis, nous utilisons en outre les mesures suivantes pour évaluer les compromis : résistance à Sybil, absence d'autorisation, confidentialité et complexité.
La résistance Sybil est ici un objectif majeur, du moins pour la gouvernance de la blockchain.
Le caractère sans autorisation est important car de nombreuses communautés souhaitent rester ouvertes à un large public, et les personnes inscrites sur liste blanche/KYC peuvent limiter leur potentiel de croissance. Actuellement, le coût des méthodes de liste blanche ou de KYC est très élevé.
La confidentialité est fondamentale pour permettre aux gens d’exprimer leurs véritables opinions.
La complexité correspond à la difficulté (en termes de coûts d’ingénierie et d’exploitation) de construire et d’utiliser ces méthodes dans la pratique.
Nous examinons ces compromis sous différentes dimensions : ouverture contre résistance au sybil, confidentialité contre complexité.
Résistance de Sybil et compromis sans autorisation
Compromis entre confidentialité et complexité du système (notez que les identités zk ont de nombreuses propriétés préférées mais nécessitent la construction d'infrastructures beaucoup plus complexes)
De plus, il existe différents types de communautés. Chaque communauté devrait choisir le meilleur compromis pour elle-même lors du choix des méthodes de vérification des électeurs. Un club fermé peut simplement utiliser la liste blanche, une communauté DAO subventionnée peut utiliser plusieurs méthodes ensemble pour maximiser sa fiabilité et sa crédibilité, si sa capacité d'ingénierie le permet.
Nous pouvons également examiner différentes communautés en fonction de la population électorale par rapport à l'ouverture.
Pour les petites communautés fermées, presque toutes les méthodes de vérification sont valables. Mais par souci de simplicité, la liste blanche, le jalonnement et les authentifications Web2 sont probablement les plus simples.
Pour les grandes communautés fermées, NFT/SBT (avec attestation privée si la confidentialité est une préoccupation majeure) et le jalonnement sont probablement de bons choix, ou combinés avec d'autres.
Pour les communautés vastes et ouvertes, des approches telles que zk-identity sont la solution à long terme. Par exemple, l’élection présidentielle américaine de 2020 a donné lieu à de nombreux différends des deux côtés concernant les bulletins de vote par correspondance et les machines à voter. Pour une communauté aussi fermée (seuls les citoyens peuvent voter) mais aussi vaste (il y a environ 300 millions de citoyens américains qui peuvent voter), cela vaut probablement la peine de développer des infrastructures d'identité zk à long terme.
Notez que plusieurs systèmes peuvent être combinés. L'ajout de jalonnement à un système de liste blanche peut renforcer la responsabilité ; la combinaison de SBT avec l'attestation zk peut ajouter de la confidentialité, etc. Cependant, l'ajout de nouvelles méthodes ou la combinaison de différentes méthodes augmentera le coût du produit, de l'ingénierie, de l'exploitation et de la gestion. Par conséquent, une communauté doit évaluer les compromis avant de prendre des décisions.
Résistance à la collusion
Même si les attaques de Sybille se produisent tout le temps dans les systèmes de gouvernance quadratiques, la collusion est le véritable éléphant dans la pièce. La collusion est un problème plus fondamental car elle transforme un système de gouvernance en un jeu coopératif, ce qui est inévitable et bien plus compliqué la plupart du temps.
En fin de compte, les systèmes de gouvernance sont des machines de distribution : les gens expriment leur opinion par le biais de votes et le système distribue une quantité limitée de ressources à différents groupes. Il existe différents niveaux de collusion en fonction de l’échelle du système de gouvernance. Il y a probablement beaucoup moins d’incitations à la collusion dans un système qui distribue 1 000 $ que dans un autre qui distribue 1 000 000 $.
Il existe des coûts associés à différentes formes de collusion, notamment des coûts financiers, des coûts de réputation, etc. Dans les subventions DoraHacks, les directives de la communauté BUIDL (https://dorahacks.io/blog/buidl-community-guidelines/) interdisent explicitement la corruption de votes. Les membres de la communauté qui enfreignent la règle peuvent se voir interdire de recevoir des fonds de contrepartie provenant d'une subvention. Toutefois, si les incitations à la collusion sont suffisamment importantes, il existe toujours des moyens de corrompre.
Cependant, contrairement aux attaques des sybils, nous ne disposons pas de moyens évidents pour éliminer la collusion. La collusion peut être bien plus obscure que les attaques de sybil, et il est difficile de mettre fin à la collusion des « forces de l’ordre ». Dans le monde réel, la collusion est partout et la plupart des formes de collusion ne sont même pas observables : délits d’initiés, pots-de-vin et lobbying. Prévenir ou réglementer la collusion peut parfois prendre des décennies (par exemple, les lois sur la sécurité).
Dans le monde de la blockchain, il est souvent impossible d’appliquer les règles communautaires pour mettre fin à la collusion (car il n’y a pratiquement pas d’« application de la loi » sur la chaîne !). Les solutions cryptographiques anti-collusion sont donc plus favorables. L'infrastructure minimale anti-collusion (MACI)(https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) est un système qui atteint cet objectif en rendant difficile pour les électeurs de prouver cryptographiquement leurs résultats de vote réels. Un tour de vote MACI de base comporte quatre étapes.
Premièrement, les électeurs doivent s’inscrire pour participer au vote.
Puis le vote commence. Tous les votes seront cryptés à l’aide de la clé privée de l’opérateur et voteront sur un contrat intelligent. Les électeurs peuvent voter plusieurs fois.
À la fin de la période de vote, l’opérateur collecte tous les messages et compte les votes dans l’ordre inverse, puis publie les résultats finaux sans révéler les votes des individus.
Enfin, l'opérateur publie les résultats avec une preuve de connaissance zéro (ZKP) prouvant que les résultats sont corrects
Quatre étapes d'un système de vote utilisant MACI
Actuellement, MACI est principalement utilisé dans le vote blockchain et la gouvernance communautaire pour la distribution des fonds. DoraHacks MACI léger (https://github.com/dorahacksglobal/qf-maci) (basé sur MACI 1.0) (https://medium.com/privacy-scaling-explorations/release-announcement-maci-1-0 -c032bddd2157) a été utilisé lors de plusieurs tours de vote quadratiques sur DoraHacks.io, y compris les tours de vote de la communauté ETHDenver 22 (https://dorahacks.io/grant/ethdenver22) et le vote des juges Opensea Hackathon (https://dorahacks.io /subvention/opensea). De plus, Clr.fund est une plateforme de financement de bien public Ethereum qui utilise le MACI et le financement quadratique.
MACI améliore la résistance à la collusion en augmentant le coût de la collusion. Sans un tel système, les électeurs et les corrompus partagent des informations, et le coût de la corruption sera faible. Avec MACI, le coût de la corruption augmentera considérablement. Dans un système doté d’informations efficaces, les dispositifs anti-collusion augmenteront le coût de la corruption à un point tel que le corrupteur ne pourra pas se le permettre. À moins que le corrupteur ne puisse créer une asymétrie de l’information et réduire les attentes des électeurs, il ne peut pas tirer profit de la corruption.
Une conversation au sein d'un forum public sur la mesure dans laquelle MACI augmente le coût de la collusion
Toutefois, le MACI ne constitue pas une solution « une fois pour toutes » à tous les problèmes de collusion. La seule propriété inconditionnelle est l’exactitude du résultat, qui est garantie par des preuves à connaissance nulle. En dehors de cela, MACI a ses propres hypothèses de sécurité et de confidentialité, principalement liées à l'opérateur :
L'opérateur ne s'entend pas avec les électeurs en divulguant des informations à certains groupes d'électeurs, directement ou indirectement.
Il n’existe pas de mécanisme « fou » entre les électeurs pour briser la résistance à la collusion du MACI (par exemple, les électeurs sont physiquement surveillés 24 heures sur 24, 7 jours sur 7, ou forcés de voter sur des ordinateurs qu’ils ne contrôlent pas eux-mêmes).
Pour l'hypothèse 1 : le MACI d'origine exige que l'opérateur soit bon, ce qui signifie que l'opérateur préserve la confidentialité des informations sur les électeurs ainsi que les détails du vote, et que l'opérateur n'est pas intentionnellement de connivence avec les électeurs en divulguant des informations. Pour l’hypothèse 2 – les incitations ne sont pas suffisamment importantes pour que les électeurs inventent des moyens coûteux de briser la résistance à la collusion du MACI.
Ces hypothèses sont-elles importantes ? Dans un système de gouvernance à petite échelle, ils ne sont peut-être pas importants, car nous pouvons toujours faire confiance à l'opérateur. Mais cela pourrait ne pas être vrai si le système de gouvernance évolue. L'opérateur peut être soudoyé s'il y a suffisamment d'incitations.
Une façon de renforcer la confidentialité entre les électeurs et l'opérateur consiste à permettre aux électeurs de changer de clé et de voter en utilisant des clés différentes sans fournir à l'opérateur aucune information sur leurs nouvelles clés.
L'idée est d'ajouter la désactivation des clés dans le système et d'utiliser le ZKP côté client pour empêcher l'opérateur de savoir à qui appartient quelle clé, empêchant ainsi l'opérateur de savoir qui a voté pour quoi. Il existe plusieurs façons d'atteindre cet objectif. Le compromis est le suivant : avec plus de confidentialité, la complexité technique augmentera.
Confidentialité et complexité, différentes propositions d'anonymisation MACI
Lien de référence pour différentes anonymisations MACI :
MACI léger (https://github.com/dorahacksglobal/qf-maci)
MACI d'origine (https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413)
MACI anonymisé léger (https://doraresear.ch/2022/04/30/light-weight-maci-anonymization/)
Anonymisation MACI (avec MPC)(https://ethresear.ch/t/adding-anonymization-to-maci/6329)
Anonymisation MACI (avec cryptage de rerandomisation)(https://ethresear.ch/t/maci-anonymization-using-rerandomizing-encryption/7054)
Le financement quadratique est particulièrement vulnérable à la collusion, car si un parti peut simplement soudoyer davantage d’électeurs pour qu’ils votent pour eux-mêmes, leur gain augmentera quadratiquement.
Actuellement, MACI est plus que suffisant pour renforcer la résistance à la collusion dans la plupart des systèmes de gouvernance blockchain. Supposons que l'anonymisation soit ajoutée aux produits existants avec le même niveau d'expérience utilisateur. Dans ce cas, les systèmes de vote résistants à la collusion basés sur la blockchain peuvent potentiellement résoudre de réels problèmes de gouvernance, des élections générales à la future gouvernance spatiale.
Les adversaires et les solutions évoluent à mesure qu'un système de gouvernance évolue
Inégalités et fiscalité
Une grande partie de la gouvernance consiste à distribuer des ressources. La plupart du temps, l’inégalité est plutôt une caractéristique qu’un bug, car elle existe toujours aussi longtemps que des ressources limitées sont distribuées. La seule différence est qu’elle soit grande ou petite, mais on ne pourra jamais l’éliminer à 100 % (de toute façon, l’utopie n’existe pas !). Si un système de gouvernance souffre d’importants écarts de richesse et de répartition, les gens perdront confiance dans le système au fil du temps, ce qui finira par conduire à l’effondrement du système. Cela est notamment vrai à la fois dans le monde réel (soulèvements sociaux, révolutions et guerres civiles) et dans la gouvernance du protocole blockchain. (https://cryptoslate.com/defi-crowd-mocks-harvard-law-student-group- pour-voter-20-millions-hors-trésorerie-uniswap)
L’idée du vote quadratique est de limiter les préférences extrêmes, notamment celles des baleines. Cela fonctionne la plupart du temps dans la pratique. Cependant, le financement quadratique accroît souvent les inégalités. Si un projet a une zone de support plus grande (soit parce qu'il a reçu un grand nombre de dons, soit parce qu'il a reçu des dons de nombreux contributeurs différents). C’est l’une des raisons pour lesquelles la plupart des subventions quadratiques sont soumises à de lourds ajustements après le cycle.
Une idée pour limiter les inégalités dans le système de gouvernance quadratique est de taxer les plus gagnants. Les projets qui ont reçu un financement plus important peuvent subventionner les projets qui sont sous-équipés, de la même manière que de nombreux pays font pour réduire l'écart de richesse, à deux différences près : (1) tous les financements « fiscaux » seront utilisés pour être redistribués au sein du même système. , (2) la taxe peut être programmée dans le protocole.
En outre, il existe une hypothèse lors de l'utilisation de la taxe. Nous devons supposer que tous les projets/propositions sont légitimes et pré-qualifiés. Il s'agit de garantir que tous les candidats qui reçoivent des subventions sont légitimes aux yeux de la communauté. Si un système ne dispose pas de contrôle des candidatures, il ne fonctionnera pas.
La première conception de l'impôt progressif à financement quadratique a été décrite ici (https://doraresear.ch/2021/06/16/reduce-quadratic-funding-inequality-with-a-progressive-tax-system/). Il taxe les meilleurs projets à chaque fois que vote() est appelé et distribue la taxe à tous les projets sur la base d'un algorithme fixe. Cette version d'impôt progressif a été expérimentée dans plusieurs subventions sur DoraHacks en 2021. Le problème de ce système est que la répartition de l'impôt suit toujours les proportions des financements de tous les projets. Ainsi, si le déficit de financement est normal, les derniers projets financés peuvent bénéficier du système. Si le déficit de financement est énorme, les projets les moins financés ne pourront recevoir que peu de financement fiscal. En réalité, le financement quadratique entraîne souvent d’importants écarts de richesse, et cet algorithme a été abandonné après quelques expérimentations.
Récemment, un nouvel algorithme de taxation du financement quadratique (https://github.com/dorahacksglobal/qf-grant-contract/blob/bsc-long-term/grant-distribution-algorithm.zh.md) a été proposé, basé sur la réduction de l'écart entre le projet le plus apparié et le projet le moins apparié tout en préservant la structure des résultats de vote quadratiques. Pour simplifier le problème, l’algorithme définit le degré d’inégalité comme l’écart entre le parti recevant le plus grand montant de financement et celui recevant le moins de financement. Dans cet algorithme, un ratio maximum entre les plus et les moins financés est défini comme paramètre, et l'algorithme ajuste dynamiquement les résultats de financement pendant le processus de vote chaque fois que l'écart dépasse le ratio maximum. Le nouveau système fiscal sera probablement expérimenté dans le cadre des prochaines subventions.
Conclusion (TL; DR)
La gouvernance concerne la distribution de ressources et de valeurs limitées.
La gouvernance elle-même ne crée pas de valeur. Toutefois, une gouvernance efficace et équitable peut accroître les incitations, ce qui accroît la productivité.
La gouvernance du monde réel partage des problèmes similaires avec la gouvernance de la blockchain.
La gouvernance quadratique hérite de la plupart des problèmes des autres systèmes de gouvernance, en y ajoutant certains de ses propres défis en raison de sa nature « quadratique ».
La gouvernance quadratique est confrontée à trois défis majeurs : la vérification de l’identité et les attaques sybil, la collusion et les inégalités.
Les solutions anti-sybil et de vérification d'identité comportent des compromis, principalement en termes d'absence de permission, de résistance aux sybil, de confidentialité et de complexité du système.
La collusion peut être partiellement résolue par des protocoles cryptographiques tels que MACI, sous certaines hypothèses. Plus de confidentialité signifie plus de complexité.
Les inégalités peuvent être néfastes et destructrices. Semblable aux solutions du monde réel. La taxe pourrait potentiellement contribuer à améliorer la qualité de la distribution.
Enfin, la gouvernance est un jeu sans fin. Lorsqu’un système de gouvernance évolue, le problème prend de l’ampleur, ce qui nécessite donc que les solutions évoluent également. Il existe un vaste espace de conception permettant aux constructeurs et aux concepteurs de mécanismes de travailler sur de nouvelles solutions et d'améliorer les solutions existantes.