Introduction

Les applications décentralisées d'aujourd'hui rencontrent des limitations dans l'exécution de calculs complexes on-chain en raison des capacités de traitement restreintes de la blockchain. Cependant, avec le développement rapide de technologies telles que les coprocesseurs de blockchain, en conjonction avec la théorie des jeux et la conception de mécanismes, une nouvelle vague de cas d'utilisation émerge pour améliorer considérablement l'expérience utilisateur.

Cet article explore l'espace de conception des coprocesseurs, en mettant l'accent sur les cas d'utilisation potentiels qu'ils permettent.

Principaux points à retenir :

• La computation en blockchain est coûteuse et limitée ; une solution consiste à déplacer la computation hors chaîne et à vérifier les résultats sur chaîne à travers des coprocesseurs, permettant des logiques d'applications décentralisées plus complexes.
• Les coprocesseurs peuvent être classés en sans confiance (ZK), minimisant la confiance (MPC/TEE), optimistes et cryptéconomiques en fonction de leurs hypothèses de sécurité. Ces solutions pourraient également être combinées pour atteindre le compromis souhaité entre sécurité et efficacité.
• Différents types de coprocesseurs sont adaptés à différentes tâches dans DeFi. Les cas d'utilisation potentiels couvrent DEX (AMM & carnet d'ordres), les marchés monétaires, le staking, le restaking, etc.
• Avec la montée de l'IA décentralisée, accompagnée de coprocesseurs, nous entrons dans une nouvelle ère de “Intelligent DeFi”.

Le rôle des coprocesseurs

La blockchain est généralement considérée comme une machine virtuelle (VM) CPU à usage général qui n’est peut-être pas idéale pour les calculs lourds. Les tâches impliquant une analyse basée sur les données et des calculs intensifs nécessitent souvent des solutions hors chaîne. Par exemple, les échanges de carnets d’ordres comme dydx v3 utilisent des moteurs de correspondance et de risque hors chaîne fonctionnant sur des serveurs centralisés, seuls les règlements de fonds ayant lieu sur la chaîne.

En informatique, les coprocesseurs sont introduits pour aider les processeurs à effectuer des tâches spécifiques, comme l'indique le préfixe 'co-'. Par exemple, les GPU servent de coprocesseurs pour les CPU. Ils excellent dans le traitement de calculs parallèles nécessaires pour des tâches comme le rendu 3D et l'apprentissage profond. Cette disposition permet au CPU principal de se concentrer sur le traitement à usage général. Le modèle de coprocesseur a permis aux ordinateurs de gérer des charges de travail plus complexes qui n'auraient pas été réalisables avec un seul CPU polyvalent.

En exploitant des coprocesseurs et en accédant aux données on-chain, les applications blockchain peuvent potentiellement offrir des fonctionnalités avancées et prendre des décisions éclairées. Cela crée des opportunités pour effectuer des calculs supplémentaires, permettant l'exécution de tâches plus complexes et permettant aux applications de devenir plus "intelligentes".

Différents types de coprocesseurs

Basé sur des hypothèses de confiance, les coprocesseurs pourraient être classés principalement en trois types différents - Zero-Knowledge (ZK), Optimiste et Cryptéconomique.

Les coprocesseurs ZK, s’ils sont implémentés correctement, sont théoriquement sans confiance. Ils effectuent des calculs hors chaîne et soumettent des preuves sur la chaîne pour vérification. Bien qu’ils offrent de la rapidité, il y a un compromis en termes de coût de preuve. Au fur et à mesure que le matériel personnalisé progresse et que la cryptographie se développe, le coût final répercuté sur les consommateurs finaux pourrait potentiellement être réduit à un niveau plus acceptable.

AxiomeetRISC ZeroLes bonsaïs sont des exemples de coprocesseurs ZK. Ils permettent d'exécuter hors chaîne des calculs arbitraires avec accès à l'état on-chain et fournissent des preuves que le calcul a été effectué.

Pour fournir une compréhension plus claire de comment fonctionne typiquement un coprocesseur ZK, examinons le flux de RISC Zero Bonsai.

Les applications envoient des demandes de coprocessing à Bonsai Relay, qui transmet ensuite la demande de preuve au service de preuve de Bonsai. Le RISC Zero zkVM exécute le programme et génère une preuve pour valider l'exécution correcte du code, qui peut être vérifiée par n'importe qui. Ensuite, Bonsai Relay publie la preuve on-chain, et les applications reçoivent les résultats via une fonction de rappel.

Bonsai sur Ethereum

Bien que le coprocesseur ZK soit une méthode pour réaliser des calculs vérifiables hors chaîne, des alternatives telles que MPC et TEE offrent des approches différentes. MPC permet un calcul collaboratif sur des données sensibles, tandis que les TEE fournissent des enclaves sécurisées basées sur du matériel. Chaque option comporte son propre ensemble de compromis entre sécurité et efficacité. Dans cet article, nous nous concentrerons sur les coprocesseurs ZK.

