¡Bienvenido! ¿Eres nuevo en Zcash?
The Zcash network is young, but evolving quickly! Sign up and we'll be in touch with monthly highlights on ecosystem growth, network development and how to get started with Zcash!

Idioma

BOLT: Canales de Pago Privados

Ian Miers | Aug 01, 2016

Matthew Green y yo hemos escrito un paper presentando BOLT (acrónimo de Blind Off-chain Lightweight Transactions, o Transacciones Ciegas Ligeras Fuera de la Cadena), que ofrece un protocolo de canal de pago privado y rápido inspirado en la Red Lightning. Creemos que esto hará que Zcash sea más escalable y práctico, manteniendo al mismo tiempo sus fuertes protecciones de privacidad.

TL;DR: Utilizando BOLT, múltiples pagos en el mismo canal no pueden ser enlazados entre sí, incluso por las partes en colusión. Los pagos se producen en milisegundos y no requieren confirmación de bloque. Todo lo que un comerciante llega a saber es que le están pagando en algún canal que ha abierto. Los pagos pueden ser encaminados a través de terceros, evitando la necesidad de que un cliente y un comerciante dispongan directamente de un canal, al tiempo que mantienen la privacidad frente a terceros malintencionados, ya que los participantes permanecen anónimos (incluso si el tercero colude) y el valor transferido permanece oculto. Todo esto requiere que el canal sea fundado con fondos privados, de lo contrario las partes malintencionadas pueden violar su privacidad por medio del cierre forzado del canal. Una versión preliminar del paper se puede encontrar en http://eprint.iacr.org/2016/701.

El Problema

Las criptomonedas basadas en blockchains funcionan registrando cada transacción en público en un blockchain. Esto tiene la clara ventaja de eliminar la necesidad de terceros de confianza. Pero tiene graves problemas de privacidad, escalabilidad y latencia porque usted está registrando cada transacción en público en un blockchain. Necesita el espacio para registrar cada transacción en el blockchain (ver todo el debate en torno al tamaño de bloque de Bitcoin), grabar la transacción en un bloque lleva minutos, y por supuesto la grabación es pública, por lo que la gente puede averiguar muchos detalles sobre lo que esté haciendo .

Canales de pago

Los protocolos de canales de pago, como la Red Lightning, abordan los problemas de escala y latencia al utilizar el blockchain sólo para depositar fondos y resolver disputas. Aparte de eso, los usuarios intercambian lo que esencialmente son pagarés ejecutados por el blockchain, que no son registrados en el blockchain a menos que haya una disputa.

¿Cómo funciona esto? Alice y Bob ambos están de acuerdo con un pagaré inicial que divide los fondos que ponen en el canal (por ejemplo, cada uno pone $50 y el pagaré es "Alice: $50, Bob: $50"). Este dinero se mantiene en fideicomiso en el blockchain y se libera sólo contra un pagaré válido firmado por Alice y Bob. Para que Alice pague a Bob $5, ella destruye verificablemente su viejo pagaré, y ella y Bob firman un nuevo pagaré "Alice: $45, Bob: $55". Pueden hacer esto repetidamente hasta que cualquiera de las partes quiera retirar el dinero. En ese momento, tanto Alice como Bob pueden publicar el último pagaré al blockchain (o ambos pueden publicarlo, en el caso de una disputa). Por lo tanto, sólo la apertura y el cierre del canal se registran en el blockchain.

Los canales no son privados

La apertura y el cierre de un canal dejan un registro que identifica al cliente, al comerciante y el reparto inicial y final de los fondos. Éstas son a menudo exactamente las cosas que deben ser ocultadas.

Supongamos que Tor (u otro servicio de anonimato) recibiera micropagos para pagar por el ancho de banda utilizado. Efectivamente, cada página web que Alice vea a través de Tor requeriría un micropago a través de un canal de pago, digamos de un décimo de centavo por página. Si podemos ver que Alice tiene un canal de pago con Tor por $1,00 que se cierra con un saldo cero cada mes, entonces sabremos que ella es un usuario muy asiduo de Tor. Si Alice es una activista o una periodista, esto puede hacer que llame la atención de las autoridades como alguien que tiene "algo que esconder", incluso si ella tiene cuidado de usar Tor solamente en cibercafés o similares. Y si Alice vive por ejemplo en Turquía, eso podría ser una muy mala idea.

