Apprendre | Proof-of-Draw

Sommaire de la page

Autres parcoursParticiper sans ESP Vue d’ensemble Rôles du réseau Consensus Solidité technique Licences Consommation électrique Synthèse technique Niveaux d’assurance Feuille de route Matrice de compatibilité Rechercher un autre sujet

InstallationChoisir l’écran Câbler Préparer Arduino Firmware et Wi-Fi Téléverser Associer l’écran Compatibilité matérielle Dépannage Wi-Fi et mises à jour

Parcours 03

Comprendre le réseau

Cette partie rassemble la vue technique du protocole. Elle est indépendante du tutoriel de branchement et peut être lue comme un white paper synthétique.

Comment une œuvre traverse le réseau

Proof-of-Draw utilise une architecture pull-based : les ESP interrogent toujours le serveur, jamais l’inverse. Ils restent ainsi utilisables derrière n’importe quel routeur ou NAT sans exposer d’adresse locale.

Artiste

Dessine dans le navigateur
Soumet le dessin au réseau

POST /api/draw

Serveur

Encode le dessin pour l’écran
Calcule sa complexité
Publie le candidat

candidate:current → Redis

ESP validateurs

Détectent le candidat
Calculent les métriques
Soumettent leurs votes

GET /api/pull · POST /api/validation-result

Finalisation

Vérifie le quorum
Grave le bloc SHA-256
Sélectionne le mineur

chain:block:{hash}

Écrans

Détectent la nouvelle frame
Téléchargent le payload
Affichent l’œuvre

GET /api/pull-frame

Séparation entre le pull léger et le téléchargement binaire

Pour préserver la mémoire disponible sur l’ESP8266, GET /api/pull ne renvoie que des métadonnées. Le payload de l’image est récupéré uniquement lorsqu’un nouveau frameId est détecté.

GET /api/pull

Métadonnées légères indiquant l’action à effectuer.

{
  "frameSource": "consensus",
  "frameId": "abc…",
  "pendingValidation": { "candidateId": "xyz…" }
}

GET /api/pull-frame?fmt=bin

Payload binaire téléchargé seulement lorsqu’une nouvelle frame est disponible.

Content-Type: application/octet-stream
Payload adapté au profil de l’écran

Les rôles du réseau

Chaque participant peut jouer un ou plusieurs rôles simultanément. Un même ESP peut être validateur, mineur et afficheur.

Artiste

Créateur du dessin

Dessine dans le navigateur et soumet son œuvre avec son propre ESP ou un écran public partagé.

POST /api/draw
Session signée HMAC-SHA256
Détection des séquences automatisées

Validateur

Nœud de consensus

L’ESP interroge le serveur, relit le contenu du candidat, recalcule son hash et des métriques entières, puis signe son vote (images fixes ; les animations sont encore votées en v1).

GET /api/pull
GET /api/validate-candidate
POST /api/validation-result

Mineur

Finalisation d’un bloc

Un validateur est tiré au sort par le serveur à chaque quorum et son compteur de blocs minés est mis à jour.

Tirage pondéré inverse
chain:notify:{deviceId}
Tirage non encore rejouable par un tiers

Serveur

Orchestrateur

L’application Next.js et Redis coordonnent les soumissions, la chaîne et la distribution des frames.

Next.js API Routes
Upstash Redis
chain:recent · candidate:current

Protocole de consensus

Soumission

POST /api/draw encode le canvas en 1 bit par pixel pour les e-ink et OLED, ou en RGB565 little-endian pour le TFT. Le serveur vérifie la session, applique les limites et publie le candidat.

Vote des ESP

Les validateurs détectent le candidat, téléchargent son contenu brut, recalculent le SHA-256 et les métriques entières (entropie, transitions, runs), signent leur verdict puis l’envoient à POST /api/validation-result. Le serveur refuse tout « accepte » dont le hash ou une métrique diffère.

Quorum et bloc

Le quorum correspond à ⌈ poolSize × 0,51 ⌉ approbations (appareils appairés actifs), avec un minimum d’un vote. Le serveur finalise le bloc, relie son hash au bloc précédent et conserve l’image et ses métadonnées.

Sélection du mineur

Le mineur n’est pas le plus rapide. Il est tiré au sort parmi les validateurs avec le poids WEIGHT_BASE / (blocksMinés + 1), ce qui favorise les nouveaux participants.

Solidité technique

Aucune IP locale exposée

Les ESP ne sont jamais contactés directement. Ils interrogent le serveur et fonctionnent derrière un routeur ou un NAT.

GET /api/pull · frame:{deviceId}

Chaîne vérifiable

Chaque bloc contient le hash SHA-256 du précédent et les blocs sont conservés sans expiration.

chain:block:{hash} · parentHash

Résistance aux automatismes

Le serveur détecte les séquences d’actions trop rapides ; cette vérification du geste reste, pour l’instant, une vérification du serveur.

automationRatio · MAX_AUTOMATION_RATIO

Minage équitable

Le mineur est tiré au sort avec un poids inversement proportionnel aux blocs déjà minés.

WEIGHT_BASE / (blocs + 1)

Authentification sans mot de passe

La session du navigateur est signée et prouve la possession du device sans compte ni seed phrase.

HMAC-SHA256 · cookie httpOnly

Seuils adaptatifs

Les critères de qualité s’adaptent à l’historique du réseau pour chaque type d’écran.

getEffectiveThresholds()

Licences et droits

Code source

Licence MIT

Le code du serveur, les firmwares et les bibliothèques peuvent être utilisés, modifiés, redistribués et forkés, y compris commercialement, sous réserve de conserver la notice de licence.

Œuvres

Licence CC0

Un dessin soumis est placé dans le domaine public universel. Il est librement partageable, réutilisable et modifiable sans condition.

CC0 ne signifie pas anonymat : le nom d’artiste, le hash du dessin et la date restent associés à l’œuvre dans la chaîne. La liberté de réutilisation et la traçabilité de l’origine coexistent.