Les coprocesseurs optimistes offrent des solutions rentables, mais souffrent de problèmes de latence significatifs (typiquement des semaines). Ils nécessitent des parties honnêtes pour les défier efficacement avec des preuves de fraude dans la fenêtre de défi. Par conséquent, le temps de garantie de sécurité est retardé.

Les coprocesseurs cryptoéconomiques sont des coprocesseurs optimistes avec une obligation économique suffisamment importante lors de l'exécution et un système d'assurance on-chain qui permet aux autres de recevoir une compensation pour une computation erronée. Cette obligation économique et cette assurance peuvent être achetées via des fournisseurs de sécurité partagée comme Eigenlayer. L'avantage est un règlement instantané, mais l'inconvénient est le coût de l'acquisition de l'assurance.

Caractéristiques des différents types de coprocesseurs

Il existe des temps de génération de preuves de moins d'une seconde là-bas (admettons pour des preuves petites et optimisées) et ils s'améliorent rapidement.

Les différents types de coprocesseurs présentent des caractéristiques de coût, de latence et de sécurité distinctes. La combinaison de différents types de coprocesseurs peut conduire à une expérience utilisateur optimisée. Un exemple frappant est Brevis. Initialement lancé avec un co-processeur zk, Brevis a maintenant dévoilé le Brevis coChain. Cette innovation combine la cryptonomie et ZKP au sein d'un coprocesseur ZK, ce qui permet de réduire les coûts, de minimiser la latence et d'améliorer l'expérience utilisateur.

Les coprocesseurs ZK purs, dans leur état actuel, présentent encore des défis tels que des coûts élevés de génération de preuves et des problèmes de scalabilité. Cela est dû au fait que les preuves ZK pour l'accès aux données et les résultats de calcul sont toujours générées à l'avance. En exploitant l'infrastructure de restaking d'Eigenlayer, Brevis coChain permet aux dapps d'adapter le niveau de sécurité cryptographique qu'ils désirent, leur offrant une plus grande flexibilité pour améliorer l'expérience utilisateur. Voici une explication simplifiée de son fonctionnement.

Brevis coChain génèrerait d'abord de manière 'optimiste' un résultat à la demande de coprocessing basée sur le consensus PoS. Ensuite, deux fenêtres de défi sont initiées, l'une est spécifique à l'application et configurable par les développeurs, et l'autre est la fenêtre de réduction globale de coChain plus longue.

Flux de travail Brevis coChain

Au cours de la période de contestation de la demande, les observateurs peuvent soumettre un ZKP contredisant les résultats du cotraitement. Les défis réussis tranchent le proposant et récompensent le challenger. Les propositions rejetées entraînent la confiscation de l’obligation du challenger.

S'il n'y a pas de défis, l'application considérera les résultats comme valides. La fenêtre de réduction globale de coChain est là pour une sécurité renforcée. Même si une application accepte un résultat défectueux, tant que la fenêtre de réduction de coChain est ouverte, les validateurs malveillants peuvent être réduits et les résultats incorrects peuvent être rectifiés.

Comme différents types de coprocesseurs présentent des caractéristiques de coût, de latence et de sécurité distinctes, les applications doivent évaluer leurs besoins pour déterminer le type de coprocesseurs dont elles ont besoin. Si le calcul implique des tâches hautement sécurisées, telles que le calcul des soldes des validateurs sur la chaîne Beacon dans la mise en jeu liquide où des milliards de dollars sont en jeu, les coprocesseurs ZK sont le choix le plus approprié. Ils offrent une sécurité maximale car les résultats peuvent être vérifiés de manière décentralisée. De plus, la latence n'est pas une préoccupation dans de tels scénarios, permettant la génération de preuves dans des délais acceptables.

Pour les tâches qui sont moins sensibles à la latence et qui n’impliquent pas de valeur financière significative, comme la présentation de mesures de réussite on-chain sur vos profils sociaux, un coprocesseur optimiste qui offre le calcul hors chaîne le plus bas peut être préférable.

Pour d'autres tâches, les coprocesseurs cryptonomiques s'avèrent plus rentables lorsque l'assurance achetée couvre la valeur à risque. L'analyse des coûts d'assurance doit être effectuée au cas par cas, fortement influencée par la valeur facilitée par l'application. Ces tâches impliquent souvent une analyse diversifiée et une modélisation des risques.

Une autre façon de catégoriser les coprocesseurs est par type de calcul, avec des exemples tels que :

• RiscZero, conciset=nil;pour le calcul général,
• RitueletModuluspour l'IA,
• EspaceetTempspour les opérations de base de données,
• MegaETHpour les calculs EVM, et plus encore.

L’utilisation de coprocesseurs dans la DeFi est un domaine émergent qui recèle un grand potentiel. Dans ce qui suit, je présenterai les idées et les implémentations existantes sur la façon dont les coprocesseurs pourraient être utilisés dans divers secteurs de la DeFi, notamment le DEX, les marchés monétaires, le jalonnement, le retaking, etc.

DEX

