drand : un protocole décentralisé de jetons aléatoires

Posté le Édité le dans , ,
drand est un protocole distribué produisant à intervalles réguliers des valeurs aléatoires, non biaisables et publiquement vérifiables

drand — un service distribué de balises aléatoires

drand (prononcé di-rand) est un service/protocole distribué produisant à intervalles réguliers des valeurs aléatoires imprévisibles, non biaisables et publiquement vérifiables. Il repose sur de la cryptographie à seuil (threshold BLS), une génération de clé distribuée (DKG) et une chaîne de balises (beacons) signées.

Source : drand.love

Objectifs et propriétés de sécurité

drand vise à offrir une source de hasard publique utilisable par des applications, telles que blockchains, les lots, tirages, time-locks, etc, avec les propriétés suivantes :

  • Imprévisibilité : personne (même un sous-ensemble de nœuds) ne peut connaître la sortie d’un futur round avant sa publication.
  • Non-biaisabilité : aucun participant ou coalition admissible ne peut forcer la sortie vers une valeur de son choix.
  • Vérifiabilité publique : tout client peut vérifier cryptographiquement que la valeur a bien été produite par le groupe autorisé.
  • Disponibilité : malgré la suppression d’une partie des nœuds, le réseau continue à produire des balises (tant que le seuil est respecté).

Source : docs.drand.love

Architecture générale

  1. Groupe de nœuds (n) : un ensemble d’opérateurs (souvent appelés operators ou nodes) qui exécutent drand. Ils détiennent collectivement une clé privée partagée.
  2. Distributed Key Generation (DKG) : protocole interactif (ex. Pedersen DKG) qui permet à ces n nœuds de générer une clé publique commune et des partages privés sans qu’une autorité centrale connaisse la clé complète. Voir la doc pour plus d’information.
  3. Rounds / beacon : à chaque intervalle (p. ex. toutes les X secondes), les nœuds exécutent un protocole de signature à seuil pour produire la valeur aléatoire du round r. Le résultat inclut la signature collective (ou l’agrégation partielle) et parfois une référence à la balise précédente (mode chained). (docs.drand.love)
  4. API publique : les balises sont exposées via HTTP/gRPC ; n’importe qui peut récupérer et vérifier une sortie. Voir la section développeur Getting Started — Developers.

Source : docs.drand.love

Mécanique cryptographique

  1. Primitives utilisées

drand utilise des signatures BLS (Boneh–Lynn–Shacham), qui tirent parti de pairings bilinéaires pour permettre l’agrégation facile de signatures partielles en une signature unique vérifiable.

Source : docs.drand.love

  1. Génération de la clé (DKG)

Les n nœuds exécutent un protocole DKG (souvent Pedersen DKG) : chaque nœud crée un polynôme secret et distribue des partages (shares) aux autres. Après vérifications (commitments), on obtient une clé publique commune PK et pour chaque nœud un share privé sk_i. Le secret complet n’existe nulle part. Cela évite qu’un acteur unique puisse signer seul.

Source : docs.drand.love

  1. Production d’un round
  • Pour un round r (horodaté / séquentiel), chaque nœud i calcule une signature partielle σ_i = Sign(sk_i, input_r) où input_r typiquement contient l’identifiant du round et souvent la balise précédente (dans le mode chained).
  • Une fois qu’on a t signatures partielles ou plus (t = seuil), on agrège ces σ_i via la construction BLS pour obtenir la signature de seuil Σ_r.
  • La valeur pseudo-aléatoire du round est dérivée (p.ex. H(Σ_r) ou H(Σ_r || previous_value)), ce qui la rend vérifiable par tous (on vérifie Σ_r avec PK).

Source : docs.drand.love

  1. Modes — chained vs unchained