Afortunadamente, Zcash fue diseñado para resolver exactamente este tipo de problemas. Al utilizar Zcash en lugar de un libro mayor totalmente transparente como Bitcoin o Ethereum, el blockchain ya no contiene información que vincule la apertura y el cierre del canal con Alice. Sin embargo, Zcash sólo maneja la privacidad para los pagos en la cadena; no se encarga de los pagarés.

El problema es que estos pagarés forman un identificador único que puede usarse para rastrear a Alice de la misma manera que sucede con las cookies. Cualquiera que las observe (por ejemplo, el nodo de salida de Tor) no sabrá a priori a quién pertenece el identificador ─su identidad real aún está protegida por el servicio de anonimato─, pero pueden de todos modos observar páginas visitadas y patrones porque varios pagos en un canal de pagos son inherentemente vinculables. Esto podría ser suficiente para identificar indivualmente a Alice (por ejemplo, si observa documentos relacionados con los artículos de prensa que escribió), o podría revelar otra información ─acerca de qué asunto está escribiendo un artículo, por ejemplo. Así que Zcash es parte de la solución, pero Zcash no hace, él mismo, un canal de pago privado.

BOLT: Canales de Pago Privados

Les presentamos BOLT, en lo que Matt y yo hemos estado trabajando los últimos meses. BOLT elimina el vínculo entre pagos dentro de un canal. Esto garantiza que los pagos de Alice estén ocultos dentro del conjunto de todos los pagos realizados a ese destinatario.

Hemos diseñado dos protocolos, uno que es no-interactivo, pero sólo permite el pago de Alice a Bob de valores fijos; y uno que permite pagos bidireccionales de valores arbitrarios, pero requiere interacción. Nos centraremos en el protocolo bidireccional aquí.

La idea básica del protocolo es la construcción de pagarés privados. Hacemos esto utilizando dos piezas de tecnología: firmas ciegas y compromisos. Los compromisos permiten a Alice ocultar el valor del pagaré (que podría hacerlo identificable). Las firmas ciegas convencen a Bob de que el pagaré es auténtico ─porque él tiene que haberlo firmado─ pero aseguran que no pueda reconocer la firma o el pagaré específicos entre cualquiera de los pagarés que haya firmado.

Diagrama de BOLT

Alice paga a Bob demostrando que tiene uno de esos pagarés, invalidándolo (al firmarlo con la clave de Revocación) y consiguiendo que Bob firme un nuevo pagaré con un saldo que es igual al saldo anterior menos el monto del pago. Del mismo modo, cuando Bob paga a Alice, la cantidad pagada se agrega al nuevo pagaré. El saldo real y la firma permanecen ocultos a Bob, asegurando que él no pueda saber si dos pagos distintos vinieron del mismo canal o de canales diferentes.

El verdadero desafío es invalidar el viejo pagaré y firmar el nuevo atómicamente. Y ─esta es la parte difícil─ hacerlo sin que se sepa qué canal está usando Alice. Si Alice invalida el viejo pagaré primero, y Bob se niega a firmar el nuevo pagaré, Alice no puede cerrar el canal por lo que pierde su dinero. Si Bob firma el nuevo pagaré antes de que el anterior sea invalidado, entonces Alice puede defraudar a Bob: Ella puede entonces tomar el nuevo pagaré firmado por Bob y usarlo para una serie de pagos, y luego pasar a efectivo el pagaré original manteniendo todo su dinero. En los canales de pago normales, esto no puede suceder porque Bob reconocería los pagos fraudulentos posteriores de Alice. Reconocer estos pagos con canales privados es, sin embargo, imposible.

Diagrama de BOLT

