Titre original : 7 contrôles d'intégrité avant de concevoir un jeton
Auteur : Guy Wuollet
Compilé par : Katie Gu, Odaily Planet Daily
Les jetons sont une nouvelle primitive puissante qui peut être définie de plusieurs façons. L’espace de conception de jetons est riche, mais nous en sommes encore aux premiers stades de l’exploration.
En réalité, de nombreuses équipes ont du mal à trouver la « bonne » conception de token pour leurs projets. Cependant, le secteur ne dispose pas d’un cadre de conception éprouvé, de sorte que les générations futures sont confrontées à plusieurs reprises aux mêmes défis que leurs prédécesseurs. Heureusement, il existe (quelques) premiers exemples de conception de jetons réussie. Les modèles de jetons les plus efficaces comportent des éléments propres à leurs objectifs, mais les conceptions de jetons les plus défectueuses partagent certains bugs communs. Par conséquent, cet article expliquera pourquoi nous devrions envisager la recherche et la conception de jetons plutôt que simplement « l’économie des jetons » et énumérera sept conseils pour éviter les pièges.
#1 Clarifier les objectifs de la conception des jetons
Le plus gros problème dans la conception de jetons est de savoir comment créer un modèle de jeton complexe avant que l'objectif ne soit clair. La première étape doit être d’identifier l’objectif et de s’assurer que toute l’équipe le comprend parfaitement : qu’est-ce que c’est, pourquoi est-ce important et que voulez-vous vraiment accomplir ? Le fait de ne pas définir rigoureusement les objectifs entraîne souvent une refonte et une perte de temps. Avoir des objectifs clairs permet également d’éviter le problème de « créer une économie symbolique pour le plaisir de concevoir une économie symbolique », qui est un phénomène courant dans certaines conceptions économiques symboliques.
De plus, l’objectif devrait porter sur le jeton lui-même, mais cela est souvent négligé. Voici des exemples d’objectifs clairs :
Concevez un jeu avec un modèle de jeton qui permet une évolutivité et une modélisation de support optimales.
Un protocole DeFi espère concevoir un modèle de jeton qui répartit raisonnablement les risques entre les participants.
Concevoir un protocole de réputation qui garantit que l'argent ne peut pas remplacer directement la réputation (par exemple, en dissociant la liquidité des signaux de réputation).
Concevez un réseau de stockage qui garantit que les fichiers sont disponibles avec une faible latence.
Concevez un réseau de jalonnement qui offre une sécurité économique maximale.
Concevez un mécanisme de gouvernance qui suscite de véritables préférences des utilisateurs ou maximise la participation.
La liste est longue. Laissez le jeton prendre en charge n’importe quel cas d’utilisation et atteindre n’importe quel objectif, plutôt que l’inverse.
Alors, comment commencer à définir un objectif clair ? Les objectifs bien définis proviennent généralement de la « mission du projet ». Alors que la « mission du projet » a tendance à être de haut niveau et abstraite, les objectifs doivent être spécifiques et réduits à leur forme la plus élémentaire.
Prenons l'exemple de l'EIP-1559. Roughgarden a déclaré un objectif clair pour l'EIP-1559 : « L'EIP-1559 devrait améliorer l'expérience utilisateur grâce à une simple estimation des coûts sous la forme d'une « meilleure offre claire » en dehors des périodes de croissance rapide de la demande.
Il a ensuite proposé un autre objectif clair : « Pouvons-nous repenser le mécanisme de frais de transaction d'Ethereum pour rendre la fixation des prix du gaz de transaction plus « soyeuse » comme les achats sur Amazon ? L'idéal est un mécanisme de publication des prix, ce qui signifie un mécanisme permettant à chaque utilisateur d'accepter ou abandonnez le prix du gaz.
Ce que les deux exemples ont en commun, c'est que vous énoncez un objectif de haut niveau, fournissez une analogie pertinente pour aider les autres à comprendre votre objectif, puis présentez une solution de conception qui soutient le mieux cet objectif.
#2 Évaluer le travail existant sur la base de principes fondamentaux
Lorsque vous créez quelque chose de nouveau, c'est une bonne idée de commencer par quelque chose qui existe déjà. Lorsque vous évaluez les protocoles et la littérature existants, ils doivent être évalués objectivement en fonction de leurs mérites techniques.
Les modèles de jetons sont souvent évalués en fonction du prix du jeton ou de la popularité du projet associé. Ces facteurs peuvent être sans rapport avec la capacité du modèle de jeton à atteindre ses objectifs déclarés. L'évaluation, la popularité ou d'autres moyens simplistes d'évaluer un modèle de jeton peuvent amener les constructeurs à faire des « détours ». Si vous supposez que d'autres modèles de jetons fonctionnent correctement alors qu'en réalité ce n'est pas le cas, vous pouvez créer un modèle de jeton « intrinsèquement défectueux ».
#3 Clarifiez vos hypothèses
Expliquez clairement vos hypothèses. Lorsque vous vous concentrez sur la création d’une pièce, il est facile de prendre pour acquis les hypothèses de base. Il est également facile de déformer les hypothèses que vous faites réellement.
Prenons, par exemple, un nouveau protocole qui suppose que son goulot d'étranglement matériel est la vitesse de calcul. Intégrer cette hypothèse au modèle de jeton (par exemple, en limitant le coût du matériel requis pour participer au protocole) peut aider à aligner la conception sur le comportement souhaité.
Cependant, si les concepteurs de protocoles et de jetons n’expriment pas clairement leurs hypothèses, ou si les hypothèses qu’ils expriment sont fausses. Les participants conscients de cette inadéquation ont alors le potentiel d’extraire de la valeur du protocole. Les pirates informatiques sont généralement des personnes qui comprennent mieux un système que ceux qui l’ont construit à l’origine.
Clarifier vos hypothèses permet aux utilisateurs de comprendre plus facilement la conception de votre jeton et de garantir son bon fonctionnement. Si vous n’exprimez pas clairement votre hypothèse, vous ne pourrez pas la tester.
#4 Testez vos hypothèses
Il y a un dicton : « Ce n’est pas ce que vous ne savez pas qui vous cause des ennuis. C’est ce dont vous êtes convaincu que ce n’est pas le cas. »
Les modèles de jetons font souvent une série d’hypothèses. Cette approche vient en partie de la conception du système byzantin, qui a inspiré la blockchain. Le système fait une hypothèse et construit une fonction qui, si l'hypothèse est vraie, garantit un certain résultat. Par exemple, Bitcoin garantit une activité dans un modèle de réseau synchrone, garantissant la cohérence si 51 % de la puissance de hachage du réseau est honnête. Plusieurs petites blockchains ont subi des attaques à hauteur de 51 %, violant le nombre d'hypothèses d'honnêteté requises par le consensus Satoshi pour que les blockchains fonctionnent correctement.
Les concepteurs de jetons peuvent vérifier leurs hypothèses de différentes manières. Une modélisation statistique rigoureuse, souvent sous la forme de modèles basés sur des agents, peut aider à tester ces hypothèses. Les hypothèses sur le comportement des utilisateurs peuvent aussi souvent être vérifiées en discutant avec les utilisateurs, et mieux encore en observant ce que les gens font réellement (plutôt que de dire ce qu'ils font). La probabilité d'une validation réussie est plus élevée, en particulier avec des réseaux de tests incités qui produisent des résultats empiriques dans un environnement sandbox. Une validation formelle ou un audit intensif contribuera également à garantir que la base de code fonctionne comme prévu.
#5 Identifiez les « barrières abstraites »
Une « barrière d'abstraction » est l'interface entre les différentes couches d'un système ou d'un protocole. Il est utilisé pour séparer les différents composants d’un système, permettant à chaque composant d’être conçu, mis en œuvre et modifié indépendamment. Des barrières d'abstraction claires sont utiles dans tous les domaines de l'ingénierie, en particulier dans la conception de logiciels, mais sont encore plus nécessaires pour le développement décentralisé et les grandes équipes construisant des systèmes complexes qu'aucun individu ne peut comprendre.
Dans la conception de jetons, l’objectif de supprimer les barrières d’abstraction est de minimiser la complexité. Réduire les dépendances (internes) entre les différents composants d'un modèle de jeton peut conduire à un code plus propre, à moins de bogues et à de meilleures conceptions de jetons.
Par exemple, de nombreuses blockchains sont construites par de grandes équipes d’ingénierie. Une équipe peut faire des hypothèses sur les coûts du matériel au fil du temps et les utiliser pour déterminer combien de mineurs contribuent au matériel de la blockchain à un prix symbolique donné. Si une autre équipe s'appuie sur le prix du jeton comme paramètre mais ne connaît pas les hypothèses de la première équipe concernant les coûts du matériel, elle peut facilement faire des hypothèses contradictoires.
Au niveau de la couche application, des barrières d'abstraction claires sont essentielles pour parvenir à la composabilité. À mesure que de plus en plus de protocoles seront combinés les uns avec les autres, la capacité à s’adapter, à créer, à étendre et à remixer ne fera que devenir plus importante. Des compositions plus grandes apportent de plus grandes possibilités, mais aussi une plus grande complexité. Lorsque les applications souhaitent composer, elles doivent comprendre les détails du protocole de composition qu'elles utilisent.
Des hypothèses et des interfaces opaques peuvent parfois conduire à des bugs obscurs, en particulier dans les premiers protocoles DeFi. Les barrières d'abstraction floues augmentent également l'efficacité de la communication requise entre les équipes travaillant sur différents composants du protocole, prolongeant ainsi le temps de développement. De vagues barrières d’abstraction augmentent également la complexité du protocole, ce qui rend difficile la compréhension complète de ses mécanismes.
En créant des barrières abstraites claires, les concepteurs de jetons peuvent plus facilement prédire comment des changements spécifiques affecteront chaque partie de la conception du jeton. Des barrières d'abstraction claires facilitent également l'extension d'un jeton ou d'un protocole et créent une communauté Builder plus inclusive et évolutive.
#6 Réduire la dépendance aux paramètres externes
Les paramètres externes ne sont pas inhérents au système mais peuvent affecter les performances globales et le succès, comme le coût des ressources informatiques, le volume des transactions ou la latence dans les premières étapes de la création du modèle de jeton.
Mais lorsqu'un modèle de jeton ne fonctionne que lorsque les paramètres sont maintenus dans une plage limitée, un comportement inattendu peut se produire. Par exemple, un protocole qui vend des services et offre des remises sous la forme d’une récompense fixe en jeton peut valoir plus que le coût du service si le prix du jeton est étonnamment élevé. Dans ce cas, il est très rentable d’acheter des services illimités auprès du protocole, qui profiteront pleinement des récompenses et des services symboliques.
Ou, pour prendre un autre exemple, les réseaux décentralisés s'appuient souvent sur des algorithmes cryptographiques ou des énigmes informatiques difficiles mais pas impossibles à résoudre. La difficulté dépend généralement d’une variable exogène, telle que la rapidité avec laquelle un ordinateur peut calculer une fonction de hachage ou une preuve sans connaissance. Par exemple, il existe un protocole qui suppose la rapidité avec laquelle une fonction de hachage donnée peut être calculée et paie les récompenses symboliques en conséquence. Si quelqu'un invente une nouvelle façon de calculer une fonction de hachage plus rapidement, ou dispose simplement de ressources démesurées pour résoudre le problème, disproportionnées par rapport à son travail réel dans le système, il peut être récompensé par des jetons étonnamment énormes.
#7 Revalider les hypothèses
Concevoir un jeton devrait être comme concevoir un système contradictoire. Le comportement des utilisateurs changera à mesure que le fonctionnement du jeton changera.
Une erreur courante consiste à ajuster le modèle de jeton sans garantir que le comportement arbitraire de l'utilisateur produit toujours des résultats acceptables. Ne présumez pas que le comportement des utilisateurs restera le même en raison des changements apportés au modèle de jeton. Généralement, ce type d'erreur se produit tard dans le processus de conception, lorsque quelqu'un a passé beaucoup de temps à définir l'objectif du jeton, à définir ses fonctionnalités et à le valider pour garantir qu'il fonctionne comme prévu. Ensuite, ils ont identifié un cas particulier et ont modifié la conception du jeton pour l'adapter, mais ont oublié de revalider l'intégralité du modèle de jeton. En résolvant un cas particulier, ils créent un autre (ou plusieurs autres) conséquences involontaires.
N'oubliez pas de ne pas gaspiller votre travail acharné : chaque fois qu'un projet modifie son modèle de jeton, vérifiez à nouveau qu'il fonctionne comme prévu.