Construire Ethereum Dapps: Voter avec des jetons personnalisés

Points de base

• Utilisez des jetons personnalisés dans DAO pour le vote des propositions, notamment la suppression des entrées et les adresses de liste noire, améliorant ainsi la gouvernance décentralisée et la flexibilité opérationnelle.
• Mettre en œuvre un puissant mécanisme de vote nécessitant de vérifier la propriété des jetons et les jetons de verrouillage pendant le vote pour empêcher la manipulation et assurer l'engagement.
• Proposition de conception et systèmes de vote avec des délais structurés et des normes de mise en œuvre pour maintenir les opérations DAO ordonnées et efficaces.
• résoudre les problèmes de sécurité potentiels en limitant la création de propositions aux fonctionnalités des membres et en permettant aux caractéristiques de suppression d'urgence contrôlées par les propriétaires de DAO.
• Explorez les défis techniques et les solutions pour le déploiement de grands contrats intelligents sur Ethereum, en soulignant l'importance de l'optimisation du code pour gérer les coûts du gaz et assurer un déploiement réussi.

La cinquième partie de cette série de tutoriels présente la construction d'un DAPP en utilisant Ethereum, et nous discutons de l'ajout de contenu à l'histoire et de la façon d'ajouter la possibilité d'acheter des jetons de DAO et de soumettre du contenu à l'histoire pour les participants. Il est maintenant temps de la forme finale de DAO: vote, inclusion / absolution des listes noires, distribution et retrait des dividendes. Nous ajouterons des fonctions d'assistance supplémentaires.

Si vous êtes confus par ceux-ci, le code source complet peut être trouvé dans la base de code.

votes et propositions

Nous utiliserons des propositions et des votes pour voter. Nous avons besoin de deux nouvelles structures:

<code>struct Proposal {
    string description;
    bool executed;
    int256 currentResult;
    uint8 typeFlag; // 1 = delete
    bytes32 target; // 提案目标的ID。例如，标志1，目标XXXXXX（哈希）表示删除submissions[hash]的提案
    uint256 creationDate;
    uint256 deadline;
    mapping (address => bool) voters;
    Vote[] votes;
    address submitter;
}

Proposal[] public proposals;
uint256 proposalCount = 0;
event ProposalAdded(uint256 id, uint8 typeFlag, bytes32 hash, string description, address submitter);
event ProposalExecuted(uint256 id);
event Voted(address voter, bool vote, uint256 power, string justification);

struct Vote {
    bool inSupport;
    address voter;
    string justification;
    uint256 power;
}</code>

Les propositions contiendront une carte des électeurs pour empêcher les gens de voter deux fois sur une proposition, ainsi que d'autres métadonnées qui devraient être explicites. Le vote sera un vote de oui ou contre et se souviendra des raisons de l'électeur et du droit de vote - le nombre de jetons qu'ils souhaitent utiliser pour voter pour cette proposition. Nous avons également ajouté un éventail de propositions afin que nous puissions les stocker quelque part, ainsi qu'un compteur pour compter le nombre de propositions.

Maintenant, construisons leurs fonctions de support, à commencer par la fonction de vote:

<code>modifier tokenHoldersOnly() {
    require(token.balanceOf(msg.sender) >= 10**token.decimals());
    _;
}

function vote(uint256 _proposalId, bool _vote, string _description, uint256 _votePower) tokenHoldersOnly public returns (int256) {

    require(_votePower > 0, "At least some power must be given to the vote.");
    require(uint256(_votePower) <= token.balanceOf(msg.sender), "Vote power exceeds token balance.");
    Proposal storage p = proposals[_proposalId];

    require(p.executed == false, "Proposal must not have been executed already.");
    require(p.deadline > now, "Proposal must not have expired.");
    require(p.voters[msg.sender] == false, "User must not have already voted.");

    uint256 voteid = p.votes.length++;
    Vote storage pvote = p.votes[voteid];
    pvote.inSupport = _vote;
    pvote.justification = _description;
    pvote.voter = msg.sender;
    pvote.power = _votePower;

    p.voters[msg.sender] = true;

    p.currentResult = (_vote) ? p.currentResult + int256(_votePower) : p.currentResult - int256(_votePower);
    token.increaseLockedAmount(msg.sender, _votePower);

    emit Voted(msg.sender, _vote, _votePower, _description);
    return p.currentResult;
}</code>