drand supporte les deux modes suivants :

  • Chained : chaque balise inclut (ou signe) la balise précédente formant ainsi une chaîne où chaque sortie dépend de la précédente. Cela renforce la résistance à certains types d’attaque par recomputation et crée une histoire linéaire.
  • Unchained : les sorties sont indépendantes ; utile si on ne veut pas de dépendance temporelle.

Source : docs.drand.love

Vérification par un client

  1. Récupérer la sortie du round r : contient round, random_value, signature, et public_key (ou référence).
  2. Vérifier la signature Σ_r à l’aide de la clé publique du groupe PK (BLS verify).
  3. Vérifier optionnellement la chaîne des balises et si en mode chained, s’assurer que le round r signe/référence r−1, etc.
    La vérification est publique et non interactive : tout client peut effectuer ces opérations localement.

Source : docs.drand.love

Résilience et modèle de menace

  • Tolérance aux fautes : drand implémente un modèle t-of-n : tolère jusqu’à f = n − t nœuds défaillants (par crash ou arrêt). Tant que t nœuds ou plus coopèrent, une balise est produite. (docs.drand.love)
  • Adversaire adaptatif vs statique : si l’adversaire peut corrompre des nœuds avant la DKG, il risque de compromettre la clé. Les protections incluent audits opérateurs, opérateurs diversifiés (League of Entropy) et rotation/resharing de clés. (Cloudflare)
  • Attaques possibles : DoS sur des nœuds pour retarder le round, corruption des partages, attaques réseau.   Solutions : redondance, opérateurs indépendants, surveillance, seuil choisi pour résister à des collusions probables.

Source : docs.drand.love

Opérations pratiques

  • Déployer un réseau drand : on installe le daemon (Go) sur chaque opérateur, exécute la DKG pour créer la configuration du groupe, puis on lance les rounds avec une fréquence configurée. (GitHub)
  • Consommer la vraie sortie : via REST/gRPC (endpoints publics du mainnet/League of Entropy) : GET /public/latest ou /public/{round} etc. Voir la doc développeur.
  • Cas d’usage courants : élection, blockchains, tirages/loteries vérifiables, génération de secrets temporisés (timelock), jeux, ou toute logique nécessitant un hasard non manipulable.
    Par exemple Filecoin utilise drand pour son entropie non biaisable (spec.filecoin.io).

Limites, bonnes pratiques et points d’attention

  • Sélection du seuil t : compromis entre disponibilité et sécurité (un petit t permet une meilleure disponibilité, mais plus de risque de collusion).
    Choisir t en fonction du modèle de menace et de la diversité opérationnelle. (docs.drand.love)
  • Risque de corruption lors de la DKG : la DKG doit être exécutée soigneusement et idéalement auditable.
    En pratique, on préfère des opérateurs indépendants, audités et géographiquement/administrativement séparés, c’est le principe de la League of Entropy. (Cloudflare)
  • Latence : la production de balises dépend du réseau et du temps d’agrégation des signatures partielles. drand n’est pas conçue pour des exigences de latence extrêmes (inférieures à la milliseconde), mais plutôt pour des rounds réguliers (par ex. chaque minute).

Source  : docs.drand.love

Exemple concret

  1. Setup : 7 opérateurs n = 7, seuil t = 5. Exécution d’une DKG → sortie PK.
  2. Round r : chaque opérateur signe la seed (incluant r et potentiellement prev) → collecte de ≥5 signatures partielles.
  3. Aggregation : création de Σ_r → random = H(Σ_r) → publication sur l’API.
  4. Vérification : client récupère random et Σ_r, vérifie Verify(PK, Σ_r, input_r) → si ok, accepte la valeur.

Source : docs.drand.love

Conclusion

drand est aujourd’hui l’une des solutions les plus abouties pour fournir du hasard publique et distribué : open-source, utilisée en production (ex. League of Entropy), basé sur des primitives bien étudiées (BLS, DKG).
Son adoption pratique dépendra surtout de la diversité des opérateurs, des paramètres du seuil, et de la qualité de l’opération (monitoring, rotation).

Source : drand.love