---
type: explanation
title: Proof of work
summary: Pourquoi Caputchin fait faire au navigateur un peu de calcul avant d'émettre un token, et comment cela élève le coût de l'abus.
---

Chaque vérification demande au navigateur du visiteur de résoudre un petit casse-tête de calcul avant que Caputchin n'émette un token. Ce casse-tête est le proof of work.

## Comment ça marche

Caputchin remet au navigateur un défi et lui demande de trouver un nombre (un nonce) qui, haché avec le défi, produit un hash commençant par un nombre requis de zéros en tête. Il n'y a pas de raccourci : le navigateur doit essayer nonce après nonce jusqu'à ce que l'un fonctionne par hasard. Trouver un nonce valide prend de nombreuses tentatives ; en vérifier un est un seul hash. Donc le travail est dur à faire mais bon marché à vérifier, et Caputchin confirme que la réponse passe la difficulté requise.

## Content-Security-Policy

Le solveur tourne dans un Web Worker, que le widget crée à partir d'une URL `blob:`, donc la Content-Security-Policy de la page d'intégration doit autoriser `blob:` pour les workers (`worker-src blob:`, ou `child-src` / `default-src` comme chaîne de repli). Cette partie est requise : il n'y a pas de repli sur le fil principal, donc une politique qui bloque le worker bloque la vérification. À part, le solveur compile une routine WebAssembly pour la vitesse, qui a besoin de `'wasm-unsafe-eval'` dans `script-src`. Cette partie est optionnelle : sans elle, le même solveur tourne plus lentement en JavaScript pur dans le Worker. Vois [bac à sable des jeux](/docs/understanding-caputchin/game-sandboxing#the-csp-you-set-on-your-own-page) pour la politique complète de la page hôte.

## Pourquoi ça dissuade l'abus

Le but n'est pas de rendre une résolution unique impossible. C'est de rendre l'abus à grande échelle non rentable.

Un vrai visiteur résout un casse-tête en une fraction de seconde et ne le remarque jamais. Un bot qui veut tirer des milliers de requêtes paie ce coût de calcul des milliers de fois. Si réussir l'épreuve coûte plus que ce que vaut le spam, l'attaque cesse d'avoir un sens financier. Le proof of work déplace l'objectif de « incassable » vers « pas la peine ».

## Les molettes

Deux réglages sur la page [Sécurité](/docs/site-keys/security) d'une clé règlent le coût :

- **Difficulté** fixe combien de zéros en tête le hash doit avoir, ce qui élève le coût de chaque résolution.
- **Défis par requête** multiplie ce coût en demandant plusieurs résolutions à la fois.

## Une limite honnête

Aucune épreuve n'est incassable ; avec assez d'argent, tout peut être résolu. Le proof of work l'accepte et rivalise sur le coût à la place. Il ne prouve aussi que de l'*effort* a été dépensé, pas qu'un vrai navigateur l'a dépensé, ce qui est pourquoi Caputchin l'associe à l'[instrumentation](/docs/understanding-caputchin/instrumentation) pour vérifier l'environnement aussi.