Problema técnico con la prueba del teorema de PCP


12

Estoy leyendo la prueba desde aquí y me topé con un problema técnico (pero crucial). Sé que esto es bastante específico y el contexto es problemático, pero no pude resolverlo yo mismo.

En las páginas 51 y 55, después de presentar los verificadores "estándar", se vuelven a modificar los verificadores para verificar las asignaciones divididas.

En el primer caso (p. 51) verifican que están del código polinomial, y luego usan la Algebraización (+ Zero-Testers) para construir una familia de polinomios (con una Suma- Compruebe la propiedad relacionada con la fórmula de entrada) de que cada uno puede evaluarse en un punto dado 3 valores de cada uno de (las palabras de código del armario de código polinómico a ).f1,,fk0.01f~1,,f~kf1,,fk

En el segundo caso (p. 55) comprueban que son -cerca de ser lineal, y entonces definir una función que ser una suma especial de modo que pueda evaluarse en un punto dado valores de cada uno de (las funciones lineales se en ).f1,,fk0.01ff~1,,f~kff~1,,f~kf1,,fk

Luego, en ambos casos, realizan pruebas (Sum-Check o Tensor + Hadamard) sobre los valores de un polinomio aleatorio en la familia / .f~

Mi problema es que el procedimiento para la reconstrucción de los valores requeridos de cada uno de puede proporcionar valores incorrectos con alguna probabilidad constante no despreciable . Además, la probabilidad de que todos los valores se reconstruyan correctamente es muy baja, solo para alguna constante . Y esto es cierto para ambos casos.f~ickc

Esto puede ser malo, ya que algunos de los pasos de los verificadores requieren obtener valores de la función objetivo / a polinomial de la familia whpf

Entonces, necesitamos amplificar la probabilidad de éxito usando repetidamente el "procedimiento algebraico de reconstrucción" algunas veces para cada .O(logk)f~i

Ahora, esto significa que la explosión en la complejidad de la consulta de la subrutina (en relación con la complejidad de la consulta de los verificadores originales) es ligeramente mayor que , es decir, es (en contraste con el "garantizado" - "deseado" explosión en la declaración de los teoremas).kO(klogk)O(k)

¿Es esto un problema o me estoy perdiendo algo (que probablemente sea)


Perdón si eso debería ser obvio, pero ¿dónde está la declaración de los teoremas pidiendo una explosión ? Basado en una lectura superficial, parece ser un entero constante fijo (¿no es así?). O(k)k
Clemente C.

@ClementC. Mire las definiciones numeradas 3.2 y 3.3 combinadas con el lema de recursión de composición después (y lo más crucial es su prueba). Observe que el único lugar donde se usa la capacidad del verificador de forma normal para verificar asignaciones divididas es en la prueba del lema de la composición (de hecho, en cualquier otro lugar es una "gran responsabilidad" tratar, al construir verificadores). Allí, en la prueba, no es una constante en absoluto. k
Don Fanucci

Justo, se usa para . Sin embargo, para el uso en la demostración del teorema de PCP en el Corolario 3.3 y el Teorema 3.5, , entonces (independientemente de si ese adicional debería estar aquí o no) es una constante. p=Q(n)Q(n)=1logk
Clement C.

@ClementC. Gracias, tienes razón en que cuando usamos composición usamos una constante . p
Don Fanucci

Respuestas:


1

La complejidad de la consulta utilizada en este documento es y .O(1)O(poly(logn))

Para Lemma 3.1 hay una nota de que la complejidad de la consulta utilizada es .O(1)

Si la pregunta es cómo Lemma 3.1 se generaliza a la complejidad de consulta no constante, esto presenta un problema fuera de .O(poly(f(n)))

Este problema se evita al componer un verificador que reduce la complejidad de la consulta a (Lema 4.4).O(1)

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.