Rubriques tendance
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Le matching vérifiable par ZK est un moyen d'exécuter un carnet de commandes rapide et privé tout en offrant aux utilisateurs une garantie cryptographique que le moteur de correspondance a respecté les règles.
Le problème qu'il résout est simple : un CLOB a besoin d'un opérateur (ou d'un petit groupe d'opérateurs) pour faire correspondre les ordres rapidement, mais cet opérateur peut aussi tricher (réorganiser, sauter ou remplir sélectivement).
ZK change le modèle de confiance : l'opérateur peut rester rapide, mais ne peut pas finaliser une mise à jour à moins de prouver qu'elle a été calculée correctement.
𝗖𝗼𝗺𝗺𝗲𝗻𝘁 𝗰𝗲𝗹𝗮 𝗳𝗼𝗻𝗰𝘁𝗶𝗼𝗻𝗻𝗲 (𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘂𝗲𝗹𝗹𝗲𝗺𝗲𝗻𝘁)
➤ Les ordres sont collectés et appariés hors chaîne (vous pouvez donc obtenir une exécution à faible latence).
➤ Au lieu de publier l'intégralité du flux d'ordres, le système publie :
- 𝘂𝘀𝘁𝘦 𝘤𝘰𝘮𝘮𝘪𝘵𝘵𝘦𝘯𝘵 𝘢 𝘭'𝘦𝘵𝘵𝘦𝘳𝘦 / 𝘴𝘵𝘢𝘵𝘦 𝘵𝘳𝘢𝘯𝘴𝘪𝘵𝘪𝘰𝘯 (𝘦𝘳𝘦𝘳𝘦𝘳𝘦 𝘢 𝘶𝘯 𝘴𝘵𝘢𝘵𝘦 𝘳𝘰𝘰𝘵)
- 𝘶𝘯 𝘻𝘬-𝘱𝘳𝘰𝘰𝘧 𝘲𝘶𝘦 𝘭𝘦 𝘮𝘢𝘵𝘤𝘩𝘪𝘯𝘨 + 𝘤𝘩𝘦𝘤𝘬𝘴 𝘥𝘦 𝘳𝘪𝘴𝘲𝘶𝘦 + 𝘭𝘦𝘴 𝘶𝘱𝘥𝘢𝘵𝘦𝘴 𝘥𝘦 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘴𝘦𝘳𝘦𝘯𝘵 𝘦𝘧𝘧𝘦𝘤𝘵𝘶𝘦𝘴 𝘢𝘤𝘤𝘰𝘳𝘥𝘪𝘯𝘨 𝘢𝘶𝘹 𝘳𝘦𝘶𝘭𝘦𝘴 𝘥𝘦 𝘭𝘦 𝘱𝘳𝘰𝘵𝘰𝘤𝘰𝘭,
- 𝘦𝘯𝘰𝘶𝘨𝘩 𝘥𝘢𝘵𝘢 𝘢𝘷𝘢𝘪𝘭𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘴𝘰 𝘲𝘶𝘦 𝘭𝘦𝘴 𝘶𝘴𝘦𝘳𝘴 𝘱𝘦𝘶𝘵 𝘴𝘵𝘪𝘭𝘭 𝘦𝘹𝘪𝘵 𝘦𝘷𝘦𝘯 𝘴𝘪 𝘭'𝘰𝘱𝘦𝘳𝘢𝘵𝘦𝘶𝘳 𝘥𝘪𝘴𝘢𝘱𝘱𝘦𝘢𝘪𝘳.
Cette "disponibilité de données suffisante" est là où le choix de conception de @hibachi_xyz est intéressant :
Hibachi exécute un CLOB haute performance et publie des données d'état / de transaction cryptées sur @Celestia (de sorte que les stratégies et les positions ne soient pas publiques), tout en publiant des preuves afin que les mises à jour restent vérifiables, en utilisant SP1 (le zkVM de Succinct) pour prouver le CLOB.
𝗠𝗮𝗶𝘀 𝗾𝘂𝗲𝘀𝗾𝘂𝗲 𝗹𝗮 𝗳𝗼𝗻𝗰𝘁𝗶𝗼𝗻 𝗱𝗲 𝗺𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝗲𝘀𝘁 𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝗲𝗻 𝘁𝗲𝗿𝗺𝗲𝘀 𝗱𝗲 𝗽𝗿𝗼𝗼𝗳 ?
Un zk-proof peut faire respecter les mêmes invariants que vous vous fieriez normalement à un opérateur d'échange pour suivre, par exemple :
➤ Les ordres n'étaient appariés que lorsque les prix se croisent (pas de remplissages impossibles).
➤ La séquence de remplissage respectait la règle de priorité du lieu (par exemple, priorité prix-temps, ou ce que le lieu spécifie).
➤ Les soldes/marges étaient mis à jour correctement (pas de modifications de solde cachées).
...

Meilleurs
Classement
Favoris
