Hacen primer pago Contingente con Cero-Conocimiento (ZKCP) en Bitcoin.

***

Imagine un “intercambio de maletas” al estilo de las películas (una de las partes
con una maleta llena de efectivo, y otra que contiene documentos secretos),
pero sin el escenario potencial en que una de las maletas esté llena de
papel periódico picado y con el resultado de la escena de persecución emocionante.

Así es el ZKCP, un protocolo transaccional donde comprador y vendedor de bitcoins no necesitan confiar entre sí (ni en el arbitraje de un tercero) porque  la transferencia se realizará de forma automática cuando el pago es realizado.

Un ejemplo de aplicación sería para que los dueños de un tipo particular de
lector e-book cooperen para comprar las claves maestras DRM de un fabricante
cuyo negocio esté destinado a la quiebra, para que estos pudieran cargar sus propios
documentos en los lectores aún después que los servidores sean apagados.

Este tipo de venta es inherentemente irreversible, cruza múltiples jurisdicciones, y envuelve partes cuya estabilidad financiera no es cierta. Es decir, ambas partes toman un gran riesgo, o deben hacer preparativos difíciles para llevar a cabo la transacción. Utilizar un ZKCP evita los costos transaccionales significativos envueltos en una venta, la cual podría de otro modo fácilmente salir mal.

El 26 de Febrero de 2016 se llevó a cabo la primera transacción ZKCP, en ella se compró una solución a un problema de Sudoku de 16×16 por un total de 0.10 BTC. Quien hizo esta operación fue Sean Bowe, un miembro del equipo Zcash, como parte de una demostración realizada en vivo en Financial Cryptography 2016 en Barbados. Gregory Maxwell hizo la compra de forma remota desde California.

COMO FUNCIONA ZKCP

Si se acepta la existencia del sistema de pruebas con cero conocimientos como una caja negra, el resto del protocolo ZKCP es sencillo.

El comprador primero crea un programa que pueda decidir si la entrada de datos está realmente compuesta por los datos que el comprador desea comprar. Este programa únicamente verifica la información, no la produce, el comprador no debe tener idea alguna de cómo producir estos datos (por ejemplo, es fácil escribir un programa que verifique que la solución a un Sudoku sea correcta, pero es mucho más difícil escribir un programa que resuelva Sudoku, dado que Sudoku es NP-Completo. El comprador solo necesita escribir el verificador de soluciones.)

El comprador realiza la configuración confiable para el sistema de pruebas y envía la información resultante de la configuración al vendedor.

El comprador elige una clave de encriptación al azar y encripta la información que el comprador desea comprar.

Utilizando el sistema ZKCP, el vendedor prueba un una declaración compuesta:

* “Ex” es entrada de datos encriptada la cual satisface el programa de verificación del comprador.
* “Y” es hash sha256 de la clave de desencriptado utilizada para crear “Ex”

El vendedor envía Ex, Y, la prueba, y su clave pública al comprador. Una vez que la computadora del comprador verifica la prueba, el comprador sabe que si logra aprender la entrada al SHA256 que devuelve el hash Y, entonces puede desencriptar su respuesta.

Así que el comprador inicialmente quería comprar una entrada de datos para su programa, pero ahora pudiera estar igual de contento de comprar la pre-imagen de un hash. Resulta que Bitcoin ya provee una forma de vender preimágenes de un hash de una forma segura.

El comprador hace su pago al siguiente ScriptPubKey:

(PRUEBA)* OP_SHA256
(Y) OP_EQUAL
OP_IF
  (Seller PubKey)
OP_ELSE
  (block_height+100) OP_CHECKLOCKTIMEVERIFY OP_DROP
  (Buyer PubKey)
OP_ENDIF
OP_CHECKSIG

El efecto de este pago es que el vendedor puede recolectarlo si provee el hash de la preimagen de Y y una firma con su llave. Para evitar atar los fondos del comprador por siempre, el vendedor no recolecta su pago dentro de -por ejemplo- un día, durante el cual el comprador puede recuperar su pago.

Como resultado, cuando el vendedor recolecta su pago, este es forzado a revelar la información que el comprador necesita para desencriptar la respuesta. Si el vendedor no hace esto, entonces el comprador recibe sus fondos de vuelta.

Este ScriptPubkey es el mismo que sería utilizado para realizar un intercambio entre diferentes blockchains de forma atómica, o en un canal de pago del Lightning Network.

Soporte para este tipo de transacciones en monederos ha sido implementado para Bitcoin Core en el Pull Request #7601.

El programa de verificación del comprador puede ser arbitrariamente largo y complejo sin agregar ningún tipo de carga adicional al blockchain de Bitcoin. El único impacto seria el incremento de tiempo requerido para hacer la configuración y las pruebas, todo esto ocurre fuera de Bitcoin. Nadie fuera del comprador o el vendedor sabe nada sobre el programa del comprador, es decir, nadie puede saber la naturaleza de la información que se vende.

Este enfoque es mucho más escalable y privado que tener que realizar contratos inteligentes dentro de Blockchain, y no está sujeto a problemas de performance o limitaciones de funcionalidad en las capacidades para llevar a cabo contratos inteligentes con Bitcoin.

* En la práctica, el parámetro de prueba es el input de la transacción, al cual el script le saca el SHA256 como primera operación para luego comparar con el valor de Y recibido del vendedor.
Si el resultado es el mismo, quiere decir que la clave de encripción recibida es correcta.

Artículo original de Diario Bitcoin.

Escrito por Angel León.

ADVERTENCIA: Este es un artículo de carácter informativo. DiarioBitcoin es un medio de comunicación, no promociona, respalda ni recomienda ninguna inversión en particular. Vale señalar que las inversiones en criptoactivos no están reguladas en algunos países. Pueden no ser apropiadas para inversores minoristas, pues se podría perder el monto total invertido. Consulte las leyes de su país antes de invertir.