Notez le modificateur de fonction: en ajoutant ce modificateur à notre contrat, nous pouvons l'ajouter à n'importe quelle fonction future et nous assurer que seuls les détenteurs de jetons peuvent exécuter la fonction. Ceci est un contrôle de sécurité réutilisable!

La fonction de vote effectue des chèques sanitaires, comme le droit de vote est positif, l'électeur a suffisamment de jetons pour voter, etc. Nous prenons ensuite la proposition du stockage et nous nous assurons qu'elle n'est ni expirée ni exécutée. Cela n'a aucun sens de voter sur une proposition terminée. Nous devons également nous assurer que cette personne n'a pas encore voté. Nous pouvons autoriser la modification des droits de vote, mais cela peut mettre des Daos face à certaines lacunes, comme les personnes qui retirent leurs votes à la dernière minute, etc. Peut-être un candidat pour une future version?

Nous enregistrons ensuite le nouveau vote dans la proposition, modifions le résultat actuel pour trouver la partition et émis par la publication de l'événement de vote. Mais qu'est-ce que Token.IncreaSelockEdAmount?

Cette logique augmente le nombre de jetons verrouillés pour les utilisateurs. Cette fonction ne peut être exécutée que par le propriétaire du contrat de jeton (cette fois, il est espéré être un DAO) et empêchera l'utilisateur d'envoyer plus que le montant verrouillé enregistré sur son compte. Ce verrou est libéré après l'échec de la proposition ou est exécuté.

Écrivons maintenant une fonction pour présenter des entrées de suppression.

Voter pour supprimer et noire

Dans la première partie de cette série, nous avons planifié trois fonctions de suppression d'entrée:

1. Supprimer l'entrée: après la confirmation de vote, supprimez l'entrée cible. Temps de vote: 48 heures.
2. Essayer de suppression d'urgence [propriétaire uniquement]: déclenché uniquement par le propriétaire. Après la confirmation de vote, supprimez l'entrée cible. Temps de vote: 24 heures.
3. Emergency Supprimer les photos [propriétaire uniquement]: applicable aux entrées d'images uniquement. Uniquement déclenché par le propriétaire. Après la confirmation de vote, supprimez l'entrée cible. Temps de vote: 4 heures.

La suppression de cinq entrées pour une seule adresse entraînera une liste noire.

Voyons comment nous faisons cela maintenant. Tout d'abord, supprimez la fonction:

<code>struct Proposal {
    string description;
    bool executed;
    int256 currentResult;
    uint8 typeFlag; // 1 = delete
    bytes32 target; // 提案目标的ID。例如，标志1，目标XXXXXX（哈希）表示删除submissions[hash]的提案
    uint256 creationDate;
    uint256 deadline;
    mapping (address => bool) voters;
    Vote[] votes;
    address submitter;
}

Proposal[] public proposals;
uint256 proposalCount = 0;
event ProposalAdded(uint256 id, uint8 typeFlag, bytes32 hash, string description, address submitter);
event ProposalExecuted(uint256 id);
event Voted(address voter, bool vote, uint256 power, string justification);

struct Vote {
    bool inSupport;
    address voter;
    string justification;
    uint256 power;
}</code>

Après la soumission, la proposition est ajoutée à la liste des propositions et l'entrée cible est notée par le hachage d'entrée. Enregistrez la description et ajoutez quelques valeurs par défaut et calculez la date limite en fonction du type de proposition. Un événement Add-Propose est émis et le nombre total de propositions augmente.

Ensuite, voyons comment mettre en œuvre la proposition. Pour être exécutoire, une proposition doit avoir suffisamment de votes et doit dépasser sa date limite. La fonction d'exécution acceptera l'ID de la proposition à exécuter. Il n'y a pas de moyen facile de faire en sorte que l'EVM exécute toutes les propositions en attente à la fois. Il peut y avoir trop de propositions en instance à exécuter et ils peuvent apporter des modifications importantes aux données du DAO, qui peuvent dépasser les limites de gaz du bloc Ethereum, entraînant des défaillances de transaction. Il est beaucoup plus facile de créer une fonction d'exécution manuelle qui peut être appelée par quiconque est conforme aux règles bien définies, afin que la communauté puisse se concentrer sur les propositions qui doivent être exécutées.

<code>modifier tokenHoldersOnly() {
    require(token.balanceOf(msg.sender) >= 10**token.decimals());
    _;
}