Il y a plusieurs parties prenantes impliquées dans un DEX. Celles-ci incluent les traders, les fournisseurs de liquidité, les teneurs de marché, les gestionnaires de liquidité, les solveurs/remplisseurs, et plus encore. Les coprocesseurs ont le potentiel de rationaliser efficacement des tâches complexes avec différents niveaux d'hypothèses de confiance, améliorant finalement l'expérience pour ces parties prenantes.

Réduction des coûts

Dans un AMM de base, une fonction importante consiste à calculer les paramètres nécessaires lorsque les utilisateurs lancent un échange. Ces paramètres incluent le montant à échanger et à retirer, les frais et le prix après l’échange. Un cas d’utilisation simple pour exploiter la puissance de calcul des coprocesseurs zk tout en maintenant des garanties de confiance consiste à exécuter une partie de la fonction d’échange hors chaîne, puis à effectuer les étapes restantes sur la chaîne. Les zkAMM sont une variante des teneurs de marché automatisés (AMM) qui intègrent des preuves à divulgation nulle de connaissance dans le protocole. Diego (@0xfuturistic) introduit une implémentation de zkAMM (zkUniswap) basée sur Uniswap v3 où une partie du calcul de swap AMM est déchargée vers le zkVM Risc Zero. Un utilisateur lance un échange en faisant une demande on-chain, les entrées d'échange sont prises en charge par le relais, et le calcul est effectué hors chaîne. Le relais publie ensuite la sortie et la preuve. L'AMM vérifie la preuve et règle l'échange.

Bien que le coût de calcul soit encore comparable à celui de l'EVM à l'étape actuelle, il est possible d'atteindre une plus grande efficacité en parallélisant le calcul des échanges avec des chemins indépendants grâce à la fonction de continuation de RiscZero. Essentiellement, l'exécution des échanges peut être effectuée séquentiellement on-chain, mais les étapes d'échange réelles peuvent être calculées en parallèle off-chain en utilisant cette approche. Cela permet de paralléliser la partie la plus lourde pour les lots, ce qui n'est pas nativement possible dans l'EVM. Le coût de vérification pourrait également être amorti en regroupant plusieurs transactions ensemble.

Les utilisateurs ont également la possibilité d'utiliser une couche alternative de disponibilité des données pour envoyer des demandes d'échange. Une autre approche consiste à utiliser la signature EIP712 pour la propagation hors chaîne, ce qui peut réduire davantage les coûts d'échange.

Paramètres Dynamiques

Les coprocesseurs pourraient également être utilisés pour contrôler dynamiquement les frais de swap d'un pool AMM. Le concept d'un frais dynamique est d'augmenter le taux de frais pendant les périodes de volatilité du marché et de le diminuer pendant les périodes de marché plus calmes. Cela profite aux fournisseurs de liquidité passifs, car ils prennent systématiquement le côté défavorable des échanges et subissent une fuite de valeur via la rééquilibrage des pertes par rapport au rééquilibrage (LVR). La mise en œuvre de frais dynamiques vise à résoudre ce problème en compensant adéquatement les fournisseurs de liquidité.

Certains AMM ont déjà cette fonctionnalité. Par exemple, Ambiantutilise un oracle externe qui surveille et prend des instantanés des différents pools Uniswap v3 de différents niveaux de frais toutes les 60 minutes pour choisir le meilleur performant.

Pour fournir des informations supplémentaires sur l’ajustement du taux de frais, des données supplémentaires peuvent être utilisées, à la fois on-chain et off-chain. Cela inclut les transactions historiques effectuées sur la chaîne pour ce pool AMM particulier ou pour la même paire sur différents pools de liquidité (tels que la solution Ambient) ou même des pools sur différents réseaux. Si certaines hypothèses de confiance sont autorisées, des données hors chaîne (par exemple, les données de trading CEX) provenant d’oracles réputés comme Chainlink ou Pyth pourraient également être introduites.

La décision concernant les types de coprocesseurs à utiliser est influencée par la fréquence à laquelle les frais sont ajustés. Dans les cas où une pool nécessite des changements de frais dynamiques très fréquents, les coprocesseurs cryptoéconomiques peuvent être plus adaptés. Cela est dû au fait que les coûts de preuve sont susceptibles de l'emporter sur les coûts d'assurance, qui peuvent être estimés comme la différence de taux de frais multipliée par le volume moyen. En cas de calculs erronés, les fournisseurs de liquidité peuvent facilement réclamer leur assurance facilitée par Eigenlayer pour compenser leur perte de frais.

D'autre part, il y a des pools qui préfèrent des changements de taux de frais moins fréquents. Cependant, ces pools traitent des volumes très importants, ce qui peut faire monter le coût de l'achat d'assurance. Dans de tels cas, les coprocesseurs ZK sont plus adaptés car ils offrent la garantie la plus forte.

Gestionnaire de liquidité active (ALM)

