Conception et mise en œuvre d'un système de prix distribué Oracle Machine

Pour résoudre le problème de point de défaillance unique, certains services d'Oracle Machine ont adopté un design distribué. Prenons l'exemple d'un service fournissant le prix du bitcoin en dollars, un certain système agrège 31 Oracle Machines de prix indépendants pour fournir des données fiables aux utilisateurs.

La conception contractuelle de cet agrégateur permet à plusieurs oracles hors chaîne de répondre aux demandes des utilisateurs en appelant la méthode de transmission pour fournir des données de prix. Ces oracles hors chaîne sont généralement des (EOA) de comptes externes qui peuvent fournir des données non seulement pour la paire BTC/USD, mais aussi pour d’autres paires de devises telles que Ethereum/USD.

Les contrats sur la chaîne passent par une série d'étapes de validation strictes lors du traitement des données fournies par l'Oracle Machine :

1. Tout d'abord, lisez l'état actuel du contrat et effectuez une vérification préliminaire.
2. Effectuer les préparatifs nécessaires.
3. Utilisez la fonction ecrecover() pour vérifier chaque donnée de signature, en vous assurant que la valeur de hash est le résultat de l'opération de hachage sur _report. Vérifiez également que le rôle du signataire est Signer et empêchez les signatures répétées.
4. Vérifiez si les valeurs observées sont triées dans l'ordre et sélectionnez la médiane. Assurez-vous que cette médiane ne dépasse pas la plage de seuils prédéfinie.
5. Enregistrez la réponse de l'Oracle Machine dans s_transmissions et effectuez une validation supplémentaire.

Certains systèmes étendent davantage ce processus de validation, par exemple en comparant si les écarts de prix fournis par différents Oracle Machine sont dans des limites acceptables pour renforcer la fiabilité des données.

Pour simplifier le processus d'obtention des prix de plusieurs tokens, certaines plateformes ont introduit le concept de Feed Registry. Cela peut être considéré comme un agrégateur de PriceFeeds, ayant déjà intégré plusieurs priceFeed. En utilisant le Feed Registry, les développeurs peuvent lire directement les données de prix, sans avoir à configurer un priceFeed séparé pour chaque token, ce qui réduit considérablement les coûts de gouvernance et améliore la flexibilité.

! Chainlink (partie 2) de la série explicative Oracle](https ://img-cdn.gateio.im/social/moments-28d519adb5b491a0596a00eed45731eb)

En ce qui concerne le mécanisme de tarification, certains systèmes avancés d'Oracle Machine utilisent une stratégie d'agrégation de données multi-niveaux :

1. Agrégation des sources de données : collectez des données brutes sur les prix des principaux échanges centralisés et décentralisés.
2. Agrégation des opérateurs de nœuds : des opérateurs de nœuds indépendants obtiennent des données de plusieurs fournisseurs de services d'agrégation de données et les traitent.
3. Agrégation de réseau Oracle : agrégation de données au niveau de l’ensemble du réseau, généralement à l’aide de méthodes telles que les calculs médians.

Ce mécanisme d'agrégation multicouche aide à améliorer l'exactitude et la fiabilité des données. Cependant, en raison de mécanismes de déclenchement de mise à jour tels que le seuil de biais et le seuil de battement, les mises à jour de prix de certains systèmes peuvent être relativement lentes, variant de quelques minutes à plusieurs heures. Bien que ce design renforce la sécurité, il limite également son utilisation dans des scénarios d'application sensibles aux prix en temps réel.

Dans l'ensemble, le système de prix Oracle Machine décentralisé présente des avantages significatifs en matière de fourniture de données fiables, mais il est toujours nécessaire de peser ses caractéristiques en fonction des besoins spécifiques de l'application lors du choix et de l'utilisation.