function vote(uint256 _proposalId, bool _vote, string _description, uint256 _votePower) tokenHoldersOnly public returns (int256) {

    require(_votePower > 0, "At least some power must be given to the vote.");
    require(uint256(_votePower) <= token.balanceOf(msg.sender), "Vote power exceeds token balance.");
    Proposal storage p = proposals[_proposalId];

    require(p.executed == false, "Proposal must not have been executed already.");
    require(p.deadline > now, "Proposal must not have expired.");
    require(p.voters[msg.sender] == false, "User must not have already voted.");

    uint256 voteid = p.votes.length++;
    Vote storage pvote = p.votes[voteid];
    pvote.inSupport = _vote;
    pvote.justification = _description;
    pvote.voter = msg.sender;
    pvote.power = _votePower;

    p.voters[msg.sender] = true;

    p.currentResult = (_vote) ? p.currentResult + int256(_votePower) : p.currentResult - int256(_votePower);
    token.increaseLockedAmount(msg.sender, _votePower);

    emit Voted(msg.sender, _vote, _votePower, _description);
    return p.currentResult;
}</code>

Nous obtenons la proposition par son identifiant, vérifions qu'elle répond à la date limite et que la date limite a des exigences expirées, puis si le type de proposition est de supprimer la proposition et que le vote est positif, nous utilisons la fonction de suppression écrite et enfin Émettez le nouvel événement (ajoutez-le au sommet du contrat). L'appel ASSERT fonctionne de la même manière que l'instruction OFFR: Affirmation est généralement utilisée pour "affirmer" le résultat est vrai. L'exigence est utilisée pour les conditions préalables. Fonctionnellement, ils sont les mêmes, la différence est que l'instruction ASSERT ne peut pas accepter les paramètres de message pour gérer les situations où ils échouent. Cette fonction se termine en déverrouillant les jetons pour tous les votes dans la proposition.

Nous pouvons ajouter d'autres types de propositions en utilisant la même méthode, mais d'abord, mettons à jour la fonction de suppressionsubmission pour interdire les utilisateurs avec cinq suppressions ou plus sur leur compte: cela signifie qu'ils soumettent toujours du contenu que la communauté a opposé. Mettons à jour la fonction de suppression:

<code>struct Proposal {
    string description;
    bool executed;
    int256 currentResult;
    uint8 typeFlag; // 1 = delete
    bytes32 target; // 提案目标的ID。例如，标志1，目标XXXXXX（哈希）表示删除submissions[hash]的提案
    uint256 creationDate;
    uint256 deadline;
    mapping (address => bool) voters;
    Vote[] votes;
    address submitter;
}

Proposal[] public proposals;
uint256 proposalCount = 0;
event ProposalAdded(uint256 id, uint8 typeFlag, bytes32 hash, string description, address submitter);
event ProposalExecuted(uint256 id);
event Voted(address voter, bool vote, uint256 power, string justification);

struct Vote {
    bool inSupport;
    address voter;
    string justification;
    uint256 power;
}</code>

c'est mieux. Automatiquement sur liste noire et supprimé cinq fois. Il est injuste de ne pas donner aux adresses noires une chance de racheter. Nous devons également définir la fonction de liste noire elle-même. Faisons ces deux choses et fixons les frais pour annuler la liste noire, par exemple, 0,05 éther.

<code>modifier tokenHoldersOnly() {
    require(token.balanceOf(msg.sender) >= 10**token.decimals());
    _;
}

function vote(uint256 _proposalId, bool _vote, string _description, uint256 _votePower) tokenHoldersOnly public returns (int256) {

    require(_votePower > 0, "At least some power must be given to the vote.");
    require(uint256(_votePower) <= token.balanceOf(msg.sender), "Vote power exceeds token balance.");
    Proposal storage p = proposals[_proposalId];

    require(p.executed == false, "Proposal must not have been executed already.");
    require(p.deadline > now, "Proposal must not have expired.");
    require(p.voters[msg.sender] == false, "User must not have already voted.");

    uint256 voteid = p.votes.length++;
    Vote storage pvote = p.votes[voteid];
    pvote.inSupport = _vote;
    pvote.justification = _description;
    pvote.voter = msg.sender;
    pvote.power = _votePower;

    p.voters[msg.sender] = true;

    p.currentResult = (_vote) ? p.currentResult + int256(_votePower) : p.currentResult - int256(_votePower);
    token.increaseLockedAmount(msg.sender, _votePower);

    emit Voted(msg.sender, _vote, _votePower, _description);
    return p.currentResult;
}</code>