La fourniture passive de liquidité peut être une option attrayante pour les utilisateurs moins expérimentés qui souhaitent percevoir des frais sur leur liquidité inutilisée sans être trop préoccupés par les écarts de prix. Cependant, certains fournisseurs de liquidité (LP) sont plus susceptibles de subir des pertes causées par les écarts de prix et les arbitrages statistiques. Nous avons précédemment discuté de la façon dont l'ajustement dynamique des frais pourrait atténuer ce problème. Mais pourquoi ne pas aller plus loin et changer complètement la forme de la courbe de liquidité ? Il s'agit d'une approche plus sophistiquée de la gestion de la liquidité connue sous le nom de gestionnaires de liquidité actifs (ALM).

Malheureusement, la majorité des ALM existants n’offrent que des stratégies de base comme le rééquilibrage, qui ont un impact limité sur la perception des frais. D’autre part, des techniques un peu plus avancées telles que la couverture à l’aide des marchés monétaires ou des produits dérivés sont disponibles. Cependant, ils entraînent des coûts élevés lorsqu’ils sont exécutés fréquemment sur la chaîne ou s’appuient sur un calcul centralisé de la boîte noire hors chaîne.

Les coprocesseurs ont le potentiel de résoudre les problèmes de coût et de confiance, permettant l'adoption de stratégies avancées. En intégrant des solutions de machine learning de pointe à connaissance nulle (ZKML) telles que Modulus Labs et des plateformes d’IA décentralisées comme Rituel, les gestionnaires de liquidité peuvent tirer parti de stratégies complexes basées sur des données commerciales historiques, des corrélations de prix, de la volatilité, de l'élan, et plus encore tout en profitant des avantages de la confidentialité et de la non-confiance.

Les stratégies de trading à haute fréquence nécessitent un timing précis et une exécution rapide. Bien que les solutions ZK n’atteignent pas toujours la vitesse nécessaire, les coprocesseurs cryptoéconomiques excellent dans ce domaine. Ces coprocesseurs permettent d’exécuter rapidement des algorithmes d’IA, avec des paramètres mis à jour aussi fréquemment que le temps de bloc le permet. Cependant, l’utilisation de cette approche entraîne des coûts d’assurance. Il peut être difficile d’estimer avec précision ces coûts en raison des risques potentiels tels que la mauvaise gestion des fonds par les gestionnaires ou la participation à des contre-transactions. Le processus de prise de décision consiste à trouver un équilibre entre les rendements supplémentaires et les frais d’assurance, qui dépendent en fin de compte du volume total qui se produit dans le délai mesuré par le coprocesseur. La mise à l’échelle de ce processus peut également s’avérer difficile en raison du capital disponible pour l’accès dans un seul AVS et de la capacité de prédire la valeur à risque à un moment donné.

Distribution des récompenses basée sur des métriques

Alors que chaque transaction est enregistrée sur la blockchain, les contrats intelligents sont confrontés à des défis pour déterminer les métriques représentées par ces transactions, telles que le volume des transactions, le nombre d'interactions, la TVL par unité de temps, etc. On pourrait suggérer d'utiliser des solutions d'indexation comme Dune Analytics, qui fournissent des informations précieuses. Cependant, s'appuyer sur une indexation hors chaîne introduit une couche supplémentaire de confiance. C'est là que les coprocesseurs apparaissent comme une solution prometteuse.

Une mesure particulièrement précieuse en chaîne est le volume. Par exemple, le volume accumulé dans un pool AMM spécifique associé à une adresse particulière dans certains blocs. Cette mesure est très bénéfique pour les DEX. Un cas d'utilisation est de permettre de définir différents niveaux de frais pour les utilisateurs en fonction de leur volume de trading. Cette approche est similaire aux frais dynamiques, mais au lieu de se baser sur des données générales, elle examine des données spécifiques à une adresse.

Brevisfournit un exemple intéressant où la preuve de volume pourrait être combinée avec un remboursement de frais personnalisé Uniswap hooks pour offrir des remises de frais basées sur le volume similaires aux traders VIP sur les CEX.

Plus précisément, Uniswap v4 peut lire les transactions historiques d'un utilisateur au cours des 30 derniers jours, analyser chaque événement de transaction avec une logique personnalisée et calculer le volume des échanges avec Brevis. Le volume des échanges et une preuve ZK générée par Brevis sont ensuite vérifiés de manière décentralisée dans un smart contract Hook Uniswap v4, qui détermine et enregistre de manière asynchrone le niveau de frais VIP de l'utilisateur. Après la vérification de la preuve, toute transaction future d'un utilisateur éligible déclenchera la fonction getFee() pour simplement consulter l'enregistrement VIP et réduire les frais de transaction en conséquence.

Le coût de l'obtention de la certification en tant que "VIP" est également peu élevé (environ 2,5 $ sur la base de ses résultats de référence en matière de performance). Les coûts peuvent être réduits davantage en regroupant plusieurs utilisateurs à l'aide de solutions comme NEBRA. Le seul compromis est la latence, car il a fallu environ 400 secondes pour accéder et calculer 2600 transactions Uniswap on-chain. Cependant, cela est moins préoccupant pour les fonctionnalités qui ne sont pas sensibles au temps.

