Proof-of-Draw est un réseau ouvert où des artistes dessinent dans un navigateur ; de petits ordinateurs (ESP8266, Arduino UNO R4 WiFi) relisent l’œuvre, recalculent son empreinte et des mesures de complexité, et signent leur vote ; l’œuvre rejoint alors une chaîne de blocs et s’affiche sur des écrans physiques (e-ink, OLED, TFT).

Les appareils n’ouvrent jamais de port : ils appellent le serveur (architecture « pull »). Ils fonctionnent donc derrière n’importe quel routeur, sans exposer d’adresse locale.

Chaque carte lit le contenu brut du candidat en flux, par petits morceaux, et met à jour ses compteurs au fur et à mesure. Elle n’a pas besoin d’un second buffer complet de l’image ; seuls l’OLED (1 Ko) et l’e-ink 2,9″ (4,7 Ko) utilisent un petit espace de travail borné, employé pendant la lecture. La durée totale, réseau compris, est relevée au port série. Chaque carte produit :

hash = SHA-256( octets bruts du contenu )
e = entropie binaire du taux de pixels allumés        (table fixe, en ppm)
t = proportion de voisins horizontaux/verticaux différents (ppm)
r = racine de (nombre de plages continues / nombre de pixels) (ppm)
score s = (4·e + 4·t + 2·r) / 10                       (ppm, plafonné à 1 000 000)

message signé = pod-vote-v2 | appareil | candidat | hash | version | e | t | r | verdict

Le calcul est entièrement entier (aucun nombre à virgule) pour que le serveur, l’ESP8266 et la R4 obtiennent exactement le même résultat. Cette parité est vérifiée par un test automatisé qui compile le code des cartes et le compare à la version TypeScript. Le verdict est « refuse » si le hash diffère, si l’image est uniforme (toute blanche ou toute pleine) ou si elle ressemble à du bruit pur ; sinon « accepte ». Aucun critère esthétique n’est jamais appliqué.

Un bloc contient :

• l’imageHash, l’actionsHash et le score de dessin ;
• le parentHash (hash du bloc précédent), d’où la chaîne ;
• les identifiants des validateurs, le score, la date, l’artiste et le titre ;
• son propre blockHash = SHA-256 de l’ensemble canonique.

Modifier un ancien bloc change tous les hash suivants : l’intégrité de l’historique est réelle. En revanche, les votes signés complets ne sont pas conservés dans le bloc (seul un résumé l’est) : un tiers ne peut pas, aujourd’hui, revérifier seul qu’un quorum a bien approuvé ces octets. Le code qui conserve ces reçus signés dans le bloc et le vérificateur public existent, mais sont éteints par défaut et pas encore essayés sur le réseau réel : tant qu’ils ne sont pas activés, la phrase ci-dessus reste vraie.

Principe : les appareils attestent N1 et N2 (objectif, calculable, reproductible) ; N3 reste confié au serveur puis à des auditeurs plus puissants (navigateur, Raspberry Pi). Le réseau ne juge jamais le goût.

• Clés : chaque carte génère une paire Ed25519 au premier démarrage et la garde en mémoire permanente.
• Votes v2 : la signature est obligatoire et couvre l’appareil, le candidat, le contenu, les métriques et le verdict.
• Vote atomique : un script Redis enregistre chaque vote d’un seul tenant ; un double vote est ignoré.
• Session du navigateur : cookie signé qui prouve la possession d’un écran, sans compte ni mot de passe.
• Mémoire des cartes : l’ESP8266 n’a qu’environ 80 Ko ; le chiffrement de la connexion en réclame une grande part, d’où le calcul en flux.

Une animation suit le même parcours qu’un dessin : atelier plein écran (3 modes, 7 brosses, fantôme avant/après), clip compact « PBC1 » de 128×64 en 1 bit (9 Ko au plus, images codées en différences), candidat, votes, bloc de type animation, puis diffusion automatique aux écrans dynamiques (TFT 2,8″, TFT 1,8″, OLED) dont le firmware sait la jouer ; jamais aux e-ink.

Cartels e-ink : le firmware grave l’heure, l’artiste et le titre dans les bandes haute et basse après avoir reçu l’image. Sur l’e-ink 2,9″, cela masque environ 22 % de la hauteur ; une zone sûre puis un réglage par appareil sont prévus.

• Quotas Redis : toute nouveauté est chiffrée en commandes par heure avant d’être codée ; lectures groupées, cadence adaptative (5 minutes en activité, 15 au repos), contenu des candidats servi par un CDN.
• Mémoire ESP8266 : les tampons d’image destinés à l’affichage sont alloués après la fermeture de la connexion chiffrée ; pour la validation, un espace de travail borné (1 à 4,7 Ko selon l’écran) sert pendant la lecture en flux ; messages en mémoire flash ; relevé du tas au démarrage.
• Mémoire UNO R4 : tampons statiques seulement, pile principale d’un kilo-octet.
• Secrets : les identifiants Wi-Fi vivent dans un fichier local ignoré par git, jamais dans les sketches publiés.

• Une blockchain décentralisée : un registre unique, un serveur qui choisit candidat, quorum et mineur.
• Un consensus résistant aux identités multiples : le vote est par appareil, pas par profil.
• Un taux de menteurs mesuré : aucune réputation persistante n’existe ; seul un drapeau « suspect » temporaire.
• Une validation des animations par calcul.
• Une preuve que le dessin est fait à la main vérifiable par un tiers.
• Un système à mise à jour à distance : chaque carte se reflashe encore par câble.

Chacun de ces points est une ligne de la feuille de route, avec son statut.

Candidat

Dessin soumis, en attente de validation. Un seul à la fois.

Bloc

Enregistrement permanent d’une œuvre validée : hash de l’image, des gestes, du bloc précédent, validateurs, score, date.

Quorum

Nombre minimal de votes d’approbation : ⌈ 0,51 × appareils appairés, actifs et déclarés capables de valider ⌉, au moins 1.

ppm

Partie par million : les métriques sont des entiers entre 0 et 1 000 000, pour obtenir exactement le même résultat sur toutes les cartes.

Mineur

Validateur tiré au sort (poids inverse du nombre de blocs déjà minés) qui reçoit la propriété du bloc. Tirage fait par le serveur.

Canari

Essai volontairement limité d’une nouveauté avant de l’étendre.

OTA

Mise à jour d’un firmware à distance, sans câble.