Veuillez noter que les jetons pour les comptes sur liste noire seront verrouillés jusqu'à ce qu'ils envoient des frais pour annuler la liste noire.

Autres types de votes

Essayez d'écrire d'autres propositions basées sur l'inspiration des fonctions que nous avons écrites ci-dessus. Pour les spoilers, consultez la base de code GitHub du projet et copiez le code final à partir de là. Pour Brivity, passons aux autres fonctions que nous avons encore dans le DAO.

fin du chapitre

Une fois que le moment ou la limite de chapitre de l'histoire est atteint, il est temps de mettre fin à l'histoire. Après la date, n'importe qui peut appeler la fonction finale, ce qui permettra à la dividende d'être retirée. Tout d'abord, nous avons besoin d'une nouvelle propriété StoryDao et d'un événement:

<code>modifier memberOnly() {
    require(whitelist[msg.sender]);
    require(!blacklist[msg.sender]);
    _;
}

function proposeDeletion(bytes32 _hash, string _description) memberOnly public {

    require(submissionExists(_hash), "Submission must exist to be deletable");

    uint256 proposalId = proposals.length++;
    Proposal storage p = proposals[proposalId];
    p.description = _description;
    p.executed = false;
    p.creationDate = now;
    p.submitter = msg.sender;
    p.typeFlag = 1;
    p.target = _hash;

    p.deadline = now + 2 days;

    emit ProposalAdded(proposalId, 1, _hash, _description, msg.sender);
    proposalCount = proposalId + 1;
}

function proposeDeletionUrgent(bytes32 _hash, string _description) onlyOwner public {

    require(submissionExists(_hash), "Submission must exist to be deletable");

    uint256 proposalId = proposals.length++;
    Proposal storage p = proposals[proposalId];
    p.description = _description;
    p.executed = false;
    p.creationDate = now;
    p.submitter = msg.sender;
    p.typeFlag = 1;
    p.target = _hash;

    p.deadline = now + 12 hours;

    emit ProposalAdded(proposalId, 1, _hash, _description, msg.sender);
    proposalCount = proposalId + 1;
}    

function proposeDeletionUrgentImage(bytes32 _hash, string _description) onlyOwner public {

    require(submissions[_hash].image == true, "Submission must be existing image");

    uint256 proposalId = proposals.length++;
    Proposal storage p = proposals[proposalId];
    p.description = _description;
    p.executed = false;
    p.creationDate = now;
    p.submitter = msg.sender;
    p.typeFlag = 1;
    p.target = _hash;

    p.deadline = now + 4 hours;

    emit ProposalAdded(proposalId, 1, _hash, _description, msg.sender);
    proposalCount = proposalId + 1;
}</code>

Ensuite, construisons la fonction:

<code>function executeProposal(uint256 _id) public {
    Proposal storage p = proposals[_id];
    require(now >= p.deadline && !p.executed);

    if (p.typeFlag == 1 && p.currentResult > 0) {
        assert(deleteSubmission(p.target));
    }

    uint256 len = p.votes.length;
    for (uint i = 0; i < len; i++) {
        token.decreaseLockedAmount(p.votes[i].voter, p.votes[i].power);
    }

    p.executed = true;
    emit ProposalExecuted(_id);
}</code>

Simple: il désactive l'histoire après avoir envoyé les frais collectés au propriétaire et envoyé un événement. Mais en réalité, cela ne change pas vraiment la situation globale de DAO: d'autres fonctions ne réagissent pas à sa fin. Alors construisons un autre modificateur:

<code>function deleteSubmission(bytes32 hash) internal returns (bool) {
    require(submissionExists(hash), "Submission must exist to be deletable.");
    Submission storage sub = submissions[hash];

    sub.exists = false;
    deletions[submissions[hash].submitter] += 1;
    if (deletions[submissions[hash].submitter] >= 5) {
        blacklistAddress(submissions[hash].submitter);
    }

    emit SubmissionDeleted(
        sub.index,
        sub.content,
        sub.image,
        sub.submitter
    );

    nonDeletedSubmissions -= 1;
    return true;
}</code>

Ensuite, nous ajoutons ce modificateur à toutes les fonctions, sauf le retrait du propriétaire, comme indiqué ci-dessous:

<code>function blacklistAddress(address _offender) internal {
    require(blacklist[_offender] == false, "Can't blacklist a blacklisted user :/");
    blacklist[_offender] == true;
    token.increaseLockedAmount(_offender, token.getUnlockedAmount(_offender));
    emit Blacklisted(_offender, true);
}

