---
type: explanation
title: Proof of work
summary: Por qué Caputchin hace que el navegador haga un poco de cómputo antes de emitir un token, y cómo eso eleva el coste del abuso.
---

Cada verificación le pide al navegador del visitante que resuelva un pequeño puzzle computacional antes de que Caputchin emita un token. Ese puzzle es el proof of work.

## Cómo funciona

Caputchin le entrega al navegador un reto y le pide que encuentre un número (un nonce) que, al hacerse hash junto con el reto, produzca un hash que empiece con una cantidad requerida de ceros a la izquierda. No hay atajo: el navegador tiene que probar nonce tras nonce hasta que uno funcione por casualidad. Encontrar un nonce válido lleva muchos intentos; comprobar uno es un solo hash. Así que el trabajo es difícil de hacer pero barato de verificar, y Caputchin confirma que la respuesta supera la dificultad requerida.

## Content-Security-Policy

El solver corre en un Web Worker, que el widget crea desde una URL `blob:`, así que la Content-Security-Policy de la página que incrusta debe permitir `blob:` para los workers (`worker-src blob:`, o `child-src` / `default-src` como la cadena de fallback). Esta parte es obligatoria: no hay fallback en el hilo principal, así que una política que bloquea el worker bloquea la verificación. Por separado, el solver compila una rutina de WebAssembly por velocidad, que necesita `'wasm-unsafe-eval'` en `script-src`. Esa parte es opcional: sin ella el mismo solver corre más lento en JavaScript puro dentro del Worker. Mira [sandboxing de juego](/docs/understanding-caputchin/game-sandboxing#the-csp-you-set-on-your-own-page) para la política completa de la página anfitriona.

## Por qué disuade el abuso

El punto no es hacer imposible cualquier resolución individual. Es hacer el abuso a escala antieconómico.

Un visitante real resuelve un puzzle en una fracción de segundo y nunca lo nota. Un bot que quiere disparar miles de peticiones paga ese coste de cómputo miles de veces. Si superar el reto cuesta más de lo que vale el spam, el ataque deja de tener sentido financiero. El proof of work cambia el objetivo de "irrompible" a "no vale la pena".

## Las perillas

Dos ajustes en la página de [Seguridad](/docs/site-keys/security) de una clave afinan el coste:

- **Difficulty** fija cuántos ceros a la izquierda debe tener el hash, lo que eleva el coste de cada resolución.
- **Challenges per request** multiplica ese coste pidiendo varias resoluciones a la vez.

## Un límite honesto

Ningún reto es irrompible; con suficiente dinero, cualquier cosa se puede resolver. El proof of work acepta eso y compite en coste en su lugar. También solo prueba que se gastó *esfuerzo*, no que un navegador real lo gastó, que es por qué Caputchin lo empareja con [instrumentación](/docs/understanding-caputchin/instrumentation) para comprobar el entorno también.