Pour répondre aux préoccupations en matière de latence, les dapps pourraient exploiter le coChain de Brevis. Les résultats sont calculés et livrés rapidement grâce à un mécanisme de consensus PoS pour minimiser les retards. En cas d'activités malveillantes, un ZKP peut être utilisé pendant la fenêtre de défi pour pénaliser les validateurs voyous.

Par exemple, dans le scénario des frais VIP mentionné précédemment, si plus de ⅔ des validateurs de coChain attribuent de manière trompeuse un niveau VIP plus élevé à certains utilisateurs dans un “tableau de recherche de niveau VIP” lié au crochet de frais dynamique, certains utilisateurs pourraient initialement bénéficier de plus grandes réductions de frais. Cependant, lorsqu'une preuve ZK est présentée pendant la fenêtre de réduction, démontrant que les niveaux VIP sont incorrects, les validateurs malveillants seront pénalisés. Les niveaux VIP erronés peuvent alors être rectifiés en activant le rappel de défi pour mettre à jour le tableau de recherche de niveau VIP. Pour des scénarios plus prudents, les développeurs peuvent choisir de mettre en place des fenêtres de défi au niveau de l'application étendues, offrant une couche supplémentaire de sécurité et d'adaptabilité.

Mining de liquidité

Le minage de liquidité est une forme de distribution de récompenses destinée à amorcer la liquidité. Les DEX pourraient acquérir une compréhension plus profonde du comportement de leurs fournisseurs de liquidité grâce aux coprocesseurs et distribuer de manière appropriée les récompenses ou incitations au minage de liquidité. Il est important de reconnaître que tous les LP ne se ressemblent pas; certains agissent comme des mercenaires tandis que d'autres restent fidèles en tant que croyants à long terme.

L'incitation optimale à la liquidité devrait évaluer rétrospectivement le dévouement des LP, en particulier pendant les fluctuations significatives du marché. Ceux qui apportent constamment leur soutien au pool pendant de telles périodes devraient recevoir les plus grandes récompenses.

Système de réputation Solver/Filler

Dans un avenir axé sur l'intention de l'utilisateur, les solveurs/remplisseurs jouent un rôle crucial en simplifiant les transactions complexes et en obtenant des résultats plus rapides, moins chers ou meilleurs. Cependant, il y a des critiques constantes concernant le processus de sélection des solveurs. Les solutions actuelles comprennent :

• Un système sans permission qui utilise des enchères hollandaises ou des escalateurs de frais. Cependant, cette approche est confrontée à des défis pour garantir un environnement d'enchères concurrentiel et sans permission, ce qui pourrait entraîner des problèmes de latence ou même une non-exécution pour les utilisateurs.
• Un système sans permission nécessite de miser des jetons pour participer, ce qui crée une barrière financière à l'entrée et peut manquer de conditions de réduction/pénalité claires, ou d'applications transparentes et sans confiance.
• Alternativement, une liste blanche de solveurs peut être établie en fonction de la réputation et de la relation.

Le chemin à venir doit être à la fois sans permission et sans confiance. Cependant, pour y parvenir, il est nécessaire d'établir des lignes directrices pour distinguer les grands résolveurs des moins grands. En utilisant des coprocesseurs ZK, des preuves vérifiables peuvent être générées pour déterminer si certains résolveurs répondent ou non à ces lignes directrices. Sur la base de ces informations, les résolveurs peuvent être soumis à des flux d'ordre prioritaires, des réductions, des suspensions ou même des mises sur liste noire. Idéalement, les meilleurs résolveurs recevraient plus de flux de commandes tandis que les moins bons en recevraient moins. Il est important de revoir et de mettre à jour périodiquement ces évaluations pour éviter l'enracinement et promouvoir la concurrence, donnant ainsi aux nouveaux arrivants une chance égale de participer.

Oracle des prix résistant à la manipulation

Uniswap a déjà introduit des oracles intégrés dans ses versions v2 et v3. Avec la sortie de la v4, Uniswap a élargi les possibilités pour les développeurs en introduisant des options d'oracle plus avancées. Cependant, il reste des limitations et des contraintes en ce qui concerne les oracles de prix on-chain.

Tout d'abord, il y a la question du coût. Si un coprocesseur calculant un oracle de prix peut offrir des améliorations en termes de coût, il pourrait servir de solution plus abordable. Plus les conceptions de l'oracle de prix sont complexes, plus le potentiel d'économies de coûts est grand.

Deuxièmement, le pool d’oracles de prix on-chain est toujours susceptible d’être manipulé. Pour remédier à ce problème, il est courant d’agréger les prix provenant de différentes sources et d’effectuer des calculs pour créer un oracle de prix plus résistant à la manipulation. Les coprocesseurs ont la capacité de récupérer l’historique des transactions à partir de différents pools, même sur différents protocoles, ce qui permet de générer un oracle de prix résistant à la manipulation avec des coûts compétitifs pour l’intégration avec d’autres protocoles DeFi.