function unblacklistMe() payable public {
    unblacklistAddress(msg.sender);
}

function unblacklistAddress(address _offender) payable public {
    require(msg.value >= 0.05 ether, "Unblacklisting fee");
    require(blacklist[_offender] == true, "Can't unblacklist a non-blacklisted user :/");
    require(notVoting(_offender), "Offender must not be involved in a vote.");
    withdrawableByOwner = withdrawableByOwner.add(msg.value);
    blacklist[_offender] = false;
    token.decreaseLockedAmount(_offender, token.balanceOf(_offender));
    emit Blacklisted(_offender, false);
}

function notVoting(address _voter) internal view returns (bool) {
    for (uint256 i = 0; i < proposals.length; i++) {
        if (proposals[i].executed == false && proposals[i].voters[_voter] == true) {
            return false;
        }
    }
    return true;
}</code>

s'il reste des jetons restants dans le DAO, reproduisons-les et prenons les possessions de ces jetons afin que nous puissions les utiliser plus tard pour une autre histoire:

<code>bool public active = true;
event StoryEnded();</code>

La fonction

UnlockmyTokens est utilisée pour déverrouiller tous les jetons verrouillés qu'un utilisateur particulier peut verrouiller. Cela ne devrait pas se produire et cette fonction doit être supprimée avec de nombreux tests.

Distribution et retrait des dividendes dip

Maintenant que l'histoire est terminée, les frais facturés pour les soumissions doivent être alloués à tous les détenteurs de jetons. Nous pouvons réutiliser notre liste blanche pour marquer tous ceux qui ont déjà retiré leurs frais:

<code>function endStory() storyActive external {
    withdrawToOwner();
    active = false;
    emit StoryEnded();
}</code>

Si ces dividendes ne sont pas retirés dans un certain délai, le propriétaire peut obtenir la partie restante:

<code>modifier storyActive() {
    require(active == true);
    _;
}</code>

En tant que devoirs, considérez à quel point il est facile ou difficile de réutiliser ce contrat intelligent déployé, d'effacer ses données, de garder des jetons dans la piscine et de redémarrer un autre chapitre d'ici sans redéployer. Essayez de le faire vous-même et suivez la base de code pour les futures mises à jour que cette série couvre! Envisagez également des incitations supplémentaires: peut-être que le nombre de jetons dans le compte affectera les dividendes qu'ils reçoivent de la fin de l'histoire? Votre imagination est infinie!

Problèmes de déploiement

Étant donné que notre contrat est désormais assez important, le déploiement et / ou le test peut dépasser les limites de gaz du bloc Ethereum. C'est ce qui empêche les grandes applications de déploier au réseau Ethereum. Pour le déployer de toute façon, essayez d'utiliser l'optimiseur de code pendant la compilation en modifiant le fichier truffle.js pour inclure les paramètres de solc optimisés comme suit:

<code>struct Proposal {
    string description;
    bool executed;
    int256 currentResult;
    uint8 typeFlag; // 1 = delete
    bytes32 target; // 提案目标的ID。例如，标志1，目标XXXXXX（哈希）表示删除submissions[hash]的提案
    uint256 creationDate;
    uint256 deadline;
    mapping (address => bool) voters;
    Vote[] votes;
    address submitter;
}

Proposal[] public proposals;
uint256 proposalCount = 0;
event ProposalAdded(uint256 id, uint8 typeFlag, bytes32 hash, string description, address submitter);
event ProposalExecuted(uint256 id);
event Voted(address voter, bool vote, uint256 power, string justification);

struct Vote {
    bool inSupport;
    address voter;
    string justification;
    uint256 power;
}</code>

Cela exécutera l'optimiseur 200 fois sur le code pour trouver des zones qui peuvent être réduites, supprimées ou abstraites avant le déploiement, ce qui devrait réduire considérablement les coûts de déploiement.

Conclusion

Cela met fin à notre développement DAO détaillé - mais le cours n'est pas encore terminé! Nous devons encore construire et déployer l'interface utilisateur pour cette histoire. Heureusement, la construction de l'extrémité avant est beaucoup plus facile car le backend est entièrement hébergé sur la blockchain. Jetons un coup d'œil à cela dans l'avant-dernier partie de cette série.

Des questions fréquemment posées sur la construction de Dapps Ethereum et le vote avec des jetons personnalisés

Comment fonctionne le vote de la blockchain dans la pratique?

