Visualización de Anuncios con Atestación zk

Los anuncios financian el Prize Pool (fondo de premios). Por lo tanto, el protocolo debe demostrar que los anuncios realmente se vieron, no simplemente que un cliente afirmó haberlos visto.

El modo de fallo ingenuo

Una afirmación del lado del cliente de que "se vio un anuncio" es trivialmente falsificable. Un usuario puede reproducir un evento de "sí, lo vi" una cantidad arbitraria de veces. Sin verificación, el sistema paga el Prize Pool (fondo de premios) sin ingresos reales por publicidad.

AdMob SSV como fuente de verdad

La verificación del lado del servidor (SSV) de Google AdMob es la fuente de verdad: cuando un anuncio se completa, el servidor de AdMob envía un callback firmado a un endpoint configurado, que incluye el ID del anuncio, el ID del usuario, la marca de tiempo y los metadatos de ingresos por impresión. El callback está firmado por AdMob con una clave pública que Google publica.

Cada callback verificado es el registro autoritativo del protocolo de que se vio un anuncio. El crédito de recompensa por esa visualización se emite solo después de que se recibe y verifica el callback.

El problema de privacidad

La liquidación ingenua en cadena de SSV publicaría el historial de visualización de anuncios de cada usuario. Esto es inaceptable porque:

• Expone patrones de interacción con anuncios de usuarios identificables.
• Expone metadatos de monetización (eCPM, anunciante, geografía).
• Correlaciona con la identidad del usuario de formas que violan la privacidad del usuario y pueden infringir los Términos de Servicio de AdMob.

La construcción zk-SNARK

CashPop envuelve cada callback de AdMob SSV en un zk-SNARK que demuestra:

"Poseo un callback válido de AdMob SSV para el usuario i, el anuncio j, en la marca de tiempo t, firmado por la clave pública conocida de AdMob."

sin revelar el contenido de la firma SSV en sí.

Formalmente, el probador construye:

$${\pi }_i=\text{Probar}(\mathrm{\exists }{\text{SSV}}_i:{\text{Verificar}}_{p{k}_{AdMob}}({\text{SSV}}_i,\text{ad\_id},{\text{user}}_i,t)=1)$$

El verificador en cadena acepta π_i como evidencia de una visualización de anuncio. La firma SSV en sí se destruye después de generar la prueba.

Implementación

• Probador: SP1 zkVM (Succinct), que genera pruebas Plonky3 envueltas en Groth16.
• Verificador: un contrato inteligente de TON que implementa verificación Groth16 en BN254.
• Tamaño de prueba: ~200 bytes por visualización de anuncio.
• Costo de verificación: ~0.001 TON por prueba.

A escala, las visualizaciones de anuncios se agregan antes de la liquidación. Un lote de N visualizaciones genera una prueba agregada (composición recursiva), lo que reduce el costo de verificación por visualización a ~$0.00001.

Estado de la Fase 2

El pipeline de zk-SNARK está previsto para la Fase 2 (Q4 2026). Hasta entonces, la liquidación de visualizaciones de anuncios utiliza una multifirma federada: los callbacks de AdMob SSV son recibidos por 3 operadores independientes, cada uno de los cuales confirma de forma independiente antes de acreditar POP (puntos). Esto proporciona tolerancia a fallos bizantinos sobre un conjunto pequeño de operadores, mientras el pipeline zk madura.

Por qué esto es importante

Los mercados de fraude publicitario (fraude de clics, fraude de impresiones, fraude de atribución) le cuestan a la industria publicitaria un estimado de $80 mil millones/año (Juniper Research, 2026). La integridad estructural de CashPop se basa en la imposibilidad de inflar las visualizaciones de anuncios. El pipeline de atestación zk coloca al protocolo en la posición de integridad más sólida conocida: criptográfica, no basada en políticas.