Données DIAtravaille sur des oracles basés sur ZK avec O(1) Labsde l'écosystème Mina. L'approche est similaire - prendre des données de marché et effectuer des calculs plus sophistiqués hors chaîne, sans frais de gaz et autres contraintes d'exécution, mais avec la capacité de vérifier l'intégrité du calcul lorsque le résultat est servi sur chaîne. Cela peut rendre possible de compléter des flux de prix simples avec d'autres données de marché telles que la profondeur, pour aider à évaluer l'impact des liquidations, ainsi que des métadonnées pour permettre aux protocoles de personnaliser leur flux.

Systèmes de Marge

Pour surmonter les limitations computationnelles de la technologie blockchain, de nombreuses plateformes de produits dérivés déplacent fréquemment certains composants, tels que les systèmes de gestion des risques, hors chaîne.

@0x_emperoret@0xkranepropose un cas d'utilisation intéressant des coprocesseurs où la logique de la marge est transparente et vérifiable. Dans de nombreux échanges, des systèmes de gestion des risques sont en place pour éviter un effet de levier excessif. Un exemple est le système de déclenchement automatique (ADL), qui alloue stratégiquement les pertes aux traders rentables afin de compenser les pertes subies par les traders liquidés. Essentiellement, il redistribue les pertes entre les traders rentables pour couvrir les dettes impayées résultant de ces liquidations.

Les utilisateurs peuvent avoir des questions concernant la fermeture forcée de leurs positions. Pour y répondre, l'échange pourrait utiliser des coprocesseurs pour exécuter la logique du moteur de marge en utilisant des données on-chain et générer des preuves pour vérifier le calcul correct. Comme les occurrences d'ADL sont rares, les préoccupations concernant la latence et les coûts de preuve sont minimes. Cependant, l'utilisation de coprocesseurs Zk sans confiance et vérifiables améliore la transparence et l'intégrité, ce qui est bénéfique pour l'échange et ses utilisateurs.

Marché monétaire

En exploitant les informations issues des données historiques on-chain, les coprocesseurs ont le potentiel d’améliorer la gestion des risques pour les LP et les protocoles de prêt. De plus, les protocoles peuvent offrir une expérience utilisateur améliorée basée sur des analyses basées sur les données.

Lorsque Curve a subi une exploitation il y a quelques mois, l'attention s'est tournée vers les marchés monétaires avec des millions de jetons CRV en danger de liquidation. Les prêteurs Frax ont trouvé un certain réconfort dans les hausses agressives des taux d'intérêt du protocole lorsque le ratio prêt-valeur (LTV) est devenu malsain. Cela a incité le fondateur de Curve à rembourser la dette plus rapidement. Cependant, les parties prenantes d'AAVE ont exprimé des préoccupations et ont engagé des discussions sur la réduction de la capacité de garantie et éventuellement l'arrêt du marché. Leur crainte était liée à la possibilité d'une liquidité insuffisante pour des liquidations réussies, ce qui pourrait entraîner des créances douteuses et une vulnérabilité aux conditions du marché.

Heureusement, la crise a été résolue. Il est important de passer régulièrement en revue les actifs répertoriés sur les marchés monétaires, en mettant l'accent particulièrement sur leur liquidité sur le marché, surtout lors d'événements de liquidation. Les actifs illiquides devraient se voir attribuer un ratio prêt-valeur (LTV) plus bas et une capacité de garantie.

Cependant, le processus de prise de décision pour les changements de paramètres de risque dans les marchés monétaires est souvent réactif, comme nous l'avons observé dans la situation du CRV. Nous avons besoin de mesures plus rapides et proactives, y compris des solutions sans confiance. Des discussions ont eu lieu concernant l'utilisation de Contrôles de rétroactionajuster dynamiquement les paramètres en fonction des métriques on-chain, telles que l'utilisation de liquidité, au lieu de s'appuyer sur une courbe prédéterminée. Un concept intrigant implique un pool de prêt qui vérifie la preuve de liquidité on-chain pour un marché spécifique. Le contrôleur reçoit une preuve calculée à partir de métriques on-chain par des coprocesseurs ZK, indiquant quand un actif n'est plus suffisamment liquide au-delà d'un certain seuil. Sur la base de ces informations, le contrôleur peut prendre différentes mesures, telles que l'ajustement des taux d'intérêt, la définition de plafonds de LTV, la suspension du marché, voire sa discontinuation complète.

Des stratégies plus avancées pourraient inclure l'ajustement périodique de la capacité d'emprunt de garantie ou de la courbe des taux d'intérêt en fonction de la liquidité on-chain de la semaine précédente. Le seuil exact serait déterminé grâce à des discussions au sein du DAO. Il pourrait être déterminé en tenant compte de facteurs tels que le volume historique on-chain, les réserves de jetons, le glissement minimal pour un échange global, et ainsi de suite.

