DORA: Accord d’Oracle Distribué

Ce post est le litepaper de DORA. Pour une description plus en profondeur de notre protocole d’orale distribué, téléchargez le whitepaper complet ici.

Qu’est-ce qu’un Oracle? Pourquoi sont-ils nécessaires?

Un oracle est un mécanisme qui connecte une blockchain au monde extérieur à cette chaîne. Une blockchain peut être considérée comme une séquence immuable de transitions d’état émergeant à la suite de l’exécution d’un ordinateur déterministe. Par déterministe, nous entendons que chaque instruction de cet ordinateur produit la même sortie lorsqu’elle reçoit la même entrée. Cet ordinateur déterministe est une abstraction. En réalité, il est mis en œuvre par un réseau de nombreux ordinateurs exécutant un protocole de consensus pour déterminer la séquence des instructions et leurs résultats.

Du non-déterminisme au déterminisme

Pouvons-nous avoir une instruction getCurrentPrice(“BTC”) dans un tel ordinateur ? Ce n’est pas si simple. Pourquoi ? Parce que la sortie de cette instruction serait différente en fonction du moment où elle est exécutée et d’où les prix sont récupérés. C’est rédhibitoire, car cela viole la propriété fondamentale de notre ordinateur d’être déterministe.

Alors, que peut-on faire pour remédier à cela ? L’une des façons de résoudre ce problème est de fournir le contexte entier de l’instruction en tant qu’entrée. Par exemple, prenons une instruction comme getPrice(“BTC”,”SomeExchange”,”11:59:59 UTC 7 dec 2022"). Dans cette instruction, nous spécifions explicitement que nous devons récupérer le prix à ce moment-là et à partir d’où. Cependant, nous avons encore quelques problèmes à résoudre.

Conservation

Nous supposons que quelle que soit la date à laquelle nous exécutons cette instruction, nous obtiendrons le même résultat. Que se passerait-il si nous essayions d’exécuter cette instruction dans dix ans et que “SomeExchange” n’avait pas ces données disponibles ? Que se passerait-il si, hypothétiquement, “SomeExchange” n’avait conservé que cinq ans de données en raison de leur politique de conservation des données à ce moment-là ? Que se passerait-il si une corruption de données s’était produite sur cette donnée ? Essentiellement, ce dont nous avons besoin est une archive fiable et immuable afin d’obtenir exactement le même résultat même si nous exécutons cette instruction dans dix ans. Eh bien, nous connaissons déjà un tel mécanisme. Une blockchain elle-même ! Nous pouvons avoir une instruction putPrice(CommodityCode, source, time, value) pour stocker la valeur de CommodityCode obtenue de la source à l’heure dans la blockchain elle-même, qui peut être récupérée en toute sécurité ultérieurement.

Authenticité

Cependant, nous avons encore un problème. Comment savons-nous que la valeur provient bien de la source obtenue à l’heure indiquée ? Si la source elle-même signe numériquement et certifie qu’à l’heure indiquée, le prix de CommodityCode est la valeur, alors nous avons terminé. C’est en effet ainsi que fonctionnent certains oracles. Hélas, toutes les sources d’information ne signent pas numériquement leurs données et ne les placent pas dans la blockchain. De plus, le fait qu’une source de données signe ses données ne signifie pas que les données signées sont effectivement exactes. Dans un tel cas, nous avons besoin d’un ensemble d’entités qui peuvent apposer un sceau d’authenticité et certifier que la valeur est effectivement le prix de CommodityCode à la source et à l’heure indiquée.

Agrégation

Lorsqu’il existe plusieurs bourses et sources d’informations, il n’y a pas de valeur unique d’une marchandise. Les marchandises peuvent être échangées à des prix différents sur différentes bourses. De nombreuses applications blockchain et contrats intelligents nécessitent une seule valeur du prix d’une marchandise. Dans un tel cas, nous devons agréger les prix provenant de plusieurs sources d’informations en une seule valeur représentative. Alors, qu’est-ce qu’un oracle ? En bref, un oracle est un mécanisme qui prend des informations de plusieurs sources et place des informations représentatives certifiées authentiques dans une blockchain de manière déterministe afin que les applications blockchain et les contrats intelligents modernes puissent utiliser ces informations.

Qu’est-ce que DORA (Accord d’Oracle Distribué)?

<div class=”vimeo-space” style=”padding: 56.25% 0 0 0; position: relative;” > <iframe title=”vimeo-player” src=”https://player.vimeo.com/video/786829774?h=8329fb44dc" style=”height: 100%; left: 0; position: absolute; top: 0; width: 100%;” frameborder=”0" allowfullscreen></iframe> </div> <script src=”https://player.vimeo.com/api/player.js"></script>

Lorsqu’il existe plusieurs sources d’informations qui ne signent pas leurs données, nous avons besoin d’un mécanisme qui agrège toutes ces informations en une seule valeur représentative et les place dans la blockchain tout en rendant cela tolérant aux fautes byzantines, au moins dans une certaine mesure.

Une faute byzantine fait référence à une faute d’une entité où l’entité est soit non réactive, soit peut dévier arbitrairement d’un protocole convenu, éventuellement de manière malveillante.

En l’absence de fautes byzantines, une seul node recueillant les informations de plusieurs sources est suffisant. Cependant, en présence de fautes byzantines, nous aurions besoin de plusieurs nodes.

Lorsque tous les nodes peuvent fournir une valeur en entrée et que certains des nodes sont byzantins, le défi pour les nodes honnêtes restants est de s’entendre sur une seule valeur représentative, ce que l’on appelle le problème DORA (Accord Oracle Distribué). Formellement :

Un protocole DORA parmi n nodes p1, p2, …, pn, chaque node ayant des entrées vi, pour une distance d’accord donnée D, garantit que :

[Termination] : Tous les nodes honnêtes finissent par s’accorder sur une valeur.

[Accord] : La valeur de sortie S pour tous les nodes est la même.

[Validité] : Hmax ≤ S ≤ Hmax, où Hmin et Hmax représentent les valeurs minimale et maximale des nodes honnêtes. Nous désignons la valeur de sortie de DORA comme Supra-valeur ou S-valeur ou S.

Valeur représentative

Notez que nous exigeons non seulement que tous les nodes convergent vers une seule valeur, mais qu’elle doit être une valeur représentative. La propriété de validité mentionnée ci-dessus stipule que S doit se situer quelque part entre les valeurs minimale et maximale des nodes honnêtes. Cependant, cela ne semble pas représentatif. Comment toute valeur entre les valeurs minimale et maximale des nodes honnêtes peut-elle être considérée comme représentative des valeurs de tous les nodes honnêtes ? C’est une question valable. On pourrait penser que prendre la moyenne de toutes les valeurs pourrait être un bon candidat pour créer une valeur représentative. Cette pensée est tout à fait valable, et pourtant, naïve.

Non seulement nous avons des nodes byzantins, mais nous ne savons même pas lesquels sont byzantins et lesquels sont honnêtes. Pendant le calcul de la moyenne, même si une seule valeur d’une node byzantine s’introduit, la sortie peut dévier arbitrairement de la moyenne de toutes les valeurs honnêtes. La médiane offre une alternative robuste en tant que valeur représentative car elle est un agrégateur statistique qui peut tolérer une corruption des données jusqu’à 50%.

Malheureusement, en présence d’un tiers de nodes byzantins, la garantie donnée dans la propriété de validité ci-dessus est la meilleure garantie possible que quiconque puisse fournir. Veuillez vous référer au whitepaper de DORA pour une preuve formelle de ceci.

Architecture de l’Oracle de Supra

Le service Oracle de Supra suppose qu’un SMR (State Machine Replication) alias un service blockchain soit disponible.

Qu’est-ce qu’un SMR?

De manière informelle, SMR (State Machine Replication) offre un service d’ordonnancement tel que tout message envoyé à ce service d’ordonnancement devient partie d’un ordre total, et chaque node lisant des messages à partir de ce service observe le même ensemble de messages dans le même ordre total exact.

Architecture de la Tribu-Clan

Une tribu est un ensemble de nodes. Une tribu peut continuer à fonctionner en toute sécurité et à progresser sur les services qu’elle offre tant que le nombre de nodes devenant byzantins est inférieur à un tiers de tous les nodes.

D’un clan, nous tirons de manière uniformément aléatoire des sous-ensembles de nodes. Nous appelons chaque tel sous-ensemble un clan. Chaque clan est tiré de manière à que la probabilité d’avoir la moitié ou plus de nodes byzantins dans un clan soit négligeable. Notre protocole DORA est conçu de telle sorte que dans des circonstances normales, nous n’avons besoin que d’un clan pour calculer et s’entendre sur une valeur S. Cela signifie que DORA peut fonctionner avec un plus petit nombre de nodes et peut résister à une plus grande fraction des nodes devenant byzantins.

Fragmentation des marchandises

Un fournisseur de services oracle peut avoir besoin de fournir une valeur représentative pour de nombreuses marchandises différentes, telles que BTC/USD, ETH/USD, etc. Comme nous n’avons besoin que d’un clan pour exécuter le protocole DORA, nous divisons la responsabilité des différentes marchandises également entre différents clans. Par exemple, si nous devons agréger et fournir des valeurs S pour 100 marchandises différentes et si nous avions 4 clans, alors chaque clan peut se voir confier la responsabilité de calculer des valeurs S pour 25 marchandises.

Le protocole DORA

Maintenant, regardons comment fonctionne une ronde du protocole DORA.

Collecte de données

Chaque node du clan se voit attribuer un ensemble de sources de données pour obtenir la valeur du prix d’une marchandise. Comme vous pouvez le voir dans l’image ci-dessus, chaque node obtient des données de plusieurs sources. Pourquoi cela ? Eh bien, un clan ne peut fonctionner correctement que si moins de la moitié des nodes du clan sont byzantins. Par exemple, imaginez un scénario où nous avons 51 nodes dans notre clan, dont 25 sont déjà devenus byzantins. Jusqu’ici, tout va bien. Maintenant, imaginez que nous ayons une conception où chaque node obtient ses données uniquement à partir d’une seule source de données.

Et si la source de données devient byzantine? Même une node honnête, si elle reçoit des données d’une seule source byzantine, présente un comportement byzantin. Ordures en entrée, ordures en sortie. Maintenant, nous avons donc 26 sur 51 nodes présentant un comportement byzantin. Il n’y a désormais aucune garantie que le clan puisse produire une quelconque valeur, et si c’est le cas, que cette valeur soit proche d’un prix représentatif idéal d’une marchandise. Cela rend l’oracle effectivement inutile.

Il est vrai que les prix des actifs sur certaines bourses peuvent dévier considérablement en raison de problèmes techniques ou d’autres raisons. Il est donc sage de ne pas se fier uniquement à une seule source d’information. Dans notre conception, si nous voulons résister à la défaillance de fd sources de données, nous exigeons que chaque node écoute au moins 2fd+1 sources de données pour obtenir le prix d’une marchandise.

Notez également qu’il y a plusieurs nodes récupérant des données de chaque source de données. Pourquoi cela ? Eh bien, imaginez que nous soyons maintenant dans une situation où la source de données est honnête mais que la node est byzantine. Le prix fourni par la source de données honnête peut ne pas être du tout pris en compte lors du calcul de la valeur S. C’est pourquoi nous nous assurons qu’il existe plusieurs chemins par lesquels cette information peut être intégrée dans le calcul. Maintenant, nous devons examiner une autre subtilité.

Par exemple, si nous avons un total de 10 sources de données et que chaque node doit écouter au moins 3 sources de données, comment pouvons-nous être sûrs que les prix de chaque source de données parviennent dans le calcul final ? Et si tous les nodes écoutent les 3 premières sources de données et que personne n’écoute les 7 restantes ? Pour éviter cette situation, l’attribution des sources de données aux nodes est effectuée via une VRF (Fonction Aléatoire Vérifiable). De cette manière, nous pouvons nous assurer que toutes les sources de données alimentent leurs données à un nombre approximativement égal de nodes dans le clan.

Agrégation au niveau de la node

Une fois qu’une node a reçu des prix de plusieurs sources de données, il calcule sa médiane. Cette valeur médiane est garantie de se situer entre les valeurs minimale et maximale des sources de données honnêtes. Ainsi, tant qu’une node reçoit la majorité des prix des sources de données honnêtes, il calculera une valeur qui est bornée par des valeurs honnêtes.

Rôle des Agrégateurs

Une fois qu’une node a calculé une valeur, nous devons maintenant trouver un moyen pour que l’ensemble du clan s’accorde sur une seule valeur. Comme différents nodes écoutent différents ensembles de sources de données, les valeurs calculées par différentes nodes peuvent être différentes. C’est là qu’intervient un agrégateur. Nous désignons un ensemble de nodes de la tribu comme agrégateurs.

Les nodes du clan signent numériquement leurs valeurs et les envoient aux agrégateurs. En fait, nous n’avons besoin que d’un seul agrégateur pour combiner toutes les valeurs des nodes du clan en une seule valeur. Comme nous ne savons pas quels nodes sont byzantins, nous sélectionnons de manière aléatoire une famille d’agrégateurs de la tribu de telle sorte que nous soyons garantis, avec une probabilité extrêmement élevée, qu’il y ait au moins un agrégateur honnête au sein de la famille.

Alors, que fait un agrégateur ? Il est censé combiner les valeurs de tous les nodes en une seule valeur représentative pour le prix d’une marchandise donnée. Notez qu’environ la moitié des nodes du clan pourraient être byzantins et ils pourraient ne jamais envoyer leurs valeurs à l’agrégateur. Ainsi, nous savons qu’un agrégateur honnête peut s’attendre à recevoir au moins fc + 1 valeurs, où fc est le nombre maximum de nodes byzantins dans un clan de taille 2fc +1.

Supposons qu’il attende que les premières valeurs fc + 1 arrivent. Peut-il proposer la moyenne arithmétique de cette valeur comme valeur S ? Le problème est que l’agrégateur ne peut pas être sûr que toutes ces valeurs fc + 1 de nodes honnêtes. Une node byzantine, souhaitant manipuler la valeur S, peut envoyer une valeur arbitrairement grande. Comme les retards de communication réseau sont imprévisibles, cette valeur peut arriver plus tôt, donc être incluse dans l’ensemble des valeurs fc + 1. La moyenne arithmétique peut maintenant devenir arbitrairement grande en raison de l’inclusion de cette seule valeur malhonnête.

Le médian fonctionne-t-il à la place ? Apparemment, non. Dans un clan de taille 2fc + 1 jusqu’à fc nodes pourraient devenir byzantins. Par conséquent, il est possible que si l’agrégateur attende la première valeur fc + 1 pour calculer la valeur S, alors autant que (fc +1)/2 valeurs malhonnêtes peuvent se frayer un chemin dans cet ensemble de valeurs fc + 1.

Tout espoir est-il perdu maintenant ? Heureusement, non ; il y a une lueur au bout du tunnel. Même dans le pire des cas, lorsque jusqu’à fc des valeurs fc + 1 pourraient être byzantines, nous avons la garantie d’au moins une valeur honnête. La magie réside dans l’exploitation de ce fait. Le problème de calcul de la moyenne ou du médian des premières valeurs reçues de fc + 1 est que les valeurs malhonnêtes peuvent être arbitrairement grandes ou arbitrairement petites par rapport aux valeurs honnêtes. Nous pouvons résoudre ce problème en exigeant que même dans le pire des cas d’une seule valeur honnête, cette valeur serve d’ancrage aux autres valeurs afin que les autres valeurs, même si malhonnêtes, ne puissent pas dévier arbitrairement de la valeur honnête.

C’est là qu’intervient la distance d’accord D.

Distance d’Accord

Étant donnée une distance d’accord D, nous disons que deux valeurs v1 et v2 sont en accord l’une avec l’autre, si v1 — v2 ≤ D . Autrement dit, si deux valeurs diffèrent au plus de la distance d’accord, alors elles sont dites être en accord l’une avec l’autre.

Une série de valeurs CC est dite former un cluster cohérent si ∀ v1, v2 ∈ CC : v1 — v2 ≤ D. En d’autres termes, un cluster cohérent est un ensemble de valeurs où toutes les valeurs de cet ensemble sont en accord entre elles.

Armé de la distance d’accord D, nous pouvons ancrer toutes les valeurs fc + 1 de telle sorte qu’elles sont garanties de ne pas être trop éloignées les unes des autres. Au lieu de demander à l’agrégateur d’attendre les premières valeurs fc + 1 qu’il reçoit, nous exigeons que l’agrégateur attende jusqu’à ce qu’il voie un cluster cohérent de valeurs de taille fc + 1.

Cette variation de DORA est appelée DORA-CC (Accord Oracle Distribué avec Cluster Cohérent) et est définie formellement comme suit :

Un protocole DORA-CC parmi n nodes p1, p2, … , pn, chaque node ayant des entrées vi, pour une distance d’accord donnée D , garantit que :

[Termination] : Tous les nodes honnêtes finissent par s’accorder sur une valeur.

[Accord] : La valeur de sortie S pour tous les nodes est la même.

[Validité] : Hmin — D ≤ S ≤ Hmax /mathcalD, où Hmin et Hmax représentent les valeurs minimale et maximale des nodes honnêtes.

Attendez une minute ! Quelle garantie avons-nous que nous serons toujours en mesure de former un cluster cohérent de taille fc + 1? Eh bien, il n’y a aucune garantie. Cependant, nous observons que dans des circonstances normales, les prix d’une marchandise donnée provenant de différentes sources de données sont très proches. Ainsi, si nous fixons notre distance d’accord D suffisamment grande pour que les valeurs des sources de données honnêtes soient en accord entre elles dans des circonstances normales, un cluster cohérent de valeurs fc + 1 peut être formé. En ce qui concerne les circonstances anormales, nous y reviendrons plus tard.

Vote et Publication des Valeurs

Une fois qu’un cluster cohérent est formé, les parties restantes sont faciles. Puisque nous savons que toute déviation est bornée par la distance d’accord, il est sûr de calculer la moyenne arithmétique du cluster. En fait, la moyenne garantit même que s’il y a une seule valeur honnête dans le cluster, elle est quand même prise en compte.

L’agrégateur envoie la moyenne, ainsi que les valeurs signées par les nodes, à tous les nodes du clan pour leur validation et leur approbation. Il est important pour l’agrégateur d’envoyer le cluster de valeurs et la moyenne à tous les nodes du clan et pas seulement aux fc + 1 nodes qui ont contribué à la formation du cluster. Sinon, s’il y a une node byzantine, qui a contribué au cluster, elle peut retenir son vote, arrêtant ainsi le protocole d’avancer.

Chaque node peut maintenant valider que les valeurs ont été contribuées par les nodes du clan en raison des signatures numériques. Elles peuvent également valider que l’ensemble des valeurs forme effectivement un cluster cohérent dans la distance d’accord, et que la moyenne envoyée par l’agrégateur est effectivement la moyenne du cluster. Comme le clan a au moins 2fc + 1 nodes, nous sommes assurés que nous recevrons au moins fc + 1 votes d’approbation, permettant ainsi à l’agrégateur de former un certificat de quorum. Une fois le certificat de quorum formé, la moyenne est publiée en tant que valeur S pour le tour d’accord donné sur le SMR. Tous les nodes honnêtes voient alors la valeur S être publiée pour le tour et concluent le tour.

Pouvons-nous rentrer à la maison maintenant ? Pas encore. Rappelez-vous que tout cela fonctionne uniquement si nous avons des circonstances normales, où les valeurs de la plupart des sources de données sont proches les unes des autres. Lorsque les choses sont chaotiques, il est possible que les valeurs même des nodes honnêtes ne soient pas assez proches pour former un cluster cohérent.

Que faisons-nous alors ? Eh bien, quand vous pensez que vous ne pouvez pas gagner une bataille, vous reculez.

Le Protocole de Repli

Déclenchement d’un Repli

Alors, quels nodes décident quand se replier ? Eh bien, tous. Tous les nodes du clan lancent leur minuterie de repli dès qu’ils envoient leurs valeurs aux agrégateurs. Lorsque la situation est chaotique, il peut être impossible pour un agrégateur de former un cluster cohérent de taille fc + 1.

Éventuellement, la minuterie de repli arrive à expiration. Lorsque la minuterie d’une node arrive à expiration, il envoie un vote de repli à tous les agrégateurs. Finalement, nous aurions un agrégateur avec au moins fc + 1 votes de repli lui permettant de former un certificat de quorum pour le repli, et il le publierait sur le SMR. Toute node observant le message de repli pour le tour sur le SMR bascule alors vers le protocole de repli.

Le Protocole de Repli

Nous savons que les choses sont un peu instables et c’est pourquoi nous avons décidé de nous replier. Alors que faisons-nous ? Nous sortons les gros moyens! À ce stade, nous faisons participer toute la tribu au calcul de la valeur S.

Le protocole de repli est très similaire au protocole précédent. Les nodes de la tribu rassemblent des données à partir des sources de données, calculent la médiane à partir de l’ensemble des prix qu’ils ont reçus, signent numériquement et envoient tout cela aux agrégateurs.

C’est là que les choses diffèrent un peu. Nous savons que nous sommes déjà dans une situation où nous ne pourrons pas former de cluster cohérent. L’agrégateur attend donc maintenant que les premiers 2ft + 1 nodes de la tribu envoient leurs valeurs. Ici, nous supposons que la taille de la tribu est de 3ft + 1 avec au plus ft nodes qui peuvent devenir byzantins. Sur 2ft + 1 valeurs, au moins ft + 1 de ces valeurs doivent provenir de nodes honnêtes. Par conséquent, nous utilisons maintenant la médiane de ces valeurs, car nous savons que la médiane serait bornée par des valeurs honnêtes.

La suite suit la trajectoire familière. L’agrégateur propose cette médiane comme valeur S pour ce tour, avec l’ensemble des 2ft + 1 valeurs signées numériquement qu’il a reçues. Les nodes de la tribu valident et envoient leurs votes d’approbation à l’agrégateur, l’agrégateur forme un certificat de quorum avec 2ft + 1 votes, puis le publie sur le SMR.

Pourquoi avons-nous plusieurs agrégateurs?

Considérons un modèle où nous avons un seul agrégateur. Imaginons un scénario où cet agrégateur s’avère être byzantin. Cet agrégateur ne peut pas publier de fausse valeur S en raison de l’exigence selon laquelle une majorité des nodes du clan doivent valider et voter pour la valeur S calculée par l’agrégateur. Cependant, l’agrégateur peut causer des problèmes de vivacité, soit en ne proposant pas de valeur S , soit en ne soumettant pas la valeur S convenue au SMR. Le modèle à plusieurs agrégateurs résout ce problème en garantissant qu’il y a au moins un agrégateur honnête dans l’ensemble des agrégateurs.

Ce choix de conception nous permet d’éviter tout protocole de changement d’agrégateur qui pourrait être nécessaire pour un modèle à un seul agrégateur, au cas où l’agrégateur s’avérerait être byzantin.

Mais maintenant, nous avons plusieurs agrégateurs qui peuvent publier des valeurs S sur le SMR. Laquelle sera prise en compte ? C’est facile, la première ! Et si la valeur est publiée par un agrégateur byzantin ? Peu importe. Les agrégateurs ne peuvent pas falsifier la signature d’une quelconque node honnête. Ainsi, la valeur S publiée serait soit (i) à au plus une distance d’accord d’une valeur honnête, soit (ii) entre deux valeurs honnêtes.

Remarquez qu’une plus grande distance d’accord peut permettre une plus grande déviation par rapport à une valeur honnête. En pratique, la distance d’accord peut être assez petite. Elle peut être maintenue inférieure ou égale à la déviation observée entre les sources de données honnêtes pour garantir que nous pouvons former un cluster cohérent dans des circonstances normales.

DORA à Démarrage Par Ticks

Avez-vous remarqué qu’un tour d’accord ne dépend pas des tours précédents ? Nous pouvons tirer parti de ce fait à notre avantage.

Nous pouvons démarrer un nouveau tour de DORA à un tick prédéterminé. L’intervalle de temps entre deux ticks peut être défini en fonction de la fréquence à laquelle nous souhaitons publier les valeurs S, ou de la fréquence à laquelle nous voulons observer les conditions du marché, etc. En pratique, il est possible de démarrer un nouveau tour toutes les quelques secondes, car un nouveau tour peut être démarré sans attendre que les tours précédents se terminent.

Les retards de réseau, comme la météo, sont imprévisibles. En raison de la nature asynchrone de la communication entre les nodes du clan, il est possible que les valeurs des tours soient publiées dans le désordre. Par exemple, la valeur du tour 4 peut apparaître sur le SMR avant la valeur du tour 3. En pratique, le tour 4 porterait une valeur fraîche et donc l’information qui découle du tour 3 après que la valeur du tour 4 soit disponible peut ne servir à rien. Sur la base de cette hypothèse, nous pouvons économiser sur certains calculs et communications inutiles.

Si, pour une raison quelconque, les anciens tours prennent plus de temps à se conclure, on peut les terminer si la valeur S du tour suivant devient disponible sur le SMR. De cette façon, les nodes n’ont pas à gaspiller leurs ressources et leur bande passante en essayant de conclure des tours plus anciens qui peuvent ne pas offrir de valeur.

Détection d’Anomalies

Disjoncteurs

De nombreuses bourses, ainsi que des bourses de cryptomonnaies, utilisent des mécanismes pour geler les transactions lorsque les prix fluctuent de manière folle.

L’un des mécanismes populaires est un disjoncteur. Le fonctionnement sous-jacent est très simple.

Soit Sr la valeur S du tour r. Une fonction de disjoncteur (Sr — (Sr — 1))/ Sr − 1 ≥ thr déclenche et coupe le circuit (ou arrête la transaction) lorsque Sr s’écarte de Sr − 1 de plus de seuil de pourcentage défini par thr.

Vérification de Cohérence Historique

Un inconvénient est que la fonction de disjoncteur mentionnée précédemment ne regarde que la valeur S précédente pour déterminer si l’écart est un peu incontrôlable.

Peut-être devrions-nous regarder plus loin dans le passé pour déterminer si les tendances actuelles sont plus folles que par le passé.

Si l’on examine toutes les valeurs S dans une fenêtre d’historique donnée Wh , on peut établir une formule généralisée comme mentionné dans l’image ci-dessus. Tout comme thr est un paramètre pour le disjoncteur, Ch est un paramètre constant qui contrôle le degré de déviation autorisé.

Un avantage de la fonction de vérification de cohérence historique mentionnée ci-dessus est qu’elle intègre l’écart type de l’historique σh . Imaginez que, pour une raison quelconque, la valeur S continue de grimper très rapidement. Alors que pour les tours initiaux, on peut penser que c’est anormal, si une telle montée persiste, σh augmente automatiquement pour classer cela comme normal. De même, lorsque la valeur S présente des fluctuations plus modérées, σh rétrécit automatiquement l’intervalle. De telles fonctions génériques et flexibles peuvent être utilisées dans une grande variété de marchandises sans nécessiter d’ajustement fin des paramètres.

Par exemple, les cryptomonnaies populaires ont tendance à rester relativement stables, tandis que les cryptomonnaies moins populaires ont tendance à fluctuer fortement. Cela signifie que, dans le cas de l’utilisation de la fonction de disjoncteur mentionnée ci-dessus, le paramètre de seuil peut nécessiter un ajustement fin pour différentes devises, sinon, on risque de bloquer la transaction même si elle peut être une situation normale.

Nous ne devons pas nous limiter à seulement ces deux fonctions. Une fois le flux de valeurs S disponible sur le SMR, il existe une grande variété de techniques de détection d’anomalies que l’on peut utiliser, telles que l’utilisation d’un test du chi-deux ou d’autres tests statistiques pour détecter une anomalie statistique. Si nous devons utiliser ces fonctions lors du traitement hors chaîne, nous avons de nombreuses options pour la détection des anomalies. Cependant, si une telle détection doit se faire sur chaîne via un contrat intelligent, alors nous devons tenir compte du coût de calcul et de stockage nécessaire pour effectuer tout test de détection d’anomalie.

Relations Croisées

De nombreuses matières premières sur le marché sont corrélées, et donc toute variation dans une matière première peut affecter le prix des matières premières corrélées. Par exemple, soit x let BTC/USD, y l’ETH/USD et z le BTC/ETH. Il est facile de voir qu’idéalement, nous aurions x — y = 0.

Bien sûr, en pratique, nous aurions x — yz ≤ Dr, pour une distance de correlation Dr.

Ensuite, si nous détectons x — yz > Dr, nous savons que quelque chose ne va pas. Une telle analyse multi-variée est une arme puissante à avoir dans notre arsenal pour l’analyse forensique. Si nous assignons toutes les trois matières premières à des clans différents, un adversaire doit être assez puissant pour contrôler trois clans pour éviter toute détection.

À l’avenir, notre plan est de tirer parti de telles corrélations croisées qui existent entre différentes matières premières pour une détection d’anomalies en temps réel.

Randomisation

Si la configuration du réseau oracle reste inchangée pendant une période prolongée, cela peut permettre aux nodes de collusionner et de fomenter un complot pour attaquer notre service oracle.

Cependant, notre conception rend cela aussi difficile que raisonnablement possible. En tant que technique d’atténuation, chez Supra, nous proposons diverses techniques de randomisation pour maintenir l’adversaire dans l’ignorance.

Rotation des tribus des clans Nous avons déjà discuté que l’attribution des sources de données aux nodes des clans se fait via un VRF. Nous proposons également de randomiser la correspondance des marchandises aux clans via un VRF. Chaque clan est chargé de suivre les prix d’un ensemble de marchandises qui sont choisies de manière uniformément aléatoire parmi l’ensemble complet des marchandises.

À la fin d’une période prédéterminée que nous appelons un cycle, cette correspondance des marchandises au clan est redessinée. Cela réduit la chance et la période de temps disponible pour un adversaire pour cibler une marchandise de son choix pour une manipulation frauduleuse.

Mélange des tribus des clans Alors que la rotation change périodiquement la responsabilité d’un clan, les nodes composant le clan ne changent pas. Permettre à une configuration de clan de rester statique pendant une longue période peut être favorable à un adversaire. Par conséquent, nous proposons de réorganiser complètement toute la tribu et de redessiner les clans de la tribu à la fin d’une période prédéterminée, que nous appelons une époque. Effectuer un mélange des nodes atténue les capacités d’un adversaire à contrôler un clan à sa guise.

Sécurité et viabilité probabilistes

À chaque mélange, les clans sont tirés au hasard de la tribu en utilisant une distribution uniforme. Étant donné que la tribu peut comporter jusqu’à 1/3 de nodes byzantins, la probabilité qu’au moins un clan ait 1/2 de nodes byzantins ou plus est non nulle. Nous devons fixer la taille de la tribu et le nombre de clans dans la tribu de telle manière que la probabilité qu’un clan ait une majorité byzantine soit négligeable.

Par exemple, si nous avons 625 nodes dans la tribu et 5 clans dans la tribu, chacun ayant 125 nodes, la probabilité qu’un des clans ait une majorité byzantine est inférieure à 35 sur un million. Si la durée d’une époque est de 2 jours, la fréquence de défaillance serait d’environ une fois tous les 156 ans.

À mesure que la taille de la tribu augmente, la probabilité de défaillance diminue pour un nombre fixe de clans.

À chaque époque, l’ensemble des agrégateurs est également tiré au hasard de manière uniforme parmi la tribu. Avoir un ensemble suffisamment grand d’agrégateurs garantit qu’il y a une très forte probabilité d’avoir au moins un agrégateur honnête.

Par exemple, si nous choisissons 12 agrégateurs parmi la tribu de 502 nodes, la probabilité de ne pas avoir un seul agrégateur honnête serait inférieure à 1,5 sur un million. Même si une époque dure un jour, la fréquence de défaillance serait inférieure à une fois tous les 1 800 ans !

À mesure que le nombre d’agrégateurs augmente, la probabilité de défaillance diminue de manière exponentielle.

Notez que les tailles de la tribu, des clans et de la famille d’agrégateurs sont paramétriques à notre conception. Les chiffres réels mentionnés ci-dessus ne sont donnés qu’à des fins d’example.

Points forts de notre conception d’oracle

• Notre conception tient compte du fait que certaines sources de données peuvent développer des défaillances byzantines.
• Notre idée novatrice d’utiliser une distance d’accord et de tirer parti du SMR permet au protocole DORA d’être résilient à un pourcentage plus élevé de défaillances byzantines (51 %) par rapport à la limite de tolérance aux défaillances conventionnelle de 33%.
• Étant donné que le protocole DORA nécessite un pourcentage moindre de nodes honnêtes pour fonctionner, cela nous permet de bien nous adapter en utilisant un éclatement de marchandises.
• Le modèle multi-agrégateur évite les retards qu’un modèle à agrégateur unique peut avoir à subir en raison d’un agrégateur byzantin.
• La randomisation de notre conception limite les pouvoirs d’un adversaire.
• Nous proposons divers services de détection d’anomalies, y compris la corrélation croisée, pour des capacités améliorées de détection d’anomalies et de fraude.

Si vous souhaitez démystifier les mystères techniques de notre conception d’oracle via un document formel, des théorèmes et des preuves, veuillez consulter le whitepaper complet de DORA.