Para solucionar esto, separamos el proceso de generación de pagarés para el cierre de canales, de la permisión de que los pagarés sean utilizados para futuras transacciones. Un pagaré es un compromiso tanto con el saldo como con una clave pública de uso único llamada clave de revocación. Asumimos que Alice tiene un pagaré firmado (a ciegas) resultado del establecimiento del canal. ① Alice primero crea un nuevo pagaré y demuestra que éste le paga a Bob $5 más que un pagaré que Bob firmó anteriormente. ② Alice luego revela la clave pública de revocación del antiguo pagaré y obtiene ③ que Bob firme el nuevo pagaré de cierre (después, por supuesto, de comprobar que el nuevo pagaré está correctamente constituido con respecto al antiguo). ④ Entonces ella firma un mensaje invalidando el viejo pagaré con la clave de revocación y entrega el mensaje+firma a Bob. Esto es seguro porque ahora ella puede cerrar el canal con el nuevo pagaré sin importar lo que pase. ⑤ Después de asegurarse de que el pagaré antiguo ha sido revocado, Bob firma ahora el nuevo pagaré como válido para su uso en el próximo pago. Esto es seguro porque el viejo pagaré es inválido y por lo tanto Bob tiene la seguridad de que Alice nunca podrá volver a un estado anterior en el que tiene más dinero. Ahora Alice puede usar el nuevo pagaré en el siguiente pago BOLT.

Desde la perspectiva de Bob, él sabe que ha recibido un pago (de $5 en este ejemplo) en uno de sus canales de pago (o mejor dicho, recibirá $5 cuando ese canal de pago esté cerrado), pero no sabe cuál canal de pago fue utilizado realmente para el pago: le hemos ocultado el pagaré real, su saldo, y su firma, y estas son las únicas maneras en que podría identificar el canal.

La parte interesante de todo esto es que es simple, rápido, y utiliza criptografía muy bien entendida. Un prototipo será lanzado pronto, pero creemos que tomará menos de 50ms y 10MB de memoria ejecutar este protocolo.

Canales de Pago Indirectos

Hasta ahora, necesitamos que Alice y Bob tengan un canal de pago. Pero, ¿qué pasa si no lo tienen?

Al igual que Lightning, BOLT permite pagos cuando no hay un canal directo entre las partes, siempre y cuando compartan un intermediario (por ejemplo, Coinbase). Logramos esto haciendo que el uso de los pagarés para el cierre del canal sea condicional para las otras transacciones que estén pasando. A diferencia de Lightning, un simple intermediario no puede saber ni quiénes son los participantes involucrados ni cuál es la cantidad transferida. Para ello, es crucial que los propios canales sean financiados anónimamente, ya que el tercero puede retirarse y observar quién cierra su canal. Si el canal en sí es anónimo, esta información carece de valor.

Es probable que podamos generalizar los pagos indirectos de BOLT a pagos a través de múltiples intermediarios, como en Lightning, pero por el momento BOLT no lo hace.

¿Puede BOLT funcionar sin Zcash?

Podemos configurar BOLT para trabajar con la mayoría de las criptomonedas siempre que se puedan agregar los primitivos. Podríamos incluso ser capaces de hacer esto sin ningún cambio en Bitcoin, aunque a costa de usar compromisos basados en hash y computación multi-partes (MPC) genérica basada en circuitos para la firma ciega con ECDSA. Pero cualquier privacidad real proporcionada por BOLT depende fundamentalmente de que el establecimiento y el cierre del canal sean anónimos.

En Bitcoin, la financiación de un canal no es privada: hay un registro de con quién se abrió el canal, la cantidad y por qué se cerró. BOLT por sí solo no resuelve este problema: solamente hace que los pagos en el mismo canal no se puedan vincular entre sí. Peor aún, si un comerciante o un tercero puede forzar una salida en el protocolo BOLT, entonces pueden identificar qué canal usted está utilizando. Sólo pueden hacer esto una vez, por lo que no se pueden vincular varios pagos en el mismo canal, pero si no abrió el canal de forma anónima, entonces ese pago (abortado) se puede vincular a usted.

Para evitar esto, necesita fondos anónimos para crear el canal. De hecho, los requisitos de privacidad para agregar fondos a un canal son tan altos como los de los pagos normales. Por lo tanto, usted espera una privacidad tan fuerte como para los pagos normales. Y Zcash es la mejor manera de obtener fondos fuertemente privados.

Me gustaría dar las gracias a Sean Bowe, uno de los desarrolladores de Zcash, por sugerir la idea de combinar Lightning y Zerocash. Y a Sean, Maureen, Matthew, Daira, Jack, y el leopardo anónimo por sus comentarios y consejos sobre este artículo.