Pour les prêteurs et les emprunteurs, les marchés monétaires peuvent offrir des services et des expériences améliorés, similaires aux programmes de remise sur les frais pour les traders VIP dans les DEX. Il existe des solutions de pointage de crédit qui visent à créer un profil complet des utilisateurs on-chain. L’objectif est d’encourager les bons comportements, tels qu’une gestion efficace des risques démontrée en évitant les événements de liquidation, en maintenant des ratios LTV moyens sains, en effectuant des dépôts importants stables, etc. Des récompenses Trustless peuvent être accordées pour ces comportements positifs, notamment des taux d’intérêt meilleurs et plus lisses par rapport aux utilisateurs moyens, des ratios LTV et de liquidation maximaux plus élevés, un temps tampon pour la liquidation, des frais de liquidation moins élevés, etc.

Mise en jeu et réaffectation

Oracle minimisé par la confiance

Depuis la fusion et la mise à niveau Shanghai/Shapella, le marché du jalonnement liquide est devenu le plus grand marché dans le domaine de la finance décentralisée. Notamment, Lido a accumulé plus de 29 milliards de dollars de TVL, tandis que Rocketpool a plus de 3,6 milliards de dollars de TVL.

Compte tenu du montant substantiel d'argent impliqué, il est important de noter que les oracles utilisés pour rapporter des informations, telles que les soldes précis des validateurs associés sur la chaîne de balises, sont toujours fiables. Ces oracles jouent un rôle crucial dans la distribution des récompenses aux parties prenantes sur la couche d'exécution.

Actuellement, Lido emploie un mécanisme de quorum 5-sur-9 et maintient une liste de membres de confiance pour se prémunir contre les acteurs malveillants. De même, Rocketpool fonctionne avec un Oracle DAO sur invitation composé d'opérateurs de nœuds qui sont chargés de mettre à jour les informations de récompense dans les contrats intelligents sur la couche d'exécution.

Cependant, il est essentiel de reconnaître que si la majorité des tiers de confiance étaient compromis, cela pourrait nuire considérablement aux détenteurs de jetons de participation liquide (LST) et à l'ensemble de l'écosystème DeFi construit sur les LST. Pour atténuer le risque de rapports d'oracle erronés / malveillants, Lido a mis en placeune série de vérifications de santéqui sont implémentées dans le code de la couche d'exécution du protocole.

Avec l'introduction de l'EIP-4788 "racine du bloc de balise dans l'EVM", il devient plus facile pour les coprocesseurs d'accéder aux données et de les traiter sur la couche de consensus.=nill; Fondation, Succintet DendrETH développent tous leur propre oracle de TVL ZK-proof pour Lido. Pour garantir une sécurité maximale, Lido pourrait utiliser une architecture multi-proof.

Prenons pour exemple la conception de =nil; : à un niveau élevé, l'oracle obtient des informations essentielles des couches Consensus et Exécution, telles que l'en-tête du bloc Beacon, l'état du Beacon, les adresses des contrats Lido, etc. Il calcule ensuite un rapport sur la valeur totale bloquée et le nombre de validateurs pour tous les validateurs Lido. Ces données, ainsi que des informations supplémentaires nécessaires, sont transmises au producteur de preuves et exécutées sur des circuits spécialisés pour générer une preuve ZK. L'oracle récupère la preuve et soumet à la fois la preuve et son rapport au contrat intelligent pour vérification. Notez que ces conceptions d'oracle sont encore à l'étape de test et sont sujettes à des modifications.

Cependant, il convient de noter qu'il y aura toujours une sorte de données qui ne pourront peut-être pas être prouvées du côté EL en raison de la nature limitée de ce qui est envoyé via 4788 et que des oracles peuvent encore être nécessaires pour ce sous-ensemble de données.

De plus, les oracles à preuve ZK minimisant la confiance en sont encore à leurs balbutiements. L'approche proposée par les contributeurs de Lido est d'utiliser les informations fournies par les oracles ZK comme un "test de bon sens" par rapport au travail effectué par les oracles de confiance jusqu'à ce que ces implémentations ZK puissent être mises à l'épreuve. Il serait trop risqué de transférer toute la confiance actuellement accordée au système d'oracle vers des systèmes ZK à ce stade.

De plus, les preuves pour des données de cette taille sont très lourdes en termes de calcul (par exemple, cela peut prendre même 30 à 45 minutes) et très coûteuses, donc elles ne sont pas un remplacement adapté à l'état actuel de maturation de la technologie pour des tâches telles que les rapports quotidiens ou même intra-journaliers.

Analyse des risques et des performances des validateurs