Le vote de la blockchain est un système de vote décentralisé qui utilise la transparence et la sécurité de la technologie de la blockchain. En théorie, cela devrait fonctionner parfaitement, mais en pratique, il rencontre souvent des défis. Le processus de vote consiste à créer des contrats intelligents sur la blockchain Ethereum, et chaque vote est une transaction vérifiable. Cependant, des questions telles que l'anonymat des électeurs, la manipulation du vote et la complexité technique de l'utilisation des plateformes de blockchain peuvent entraver leur mise en œuvre réelle.

Qu'est-ce que le mécanisme de vote DAO?

DAO (Organisation autonome décentralisée) Le mécanisme de vote est un système qui permet aux détenteurs de jetons de DAO de voter sur des propositions en fonction de leur propriété de jeton. Les mécanismes les plus courants comprennent le vote simple de la majorité, qui est accepté si la proposition reçoit plus de 50% des votes, et un vote secondaire, où le coût du vote multiple sur la proposition augmente de façon exponentielle.

Comment fonctionne la gouvernance dans les jetons de sécurité?

La gouvernance des jetons sécurisés est généralement gérée par un système de vote où les détenteurs de jetons peuvent voter sur divers aspects du projet. Cela peut inclure des décisions concernant le développement de projets, l'économie des jetons et même les changements dans le système de gouvernance lui-même. Les droits de vote des détenteurs de jetons sont généralement proportionnels au nombre de jetons qu'ils détiennent.

Comment mettre en place la gouvernance DAO?

La mise en place de la gouvernance DAO consiste à créer un contrat intelligent sur la blockchain Ethereum qui décrit les règles de l'organisation, y compris les droits de vote et les mécanismes de proposition. Ce contrat est ensuite déployé sur la blockchain et les jetons représentant les droits de vote sont distribués aux membres. Les membres peuvent alors proposer et voter pour des changements à l'organisation.

Quels sont les risques de détenir des jetons de gouvernance DAO?

détenir des jetons de gouvernance DAO peut être risqué en raison de la volatilité et de l'incertitude réglementaire des crypto-monnaies entourant le DAO. Par exemple, la Commodity Futures Trading Commission (CFTC) avertit que l'utilisation de jetons DAO pour le vote pourrait être considérée comme une forme de manipulation du marché. De plus, les détenteurs de jetons peuvent perdre leur investissement si le DAO est mal géré ou devient victime d'attaques de pirates.

Comment créer des jetons personnalisés pour voter dans Ethereum Dapp?

La création de jetons personnalisés pour les votes dans Ethereum Dapp implique l'écriture et le déploiement de contrats intelligents sur la blockchain Ethereum. Ce contrat définit les attributs du jeton, tels que son nom, son symbole et son approvisionnement total. Une fois le contrat déployé, les jetons peuvent être distribués aux utilisateurs et les utilisateurs peuvent ensuite les utiliser pour voter sur les propositions dans le DAPP.

Quels sont les avantages de l'utilisation de la blockchain pour voter?

Le vote de la blockchain offre une variété d'avantages, notamment la transparence, la sécurité et l'immuabilité. Les votes sont enregistrés en tant que transactions sur la blockchain, ce qui les rend transparents et vérifiables. La nature décentralisée de la blockchain rend également difficile pour un seul parti de manipuler le processus de vote.

Comment assurer l'anonymat des électeurs du vote de la blockchain?

Étant donné que l'anonymat des électeurs dans le vote de la blockchain peut être difficile en raison de la nature transparente des transactions de blockchain. Cependant, des techniques telles que la preuve de connaissances zéro peuvent être utilisées pour vérifier la validité de l'électeur sans révéler l'identité de l'électeur.

Quels sont les défis de la mise en œuvre du vote de la blockchain?

La mise en œuvre du vote de la blockchain peut être difficile en raison de la complexité technique, de l'incertitude réglementaire et des risques potentiels de sécurité. Les utilisateurs doivent être familiarisés avec la technologie de la blockchain pour participer au processus de vote, et les régulateurs peuvent exprimer leurs préoccupations concernant la légitimité et la sécurité du système de vote de la blockchain.

Comment atténuer les risques associés aux jetons de gouvernance DAO?

Les risques atténuants associés aux jetons de gouvernance DAO comprennent une gestion minutieuse des DAO, des mesures de sécurité approfondies et une œil sur les développements réglementaires à tout moment. Il est également important de diversifier votre portefeuille et de ne pas investir plus que vous ne pouvez le permettre.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!