Décryptage ultra-détaillé de la mise en œuvre technique derrière Polymarket
TechFlow SélectionTechFlow Sélection
Décryptage ultra-détaillé de la mise en œuvre technique derrière Polymarket
Polymarket a réussi à combiner des technologies provenant de différents projets, ce qui est particulièrement instructif pour les nouveaux venus.
Dédié à des analyses Web3 approfondiesRédaction : Pavel Naydanov
Traduction : Golem, Odaily Planet Daily
Éditorial : Lors de cette élection présidentielle américaine, Polymarket a attiré davantage d'attention. Non seulement le volume cumulé des transactions sur les thèmes prédictifs a dépassé 3,6 milliards de dollars, mais il a également prédit avec succès et plus tôt que les sondages traditionnels ou les médias classiques la victoire de Trump. Cela a conduit les gens à prendre conscience que Polymarket n'est pas simplement un site de paris, mais pourrait devenir une source d'information plus fiable et réaliste (voir l'article recommandé : « Nouvel article de Vitalik : Des marchés prédictifs à la finance informationnelle »). Polymarket pourrait bien être l'un des points culminants les plus remarquables de l'innovation blockchain actuelle.
Alors, comment Polymarket, qui revêt une signification révolutionnaire pour la blockchain, parvient-il techniquement à ce résultat ? Le développeur de contrats intelligents Pavel Naydanov a effectué une analyse minutieuse et explicative des technologies utilisées par Polymarket, une démarche potentiellement inspirante pour les développeurs. Odaily Planet Daily traduit ci-dessous la partie technique du texte original. Plongeons maintenant dans les détails techniques de ce protocole.
CTF : La tokenisation des résultats
Tous les événements et résultats sur Polymarket sont tokenisés :
-
Ces jetons peuvent être appelés « jetons de part (Share tokens) » ;
-
Les parts sont achetées avec un actif sous-jacent, elles sont donc entièrement garanties ;
-
Les parts peuvent être vendues afin de récupérer l’actif sous-jacent.
Les Share tokens reposent sur le Conditional Token Framework (CTF) de Gnosis, implémenté selon la norme ERC-1155. Ce cadre a fait ses preuves et a été testé via plusieurs protocoles. Le CTF peut supporter jusqu’à 256 résultats par événement.
Chaque prédiction est identifiée dans le CTF en lui attribuant un identifiant conditionnel unique, composé du hachage de trois paramètres :
-
L’oracle : l’adresse de l’oracle qui déterminera le résultat de l’événement, garantissant ainsi que seul l’oracle désigné peut clôturer la prédiction ;
-
L’identifiant de la question (question ID) : un identifiant de prédiction défini par son créateur. Il peut s’agir d’un simple compteur incrémental pour chaque nouvelle prédiction, ou d’un schéma plus complexe basé sur le hachage du texte et d’autres données ;
-
Le nombre de slots de résultat (outcomeSlotCount) : le nombre de résultats possibles pour la prédiction.
Le schéma suivant illustre visuellement le fonctionnement du CTF (Conditional Token Framework) :
Lorsqu’un utilisateur parie, il fournit un actif sous-jacent et reçoit en échange un Share token, appelé aussi jeton conditionnel dans le CTF. Une fois que l’oracle a confirmé le résultat de la prédiction, l’utilisateur peut retirer sa récompense depuis le CTF.
Lorsqu’un utilisateur reçoit un jeton conditionnel, on considère qu’il a pris une position spécifique. Dans le CTF, une position représente un ensemble de combinaisons possibles de résultats pour chaque prédiction. Le CTF génère automatiquement ces positions, chacune correspondant à une combinaison possible de résultats parmi lesquelles l’utilisateur peut choisir.
Par exemple :
Quel sera le film ayant le plus grand box-office en 2024 ?
-
Vice Versa 2
-
Furieux 4
-
Deadpool 3
-
Joker 2
-
Moi, moche et méchant 4
-
Dune 2
-
Autre
Un utilisateur peut voter pour penser que « Vice Versa 2 » sera le film au plus haut box-office, ou qu’au contraire « Dune 2 » ne le sera certainement pas. Cette combinaison de votes constitue sa position.
Le CTF propose deux mécanismes intéressants pour gérer les positions : le fractionnement (splitting) et la fusion (merging). Le fractionnement permet de diviser une position unique en plusieurs résultats distincts, tandis que la fusion combine différents résultats en une seule position. Ces mécanismes offrent aux utilisateurs une grande flexibilité dans la gestion de leurs positions.
Le CTF apporte quatre avantages majeurs à Polymarket :
-
Les Share tokens permettent de confirmer le vote d’un utilisateur sur un résultat particulier ;
-
Il met en place un système souple combinant les votes des utilisateurs en diverses positions ;
-
La responsabilité du calcul des résultats est déléguée au CTF, selon le signal de l’oracle ;
-
Les récompenses sont calculées selon le nombre de Share tokens associés au résultat gagnant.
Il convient également de mentionner que le CTF permet d’organiser des activités connexes où les positions des utilisateurs peuvent être fusionnées. À ce jour, cependant, Polymarket ne présente aucun exemple de ce type. Pour approfondir le sujet du CTF, vous pouvez consulter la documentation officielle.
Mécanisme des ordres
Pour effectuer un achat, l’interface Polymarket propose trois types d’ordres :
-
Market — achat immédiat au prix du marché actuel ;
-
Limit — ordre différé permettant de spécifier un prix d’achat à atteindre ;
-
AMM — achat à un prix automatiquement déterminé, similaire aux DEX, fondé sur les réserves disponibles dans le pool.
Actuellement, la fonctionnalité AMM semble inactive, aucune prédiction ne permettant d’acheter via AMM n’a été trouvée. Un commentaire d’un utilisateur sur le Discord de Polymarket explique partiellement cette situation.
L’AMM est obsolète.
Selon la documentation de Polymarket, l’AMM a été développé comme partie intégrante du contrat intelligent du Conditional Token Framework. Ainsi, l’AMM servait initialement à déterminer le prix d’achat des Share tokens. Ce mécanisme de base nécessite de la liquidité pour assurer une tarification stable et réduire la volatilité. Les fournisseurs de liquidité doivent être incités économiquement, recevant une récompense sur chaque achat pour maintenir le système opérationnel.
Initialement, Polymarket était probablement entièrement basé sur le CTF, utilisant l’AMM pour fixer les prix. Avec le temps, le protocole a développé une solution hybride dotée d’un carnet d’ordres, et les deux autres types d’ordres (limites et marché) ont commencé à fonctionner sur cette solution personnalisée. Cette solution est appelée CLOB (Central Limit Order Book) ou BLOB (Binary Limit Order Book).
CLOB et BLOB
Le CLOB (Carnet d’ordres à cours limité centralisé) ou BLOB (Carnet binaire à cours limité) est un système représentant un carnet d’ordres hybride et décentralisé. Dans ce système, un opérateur spécialisé est chargé de matcher les ordres et d’exécuter les contrats intelligents.
Sans entrer dans trop de détails, le système fonctionne comme illustré ci-dessous :
Les utilisateurs créent des ordres à exécuter, qu’ils soient à cours limité ou au marché. L’opérateur apparie ces ordres et lance leur exécution sur le contrat intelligent. Créer un ordre consiste à créer une structure de données signée avec la clé privée de l’utilisateur, conformément à la norme EIP-712. Puisque les ordres sont stockés hors chaîne avant exécution, leurs conditions peuvent être ajustées rapidement et gratuitement, voire annulées complètement.
Cependant, tout ce qui concerne le carnet d’ordres et l’appariement des ordres n’est accessible que via API. Par commodité, Polymarket fournit deux clients : un en JavaScript et un en Python.
Le contrat intelligent Exchange.sol est toutefois public, et est responsable de la création des positions des utilisateurs dans le CTF. Il permet également de gérer ces positions et de transférer des actifs entre elles, assurant sécurité et transparence au sein du protocole.
Ce contrat intelligent a été audité, et le rapport d’audit est joint au dépôt.
Contrats intelligents
Le contrat intelligent Exchange porte en réalité un nom plus précis : CTFExchange.sol. Il n’est pas très volumineux, environ 100 lignes de code, mais comporte de nombreuses dépendances.
La plupart sont de petits contrats intelligents réalisant des fonctions spécifiques :
-
BaseExchange.sol : un contrat intelligent abstrait implémentant la capacité de recevoir des jetons ERC-1155, et responsable également de la prévention des attaques de réentrance ;
-
Auth.sol : gestionnaire de rôles, définissant les fonctions et modificateurs de vérification pour configurer les rôles admin et operator de CTFExchange.sol ;
-
Assets.sol : définit deux types d’actifs, l’actif sous-jacent (collatéral) et l’adresse du CTF ;
-
Fees.sol : définit les frais du protocole ;
-
Pausable.sol : définit la capacité de suspendre les opérations du contrat intelligent, une forme de centralisation adoptée par le protocole en cas de circonstances imprévues. Accessible uniquement au rôle admin ;
-
AssetOperation.sol : définit les opérations sur l’actif sous-jacent et le CTF, y compris le transfert, le fractionnement et la fusion des positions ;
-
Signature.sol : définit le code utilisé pour valider les signatures des utilisateurs lors de la vérification des ordres ;
-
Hashing.sol : définit le hachage des paramètres d’ordre, utilisé pour la validation des signatures ;
-
Registry.sol : définit le processus d’enregistrement d’une prédiction dans le système et l’enregistrement des jetons associés.
Tout ce qui concerne l’exécution effective des ordres est implémenté dans le contrat intelligent Trading.sol. Parcourir le code et étudier ce contrat est relativement simple. Sa structure définit clairement les points d’entrée via des fonctions :
-
fillOrder() — exécute un ordre entre l’utilisateur créateur de l’ordre et un utilisateur choisissant une offre existante (un autre ordre) ;
-
fillOrders() — identique à fillOrder(), mais pour une liste d’ordres ;
-
matchOrders() — l’opérateur sélectionne deux ordres différents et les exécute.
Toutes ces fonctions ne peuvent être appelées que par l’opérateur.
Quel que soit le point d’entrée dans le contrat intelligent, le résultat final reste le même : deux utilisateurs échangent des jetons conformément à leurs ordres.
Frais du protocole
Les frais sont perçus sur les actifs sortants. Pour les prédictions binaires, les frais sont symétriques : si un utilisateur vend un jeton à 0,99 dollar, il paiera les mêmes frais que l’acheteur qui acquiert un jeton à 0,01 dollar.
La formule de calcul est simple, extraite de la documentation officielle :
Programme de récompenses pour la liquidité
L’objectif général de ce programme est d’inciter à la liquidité sur le marché.
Pour qu’un exchange basé sur un carnet d’ordres fonctionne, il faut que des utilisateurs créent des ordres à cours limité. Ces ordres fournissent la liquidité nécessaire à l’exécution immédiate des ordres au marché. Les utilisateurs créant ces ordres sont appelés « market makers ». Plus un ordre à cours limité est proche du prix du marché, plus les ordres au marché peuvent être exécutés rapidement, augmentant ainsi le volume des transactions — ce qui est indéniablement bénéfique pour les utilisateurs finaux. En outre, plus la liquidité est élevée, plus il est difficile de manipuler le marché.
Pour garantir une liquidité suffisante, Polymarket a mis en place un programme spécial de récompenses destiné à inciter les utilisateurs à créer des ordres à cours limité. Plus un ordre à cours limité est proche du prix moyen du marché, plus la récompense est élevée. Les récompenses sont automatiquement versées chaque nuit à minuit (UTC).
Le système s’inspire de dYdX. Pour en savoir plus, consultez le programme initial d’incitation à la liquidité de dYdX et la formule détaillée de calcul des récompenses de liquidité de Polymarket.
Oracle
L’oracle sert à fournir les résultats des prédictions — à déterminer si un événement s’est produit ou non. L’oracle est l’un des composants les plus importants du protocole, mais il est géré par un service tiers, et non par l’équipe Polymarket. Cet oracle s’appelle UMA.
UMA est un oracle décentralisé spécialisé dans l’enregistrement de tout type de données sur la blockchain, à l’exception des données impossibles à vérifier. Cet oracle est optimiste : les données sont considérées comme correctes par défaut, sauf en cas de contestation. UMA dispose de son propre système d’arbitrage pour régler les litiges, composé de personnes réelles — des participants à l’écosystème UMA, notamment les détenteurs de jetons UMA. Ce système est appelé DVM (Data Verification Mechanism).
Le processus suivant est utilisé pour déterminer le résultat d’une prédiction et l’enregistrer sur la blockchain :
-
Déclaration (Statement) : la prédiction est ajoutée à l’oracle accompagnée d’une récompense. Toute personne réussissant à contester le résultat de la prédiction peut empocher la récompense ;
-
Période de contestation (Challenge period) : durant cette période, toute personne peut remettre en cause le résultat. Si aucune contestation n’a lieu et que le délai expire, le résultat est considéré comme prêt à être définitivement réglé, validant ainsi son exactitude ;
-
Contestation (Dispute) : tout participant au protocole peut contester le résultat, que ce soit pour obtenir la récompense ou par souci d’équité. En pratique, cela se produit rarement, car la théorie des jeux montre que la majorité des participants agissent honnêtement.
-
Vote (Voting) : si une contestation est lancée, les détenteurs de jetons UMA votent pour trancher le différend. UMA est le jeton du protocole utilisé pour voter, et les participants sont récompensés pour leur participation.
-
Règlement (Settlement) : dernière étape, le processus d’enregistrement effectif des données sur la blockchain. Après cela, le résultat de la prédiction peut être considéré comme fiable.
Tout le protocole repose sur la théorie des jeux : toute action malveillante d’un participant est économiquement désavantageuse.
-
Les participants soumettant un résultat pour vote doivent déposer une garantie dans le contrat intelligent. S’ils sont contredits, ils perdent leur garantie ; sinon, ils la récupèrent ainsi qu’une récompense. Cela crée une forte incitation à ne soumettre que des résultats précis.
-
Les participants contestant un résultat doivent également déposer une garantie. S’ils ont raison, ils récupèrent leur garantie et obtiennent une récompense ; sinon, ils la perdent. Cela les incite à ne contester que les résultats dont ils sont certains qu’ils sont erronés.
-
Les participants résolvant les litiges doivent miser des jetons UMA et seront récompensés pour cela. S’ils votent mal ou ne votent pas du tout, ils perdent une partie de leur mise ; sinon, ils sont récompensés. Il est impossible de rester passif.
À noter particulièrement : le processus de vote lors d’un litige utilise un schéma en deux phases commit/reveal :
-
Commit (Engagement) : les participants votent secrètement en soumettant le hachage de leur vote au contrat intelligent, ce qui signifie que personne ne peut deviner leur choix en examinant seulement le hachage.
-
Reveal (Révélation) : une fois la phase de vote terminée, les participants révèlent leur bulletin, et le contrat intelligent vérifie qu’il correspond bien au hachage précédemment soumis.
Ce processus de vote en deux étapes empêche les collusions entre électeurs visant à discréditer l’oracle ou à attaquer les services dépendant des résultats prédictifs. En outre, un résultat peut être contesté plusieurs fois. Dans ce cas, UMA autorise le redémarrage du processus décisionnel après la fin d’une contestation précédente.
Le processus de lancement d’une contestation est le suivant :
Conclusion
Polymarket, ce système de paris et de prédictions apparemment simple, intègre en réalité trois modules principaux, chacun développé par des protocoles et des équipes différentes :
-
CTF (Conditional Token Framework) : gère les combinaisons, les positions et les Shares dans les prédictions. Ce cadre flexible créé par Gnosis convient parfaitement aux marchés prédictifs.
-
CLOB (Central Limit Order Book) : solution interne développée par Polymarket pour implémenter le carnet d’ordres et les ordres à cours limité. Le CLOB permet aux utilisateurs de participer efficacement à l’écosystème et aide à agréger la liquidité.
-
UMA : un oracle décentralisé doté d’un système d’arbitrage de litiges unique. UMA est le cœur du système, chargé de transmettre les résultats des prédictions sur la blockchain.
Bien que Polymarket soit un système de paris, techniquement, le protocole parvient à combiner habilement des technologies provenant de différents projets, ce qui le rend particulièrement attrayant pour les développeurs.
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
@hackernoon