Les validateurs jouent un rôle crucial dans l'écosystème du jalonnement. Ils bloquent 32 ETH sur la chaîne de balises et fournissent des services de validation. S'ils se comportent correctement, ils reçoivent des récompenses. Cependant, s'ils se comportent mal, ils font face à des sanctions. Les validateurs sont gérés par des opérateurs de nœuds qui ont différents profils de risque. Ils peuvent être sélectionnés (par exemple, l'ensemble de validateurs sélectionnés de Lido), liés (par exemple, Rocket pool, Lido’s )CSM) ou des validateurs solos. Ils peuvent choisir d'exécuter leurs services dans des centres de données cloud ou à domicile, dans des régions favorables ou défavorables à la réglementation des cryptomonnaies. De plus, les validateurs peuvent utiliser la technologie DVT pour diviser les nœuds internes ou se regrouper en clusters afin d'améliorer la tolérance aux pannes. Avec l'émergence de l'Eigenlayer et de divers AVS (Services de Validation Active), les validateurs pourraient potentiellement offrir des services supplémentaires en plus de la validation pour Ethereum. Sans aucun doute, le profil de risque des validateurs sera complexe, ce qui rend essentiel d'évaluer avec précision leurs profils de risque. Avec de bonnes analyses de risque et de performance des validateurs, cela ouvre la porte à des possibilités infinies, y compris :

Tout d'abord, l'évaluation des risques joue un rôle crucial dans l'établissement d'un ensemble de validateurs sans permission. Dans le contexte de Lido, l'introduction du routeur de mise en jeu et du futur EIP-7002 "Sorties déclenchables par la couche d'exécution" pourrait ouvrir la voie à la possibilité de rejoindre et de quitter les validateurs sans permission. Les critères de rejoindre ou de quitter peuvent être déterminés en fonction du profil de risque et des analyses de performance tirées des activités de validation passées d'un validateur.

Deuxièmement, la sélection des nœuds dans DVT. Pour un staker solo, il peut être bénéfique de choisir d'autres nœuds pour créer un cluster DVT. Cela peut aider à atteindre une tolérance aux pannes et à augmenter les rendements. La sélection des nœuds peut être basée sur diverses analyses. De plus, la formation du cluster peut être sans autorisation, permettant à des nœuds ayant eu de bonnes performances historiques de rejoindre tandis que les nœuds sous-performants peuvent être retirés.

Troisièmement, le reposage. Les protocoles de reposage liquide permettent aux reposants de participer au marché du reposage Eigenlayer. Ces protocoles produisent non seulement des reçus liquides appelés jetons de reposage liquide (LRT), mais visent également à sécuriser les meilleurs rendements ajustés en fonction du risque pour les reposants. Par exemple, l'un des Renzo’sLes stratégies consistent à construire le portefeuille AVS avec le ratio de Sharpe le plus élevé tout en respectant une perte maximale cible spécifiée, en ajustant la tolérance au risque et les pondérations grâce au DAO. À mesure que davantage de projets AVS sont lancés, l'importance d'optimiser le support pour des AVS spécifiques et de sélectionner les opérateurs AVS les plus adaptés devient de plus en plus cruciale.

Jusqu'à présent, nous avons mis l'accent sur l'importance de l'analyse des risques et des performances des validateurs, ainsi que sur la large gamme de cas d'utilisation qu'elle permet. Cependant, la question demeure : Comment évaluons-nous avec précision le profil de risque des validateurs ? Une solution potentielle est en cours de développement par Protocole Ion.

Ion Protocol est une plateforme de prêt qui utilise des données validées par des validateurs. Il permet aux utilisateurs d'emprunter de l'ETH contre leurs positions mises en jeu et réinvesties. Les paramètres du prêt, y compris les taux d'intérêt, les ratios prêt/valeur et la santé de la position, sont déterminés par des données de la couche de consensus et protégés par des systèmes de données ZK.

Ion collabore avec l'équipe Succinct sur PrécisionUn cadre sans confiance pour vérifier l'état économique des validateurs sur la couche de consensus d'Ethereum. L'objectif est de créer un système vérifiable qui évalue précisément la valeur des actifs de garantie, atténuant tout risque de manipulation ou de réduction. Une fois établi, ce système pourrait faciliter les processus d'origination des prêts et de liquidation.

Ion collabore également avec Modulus Labs, exploitant ZKML pour une analyse sans confiance et la paramétrisation des marchés de prêt, y compris les taux d'intérêt, les LTV et d'autres détails du marché pour minimiser l'exposition au risque en cas d'incidents de réduction aberrants.

Conclusion

DeFi est vraiment remarquable car elle révolutionne la manière dont les activités financières sont menées, éliminant le besoin d'intermédiaires et réduisant les risques de contrepartie. Cependant, DeFi peine actuellement à offrir une excellente expérience utilisateur. La bonne nouvelle est que cela est sur le point de changer avec l'introduction de coprocesseurs qui permettront aux protocoles DeFi d'offrir des fonctionnalités basées sur les données, d'améliorer l'UX et de peaufiner la gestion des risques. De plus, à mesure que l'infrastructure d'IA décentralisée progresse, nous avançons vers un avenir de DeFi intelligent.

Avertissement：

1. Cet article est repris de [ miroir], Tous les droits d'auteur appartiennent à l'auteur original [lukewasm.eth]. If there are objections to this reprint, please contact thePorte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.