El pedigrí académico de Bitcoin

El concepto de criptomonedas se construye a partir de ideas olvidadas en la literatura de investigación. Por Arvind Narayanan y Jeremy Clark.

Si has leído sobre bitcoin en la prensa y estás familiarizado con la investigación académica en el campo de la criptografía, es razonable que te lleves la siguiente impresión: Varias décadas de investigación sobre el dinero digital, empezando por David Chaum^10,12, no condujeron al éxito comercial porque requerían un servidor centralizado, similar a un banco, que controlara el sistema, y ningún banco quiso firmar. Llegó el bitcoin, una propuesta radicalmente distinta de criptomoneda descentralizada que no necesitaba a los bancos, y el dinero digital triunfó por fin. Su inventor, el misterioso Satoshi Nakamoto, era un extraño académico, y bitcoin no se parece en nada a las propuestas académicas anteriores.

Este artículo cuestiona esa opinión demostrando que casi todos los componentes técnicos de bitcoin tienen su origen en la literatura académica de los años 80 y 90 (véase la figura 1). No se trata de menospreciar el logro de Nakamoto, sino de señalar que se subió a hombros de gigantes. De hecho, al rastrear los orígenes de las ideas de bitcoin, podemos centrarnos en el verdadero salto de visión de Nakamoto: la forma específica y compleja en que se unen los componentes subyacentes. Esto ayuda a explicar por qué el bitcoin tardó tanto en inventarse. Los lectores que ya estén familiarizados con el funcionamiento de bitcoin pueden comprender mejor esta presentación histórica. (Para una introducción, véase Bitcoin and Cryptocurrency Technologies de Arvind Narayanan³⁶) La historia intelectual de Bitcoin también sirve como estudio de caso que demuestra las relaciones entre el mundo académico, los investigadores externos y los profesionales, y ofrece lecciones sobre cómo estos grupos pueden beneficiarse mutuamente.

El Ledger

Si se dispone de un libro de contabilidad seguro, el proceso para convertirlo en un sistema de pago digital es sencillo. Por ejemplo, si Alicia envía 100 dólares a Bob por PayPal, PayPal cargará 100 dólares en la cuenta de Alicia y abonará 100 dólares en la cuenta de Bob. Esto es más o menos lo que ocurre en la banca tradicional, aunque la ausencia de un libro mayor único compartido por los bancos complica las cosas.

Esta idea de un libro de contabilidad es el punto de partida para entender bitcoin. Es un lugar donde se registran todas las transacciones que se producen en el sistema, y está abierto a todos los participantes en el sistema, que confían en él. Bitcoin convierte este sistema de registro de pagos en una moneda. Mientras que en la banca, el saldo de una cuenta representa dinero en efectivo que puede exigirse al banco, ¿qué representa una unidad de bitcoin? Por ahora, supongamos que lo que se está negociando tiene valor intrínseco.

¿Cómo se puede construir un libro de contabilidad para utilizarlo en un entorno como Internet en el que los participantes pueden no confiar los unos en los otros? Empecemos por lo más fácil: la elección de la estructura de datos. Hay algunas propiedades deseables. El libro mayor debe ser inmutable o, para ser más exactos, sólo debe poder añadirse: se deben poder añadir nuevas transacciones, pero no eliminar, modificar o reordenar las existentes. También debe haber una forma de obtener un resumen criptográfico sucinto del estado del libro mayor en cualquier momento. Un resumen es una cadena corta que permite evitar el almacenamiento del libro de contabilidad completo, sabiendo que si el libro de contabilidad fuera manipulado de alguna manera, el resumen resultante cambiaría y, por lo tanto, se detectaría la manipulación. La razón de estas propiedades es que, a diferencia de una estructura de datos normal que se almacena en una sola máquina, el libro mayor es una estructura de datos global mantenida colectivamente por un conjunto de participantes en los que no se confía mutuamente. Esto contrasta con otro enfoque para descentralizar los libros de contabilidad digitales^7,13,21 en el que muchos participantes mantienen libros de contabilidad locales y depende del usuario que consulta este conjunto de libros de contabilidad resolver cualquier conflicto.

Marcas de tiempo vinculadas

La estructura de datos del libro mayor de Bitcoin está tomada, con mínimas modificaciones, de una serie de artículos de Stuart Haber y Scott Stornetta escritos entre 1990 y 1997 (su artículo de 1991 tenía otro coautor, Dave Bayer)^5,22,23 Lo sabemos porque Nakamoto lo dice en su libro blanco de bitcoin^.34 El trabajo de Haber y Stornetta abordaba el problema del sellado de tiempo de los documentos: pretendían crear un servicio de «notario digital». En el caso de patentes, contratos comerciales y otros documentos, uno puede querer establecer que el documento se creó en un momento determinado, y no más tarde. Su noción de documento es bastante general y podría ser cualquier tipo de datos. Mencionan, de pasada, las transacciones financieras como una aplicación potencial, pero no era su objetivo.

En una versión simplificada de la propuesta de Haber y Stornetta, los documentos se crean y difunden constantemente. El creador de cada documento afirma una hora de creación y firma el documento, su marca de tiempo y el documento emitido anteriormente. Este documento anterior ha firmado a su propio predecesor, de modo que los documentos forman una larga cadena con punteros hacia atrás en el tiempo. Un usuario externo no puede alterar un mensaje con marca de tiempo, ya que está firmado por el creador, y el creador no puede alterar el mensaje sin alterar también toda la cadena de mensajes que le sigue. Así, si una fuente de confianza (por ejemplo, otro usuario o un servicio especializado en sellado de tiempo) te proporciona un único elemento de la cadena, toda la cadena hasta ese punto queda bloqueada, inmutable y ordenada temporalmente. Además, si se asume que el sistema rechaza documentos con fechas de creación incorrectas, se puede estar razonablemente seguro de que los documentos son al menos tan antiguos como dicen ser. En cualquier caso, bitcoin sólo toma prestada la estructura de datos del trabajo de Haber y Stornetta y rediseña sus propiedades de seguridad añadiendo el esquema de prueba de trabajo que se describe más adelante en este artículo.

En sus trabajos de seguimiento, Haber y Stornetta introdujeron otras ideas que hacen que esta estructura de datos sea más eficaz y eficiente (algunas de las cuales se insinuaban en su primer trabajo). En primer lugar, los enlaces entre documentos pueden crearse utilizando hashes en lugar de firmas; los hashes son más sencillos y rápidos de calcular. Estos enlaces se denominan punteros hash. En segundo lugar, en lugar de enhebrar los documentos individualmente -lo que puede resultar ineficaz si se crean muchos documentos aproximadamente al mismo tiempo-, pueden agruparse en lotes o bloques, y los documentos de cada bloque tienen esencialmente la misma marca de tiempo. En tercer lugar, dentro de cada bloque, los documentos pueden enlazarse mediante un árbol binario de punteros hash, denominado árbol de Merkle, en lugar de una cadena lineal. Por cierto, Josh Benaloh y Michael de Mare introdujeron estas tres ideas de forma independiente en 1991⁶ poco después del primer artículo de Haber y Stornetta.

Árboles de Merkle

Bitcoin utiliza esencialmente la estructura de datos de los artículos de Haber y Stornetta de 1991 y 1997, que se muestra de forma simplificada en la figura 2 (es de suponer que Nakamoto desconocía el trabajo de Benaloh y de Mare). Por supuesto, en bitcoin, las transacciones ocupan el lugar de los documentos. En el árbol de Merkle de cada bloque, los nodos de las hojas son transacciones, y cada nodo interno consiste esencialmente en dos punteros. Esta estructura de datos tiene dos propiedades importantes. En primer lugar, el hash del último bloque actúa como un compendio. Un cambio en cualquiera de las transacciones (nodos hoja) hará que los cambios se propaguen hasta la raíz del bloque y las raíces de todos los bloques siguientes. Así, si conoces el último hash, puedes descargar el resto del libro mayor de una fuente no fiable y verificar que no ha cambiado. Un argumento similar establece otra propiedad importante de la estructura de datos, a saber, que alguien puede demostrarle de forma eficiente que una transacción concreta está incluida en el libro mayor. Este usuario sólo tendría que enviarle un pequeño número de nodos en el bloque de esa transacción (éste es el objetivo del árbol de Merkle), así como una pequeña cantidad de información para cada bloque siguiente. La capacidad de demostrar eficientemente la inclusión de transacciones es muy deseable para el rendimiento y la escalabilidad.

Los árboles de Merkle, por cierto, deben su nombre a Ralph Merkle, un pionero de la criptografía asimétrica que propuso la idea en su artículo de 1980^.33 Su aplicación prevista era producir un compendio para un directorio público de certificados digitales. Cuando un sitio web, por ejemplo, le presenta un certificado, también podría presentar una breve prueba de que el certificado aparece en el directorio global. Usted podría verificar eficazmente la prueba siempre que conozca el hash raíz del árbol de Merkle de los certificados del directorio. Esta idea es antigua para los estándares criptográficos, pero su potencia no se ha apreciado hasta hace poco. Es el núcleo del sistema de Transparencia de Certificados recientemente implementado^.30 Un documento de 2015 propone CONIKS, que aplica la idea a directorios de claves públicas para correos electrónicos cifrados de extremo a extremo^.32 La verificación eficiente de partes del estado global es una de las funcionalidades clave proporcionadas por el libro mayor en Ethereum, una nueva criptodivisa.

Puede que Bitcoin sea la aplicación más conocida en el mundo real de las estructuras de datos de Haber y Stornetta, pero no es la primera. Al menos dos empresas -Surety desde mediados de los 90 y Guardtime desde 2007- ofrecen servicios de sellado de tiempo de documentos. Un giro interesante presente en ambos servicios es una idea mencionada por Bayer, Haber y Stornetta⁵ que consiste en publicar raíces de Merkle periódicamente en un periódico mediante un anuncio. La figura 3 muestra una raíz Merkle publicada por Guardtime.

Tolerancia bizantina a fallos

Por supuesto, los requisitos de una moneda de Internet sin autoridad central son más estrictos. Un libro de contabilidad distribuido tendrá inevitablemente bifurcaciones, lo que significa que algunos nodos pensarán que el bloque A es el último bloque, mientras que otros nodos pensarán que es el bloque B. Esto puede deberse a un adversario que intente interrumpir el funcionamiento del libro de contabilidad o simplemente a la latencia de la red, lo que provoca que ocasionalmente se generen bloques casi simultáneamente por diferentes nodos que desconocen los bloques de los demás. Las marcas de tiempo vinculadas no bastan por sí solas para resolver las bifurcaciones, como demostró Mike Just en 1998^.26

Un campo de investigación diferente, la computación distribuida tolerante a fallos, ha estudiado este problema, donde recibe diferentes nombres, incluida la replicación de estados. Una solución a este problema es aquella que permite a un conjunto de nodos aplicar las mismas transiciones de estado en el mismo orden; normalmente, el orden exacto no importa, sólo que todos los nodos sean coherentes. En el caso de una moneda digital, el estado a replicar es el conjunto de saldos, y las transacciones son transiciones de estado. Las primeras soluciones, como Paxos, propuesta por Leslie Lamport, ganador del premio Turing en 1989^28,29 consideran la replicación de estados cuando los canales de comunicación no son fiables y cuando una minoría de nodos puede presentar ciertos fallos «realistas», como desconectarse para siempre o reiniciarse y enviar mensajes obsoletos desde la primera vez que se desconectó. Siguió una prolífica literatura con configuraciones más adversas y compensaciones de eficiencia.

Una línea de trabajo relacionada estudió la situación en la que la red es fiable en su mayor parte (los mensajes se entregan con un retraso limitado), pero en la que la definición de «fallo» se amplió para abarcar cualquier desviación del protocolo. Estos fallos bizantinos incluyen tanto fallos naturales como comportamientos malintencionados. Se estudiaron por primera vez en un artículo también de Lamport, escrito en colaboración con Robert Shostak y Marshall Pease, ya en 1982^.27 Mucho más tarde, en 1999, un artículo histórico de Miguel Castro y Barbara Liskov introdujo PBFT (tolerancia práctica a fallos bizantinos), que se adaptaba tanto a los fallos bizantinos como a una red poco fiable^.8 En comparación con el sellado de tiempo enlazado, la literatura sobre tolerancia a fallos es enorme e incluye cientos de variantes y optimizaciones de Paxos, PBFT y otros protocolos seminales.

En su libro blanco original, Nakamoto no cita esta literatura ni utiliza su lenguaje. Utiliza algunos conceptos, refiriéndose a su protocolo como un mecanismo de consenso y considerando fallos tanto en forma de atacantes como de nodos que entran y salen de la red. Esto contrasta con su confianza explícita en la literatura sobre sellado de tiempo vinculado (y prueba de trabajo, que se discute a continuación). Cuando se le pregunta en una lista de correo sobre la relación de bitcoin con el problema bizantino de los generales (un experimento mental que requiere BFT para resolverse), Nakamoto afirma que la cadena de prueba de trabajo resuelve este problema^.35

En los años siguientes, otros académicos han estudiado el consenso de Nakamoto desde la perspectiva de los sistemas distribuidos. Esto sigue siendo un trabajo en curso. Algunos demuestran que las propiedades de bitcoin son bastante débiles^, 43 mientras que otros argumentan que la perspectiva BFT no hace justicia a las propiedades de consistencia de bitcoin^. 40 Otro enfoque consiste en definir variantes de propiedades bien estudiadas y demostrar que bitcoin las satisface^.19 Recientemente, estas definiciones se han afinado sustancialmente para proporcionar una definición de consistencia más estándar que se mantiene bajo supuestos más realistas sobre la entrega de mensajes^.37 Todo este trabajo, sin embargo, hace suposiciones sobre el comportamiento «honesto», es decir, que cumple con el procotol, entre un subconjunto de participantes, mientras que Nakamoto sugiere que el comportamiento honesto no necesita ser asumido ciegamente, porque está incentivado. Un análisis más detallado del consenso de Nakamoto que tenga en cuenta el papel de los incentivos no encaja perfectamente en los modelos anteriores de sistemas tolerantes a fallos.

Prueba de trabajo

Prácticamente todos los sistemas tolerantes a fallos asumen que una mayoría estricta o una supermayoría (por ejemplo, más de la mitad o dos tercios) de los nodos del sistema son honestos y fiables. En una red peer-to-peer abierta, no hay registro de nodos, y éstos se unen y abandonan libremente. Así, un adversario puede crear suficientes Sybils, o nodos títeres, para superar las garantías de consenso del sistema. El ataque Sybil fue formalizado en 2002 por John Douceur¹⁴ que recurrió a una construcción criptográfica llamada prueba de trabajo para mitigarlo.

Los orígenes

Para entender la prueba de trabajo, volvamos a sus orígenes. La primera propuesta que hoy se llamaría prueba de trabajo fue creada en 1992 por Cynthia Dwork y Moni^Naor15. Obsérvese que el spam, los ataques Sybil y la denegación de servicio son problemas muy similares en los que el adversario amplifica su influencia en la red en comparación con los usuarios normales; la prueba de trabajo es aplicable como defensa contra los tres. En el diseño de Dwork y Naor, los destinatarios de correo electrónico sólo procesarían aquellos correos que estuvieran acompañados de una prueba de que el remitente había realizado una cantidad moderada de trabajo computacional, de ahí lo de «prueba de trabajo». Calcular la prueba llevaría unos segundos en un ordenador normal. Por lo tanto, no supondría ninguna dificultad para los usuarios normales, pero un spammer que quisiera enviar un millón de correos electrónicos necesitaría varias semanas, utilizando un hardware equivalente.

Hay que tener en cuenta que la prueba de trabajo (también llamada puzzle) debe ser específica para el correo electrónico y el destinatario. De lo contrario, un spammer podría enviar múltiples mensajes al mismo destinatario (o el mismo mensaje a múltiples destinatarios) por el coste de un mensaje a un destinatario. La segunda propiedad crucial es que debe suponer una carga computacional mínima para el destinatario; las soluciones de los rompecabezas deben ser triviales de verificar, independientemente de lo difíciles que sean de calcular. Además, Dwork y Naor consideraron funciones con una trampilla, un secreto conocido por una autoridad central que permitiría a la autoridad resolver los enigmas sin hacer el trabajo. Una posible aplicación de una trampilla sería que la autoridad aprobara la publicación en listas de correo sin incurrir en costes. La propuesta de Dwork y Naor consistía en tres rompecabezas candidatos que cumplían sus propiedades, y puso en marcha todo un campo de investigación, al que volveremos.

Hashcash

Una idea muy similar llamada hashcash fue inventada de forma independiente en 1997 por Adam Back, un investigador postdoctoral que formaba parte de la comunidad cypherpunk. Los cypherpunks eran activistas que se oponían al poder de los gobiernos y las instituciones centralizadas, y buscaban crear un cambio social y político a través de la criptografía. Back tenía una orientación práctica: primero lanzó hashcash como^software2 y cinco años después, en 2002, publicó un borrador de Internet (un documento de estandarización) y un^artículo4.

Hashcash es mucho más simple que la idea de Dwork y Naor: no tiene trampilla ni autoridad central, y sólo utiliza funciones hash en lugar de firmas digitales. Se basa en un principio sencillo: una función hash se comporta como una función aleatoria para algunos fines prácticos, lo que significa que la única forma de encontrar una entrada que genere un hash con una salida determinada es probar varias entradas hasta que una produzca la salida deseada. Además, la única manera de encontrar una entrada que se convierte en un conjunto arbitrario de salidas es, de nuevo, probar a convertir diferentes entradas una a una. Así que, si te reto a encontrar una entrada cuyo valor hash (binario) empiece por 10 ceros, tendrías que probar numerosas entradas, y descubrirías que cada salida tiene una probabilidad de ^1/210 de empezar por 10 ceros, lo que significa que tendrías que probar²¹⁰ entradas, o aproximadamente 1.000 cálculos hash.

Como su nombre indica, en hashcash Back consideraba las pruebas de trabajo como una forma de dinero en efectivo. En su página web lo posicionó como una alternativa al DigiCash de David Chaum, que era un sistema que emitía dinero digital no rastreable de un banco a un usuario^.3 Incluso hizo concesiones al diseño técnico para que pareciera más dinero en efectivo. Más tarde, Back hizo comentarios sugiriendo que bitcoin era una extensión directa de hashcash. Sin embargo, Hashcash simplemente no es dinero en efectivo, porque no tiene protección contra el doble gasto. Los tokens Hashcash no pueden intercambiarse entre pares.

Mientras tanto, en el ámbito académico, los investigadores encontraron muchas aplicaciones para la prueba de trabajo además del spam, como la prevención de ataques de denegación de servicio²⁵ garantizar la integridad de los análisis web¹⁷ y limitar la tasa de adivinación de contraseñas en línea^.38 Por cierto, el término prueba de trabajo no se acuñó hasta 1999 en un artículo de Markus Jakobsson y Ari Juels, que también incluye un buen resumen del trabajo hasta ese momento^.24 Merece la pena señalar que estos investigadores no parecían conocer hashcash, pero empezaron a converger de forma independiente en la prueba de trabajo basada en hash, que se introdujo en los trabajos de Eran Gabber et al^.18 y de Juels y Brainard^. 25 (Muchos de los términos utilizados a lo largo de este párrafo no se convirtieron en terminología estándar hasta mucho después de que se publicaran los trabajos en cuestión).

Prueba de trabajo y dinero digital: Un callejón sin salida

Es posible que sepa que la prueba del trabajo no tuvo éxito en su aplicación original como medida anti-spam. Una posible razón es la drástica diferencia en la velocidad de resolución de rompecabezas de los distintos dispositivos. Eso significa que los spammers podrán hacer una pequeña inversión en hardware personalizado para aumentar su tasa de spam en órdenes de magnitud. En economía, la respuesta natural a una asimetría en el coste de producción es el comercio, es decir, un mercado de soluciones de prueba de trabajo. Pero esto presenta un dilema, porque requeriría una moneda digital operativa. De hecho, la falta de tal moneda es una parte importante de la motivación para la prueba de trabajo en primer lugar. Una solución rudimentaria a este problema es declarar que las soluciones de los puzles son dinero en efectivo, como intenta hacer hashcash.

Enfoques más coherentes para tratar las soluciones de los puzzles como dinero se encuentran en dos ensayos que precedieron a bitcoin, describiendo ideas llamadas ^b-money13 y bit ^gold42 respectivamente. Estas propuestas ofrecen servicios de sellado de tiempo que aprueban la creación (mediante pruebas de trabajo) del dinero y, una vez creado, aprueban las transferencias. Sin embargo, si se produce un desacuerdo sobre el libro mayor entre los servidores o nodos, no hay una forma clara de resolverlo. Dejar que la mayoría decida parece estar implícito en los escritos de ambos autores, pero debido al problema Sybil, estos mecanismos no son muy seguros, a menos que haya un guardián que controle la entrada en la red o que la propia resistencia Sybil se consiga con pruebas de trabajo.

En resumen

Comprender todos estos predecesores que contienen piezas del diseño de bitcoin lleva a apreciar la verdadera genialidad de la innovación de Nakamoto. En bitcoin, por primera vez, las soluciones de los enigmas no constituyen dinero por sí mismas. En su lugar, se utilizan simplemente para asegurar el libro mayor. La resolución de las pruebas de trabajo corre a cargo de entidades especializadas llamadas mineros (aunque Nakamoto subestimó lo especializada que llegaría a ser la minería).

Los mineros compiten constantemente entre sí para encontrar la siguiente solución al enigma; cada minero resuelve una variante ligeramente diferente del enigma, de modo que la probabilidad de éxito es proporcional a la fracción de la potencia minera global que controla el minero. El minero que resuelve un enigma contribuye con el siguiente lote, o bloque, de transacciones al libro mayor, que se basa en la marca de tiempo vinculada. A cambio del servicio de mantener el libro de contabilidad, el minero que contribuye con un bloque es recompensado con unidades de la moneda recién acuñadas. Con gran probabilidad, si un minero contribuye con una transacción o un bloque no válido, será rechazado por la mayoría de los demás mineros que contribuyan con los siguientes bloques, y esto también invalidará la recompensa del bloque malo. De este modo, debido a los incentivos monetarios, los mineros se aseguran mutuamente de que cumplen el protocolo.

Bitcoin evita el problema del doble gasto que afecta a los sistemas de prueba de trabajo como dinero en efectivo porque evita que las soluciones de los puzzles tengan valor por sí mismas. De hecho, las soluciones de los puzles están doblemente desvinculadas del valor económico: la cantidad de trabajo necesaria para producir un bloque es un parámetro flotante (proporcional a la potencia minera global) y, además, el número de bitcoins emitidos por bloque tampoco es fijo. La recompensa por bloque (que es como se acuñan los nuevos bitcoins) se reduce a la mitad cada cuatro años (en 2017, la recompensa es de 12,5 bitcoins/bloque, frente a 50 bitcoins/bloque). Bitcoin incorpora un esquema de recompensa adicional: los remitentes de transacciones pagan a los mineros por el servicio de incluir la transacción en sus bloques. Se espera que el mercado determine las tarifas de transacción y las recompensas de los mineros.

El genio de Nakamoto no fue ninguno de los componentes individuales de bitcoin, sino la intrincada forma en que encajan para dar vida al sistema. Los investigadores de los sellos de tiempo y los acuerdos bizantinos no dieron con la idea de incentivar a los nodos para que fueran honestos ni, hasta 2005, de utilizar la prueba de trabajo para eliminar las identidades. A la inversa, los autores de hashcash, b-money y bit gold no incorporaron la idea de un algoritmo de consenso para evitar el doble gasto. En bitcoin, es necesario un libro de contabilidad seguro para evitar el doble gasto y garantizar así que la moneda tenga valor. Una moneda valiosa es necesaria para recompensar a los mineros. A su vez, la fuerza de la minería es necesaria para asegurar el libro de contabilidad. Sin ella, un adversario podría acumular más del 50% de la potencia minera mundial y, por tanto, ser capaz de generar bloques más rápido que el resto de la red, duplicar el gasto de las transacciones y reescribir la historia, anulando el sistema. De este modo, bitcoin se basa en una dependencia circular entre estos tres componentes. El reto de Nakamoto no fue sólo el diseño, sino también convencer a la comunidad inicial de usuarios y mineros para que dieran juntos un salto hacia lo desconocido, cuando una pizza costaba 10.000 bitcoins y la potencia minera de la red era menos de una billonésima parte de la actual.

Claves públicas como identidades

Este artículo comenzó con la idea de que un libro de contabilidad seguro facilita la creación de moneda digital. Revisemos esta afirmación. Cuando Alicia desea pagar a Bob, transmite la transacción a todos los nodos bitcoin. Una transacción es simplemente una cadena: una declaración que codifica el deseo de Alice de pagar a Bob algún valor, firmada por ella. La eventual inclusión de esta declaración firmada en el libro mayor por los mineros es lo que hace que la transacción sea real. Ten en cuenta que esto no requiere la participación de Bob de ninguna manera. Pero centrémonos en lo que no está en la transacción: las identidades de Alice y Bob brillan por su ausencia; en su lugar, la transacción sólo contiene sus respectivas claves públicas. Este es un concepto importante en bitcoin: las claves públicas son los únicos tipos de identidad en el sistema. Las transacciones transfieren valor desde y hacia claves públicas, que se denominan direcciones.

Para «hablar por» una identidad, debes conocer la clave secreta correspondiente. Puede crear una nueva identidad en cualquier momento generando un nuevo par de claves, sin autoridad central ni registro. No necesitas obtener un nombre de usuario ni informar a los demás de que has elegido un nombre concreto. Esta es la noción de gestión de identidad descentralizada. Bitcoin no especifica cómo Alice le dice a Bob cuál es su pseudónimo, eso es externo al sistema.

Aunque radicalmente diferentes de la mayoría de los sistemas de pago actuales, estas ideas son bastante antiguas, ya que se remontan a David Chaum, el padre del dinero digital. De hecho, Chaum también hizo aportaciones fundamentales a las redes de anonimato, y es en este contexto en el que inventó esta idea. En su artículo de 1981, «Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms^« (Correo electrónico imposible de rastrear, direcciones de remitente y seudónimos digitales⁾⁹, afirma: «Un seudónimo digital’ es una clave pública utilizada para verificar las firmas realizadas por el titular anónimo de la clave privada correspondiente».

Ahora bien, que los destinatarios de los mensajes sólo se conozcan por una clave pública presenta un problema obvio: no hay forma de dirigir el mensaje al ordenador correcto. Esto provoca una enorme ineficiencia en la propuesta de Chaum, que puede compensarse con el nivel de anonimato, pero no eliminarse. Bitcoin es igualmente ineficiente en comparación con los sistemas de pago centralizados: el libro de contabilidad que contiene cada transacción es mantenido por cada nodo del sistema. Bitcoin incurre en esta ineficiencia por razones de seguridad de todos modos, y así consigue el pseudonimato (es decir, claves públicas como identidades) «gratis». Chaum llevó estas ideas mucho más lejos en un artículo de 1985¹¹ donde presenta una visión del comercio electrónico que preserva la privacidad basada en seudónimos omnipresentes, así como en «firmas ciegas», la idea técnica clave detrás de su dinero digital.

La idea de las claves públicas como identidades también aparece en b-money y bit gold, los dos ensayos precursores de bitcoin comentados anteriormente. Sin embargo, gran parte del trabajo que se construyó sobre los cimientos de Chaum, así como el propio trabajo posterior de Chaum sobre ecash, se alejaron de esta idea. Los cypherpunks estaban muy interesados en preservar la privacidad en la comunicación y el comercio, y adoptaron seudónimos, a los que llamaron nyms. Pero para ellos, los nyms no eran meras identidades criptográficas (es decir, claves públicas), sino que solían ser direcciones de correo electrónico vinculadas a claves públicas. De forma similar, la tesis de Ian Goldberg, que se convirtió en la base de muchos trabajos futuros sobre comunicación anónima, reconoce la idea de Chaum pero sugiere que los nyms deberían ser apodos memorizables por humanos con certificados para vincularlos^.20 Así, Bitcoin demostró ser la instanciación más exitosa de la idea de Chaum.

La cadena de bloques

Hasta ahora, este artículo no ha abordado la cadena de bloques, que, si se cree lo que se dice, es el principal invento de Bitcoin. Puede que te sorprenda que Nakamoto no mencione ese término en absoluto. De hecho, el término blockchain no tiene una definición técnica estándar, sino que es un término general utilizado por varias partes para referirse a los sistemas que tienen diferentes niveles de similitud con bitcoin y su libro de contabilidad.

Analizar ejemplos de aplicaciones que se benefician de una cadena de bloques ayudará a aclarar los distintos usos del término. En primer lugar, consideremos una base de datos para transacciones entre un consorcio de bancos, donde las transacciones se compensan al final de cada día y las cuentas son liquidadas por el banco central. Este sistema tiene un número reducido de partes bien identificadas, por lo que el consenso de Nakamoto sería excesivo. Tampoco se necesita una moneda en la cadena de bloques, ya que las cuentas están denominadas en la moneda tradicional. Por otro lado, la marca de tiempo vinculada sería claramente útil, al menos para garantizar un orden global coherente de las transacciones frente a la latencia de la red. La replicación de estados también sería útil: un banco sabría que su copia local de los datos es idéntica a la que utilizará el banco central para liquidar su cuenta. Esto libera a los bancos del costoso proceso de reconciliación que deben realizar actualmente.

En segundo lugar, consideremos una aplicación de gestión de activos, como un registro de documentos que rastrea la propiedad de valores financieros, o bienes inmuebles, o cualquier otro activo. El uso de una cadena de bloques aumentaría la interoperabilidad y reduciría las barreras de entrada. Queremos un registro seguro y global de documentos, e idealmente uno que permita la participación pública. Esto es esencialmente lo que los servicios de sellado de tiempo de los años 90 y 2000 trataron de proporcionar. Hoy en día, las cadenas de bloques públicas ofrecen una forma especialmente eficaz de conseguirlo (los propios datos pueden almacenarse fuera de la cadena y sólo los metadatos dentro de ella). Otras aplicaciones también se benefician de una abstracción de sellado de tiempo o «tablón de anuncios público», sobre todo la votación electrónica.

Sigamos con el ejemplo de la gestión de activos. Supongamos que desea ejecutar operaciones con activos a través de la cadena de bloques, y no sólo registrarlas en ella. Esto es posible si el activo se emite digitalmente en la propia cadena de bloques y si ésta admite contratos inteligentes. En este caso, los contratos inteligentes resuelven el problema del «intercambio justo» al garantizar que el pago se realiza si y sólo si se transfiere el activo. En términos más generales, los contratos inteligentes pueden codificar una lógica empresarial compleja, siempre que todos los datos de entrada necesarios (activos, sus precios, etc.) estén representados en la cadena de bloques.

Esta asignación de propiedades de blockchain a aplicaciones nos permite no sólo apreciar su potencial, sino también inyectar una dosis muy necesaria de escepticismo. En primer lugar, muchas de las aplicaciones propuestas para las cadenas de bloques, especialmente en el sector bancario, no utilizan el consenso de Nakamoto. En su lugar, utilizan la estructura de datos ledger y el acuerdo bizantino, que, como se ha demostrado, datan de los años 90. Esto desmiente la afirmación de que las cadenas de bloques son una tecnología nueva y revolucionaria. Por el contrario, el rumor en torno a las blockchains ha ayudado a los bancos a iniciar una acción colectiva para desplegar la tecnología de libro mayor compartido, como la parábola de la «sopa de piedra». Bitcoin también ha servido como prueba de concepto muy visible de que el libro mayor descentralizado funciona, y el proyecto Bitcoin Core ha proporcionado una cómoda base de código que puede adaptarse según sea necesario.

En segundo lugar, las cadenas de bloques se presentan a menudo como más seguras que los registros tradicionales, una afirmación engañosa. Para ver por qué, hay que separar la estabilidad general del sistema o plataforma de la seguridad del punto final, es decir, la seguridad de los usuarios y dispositivos. Es cierto que el riesgo sistémico de las cadenas de bloques puede ser menor que el de muchas instituciones centralizadas, pero el riesgo de seguridad del punto final de las cadenas de bloques es mucho peor que el riesgo correspondiente de las instituciones tradicionales. Las transacciones de las cadenas de bloques son casi instantáneas, irreversibles y, en las cadenas de bloques públicas, anónimas por diseño. Con un registro de valores basado en blockchain, si un usuario (o un corredor o un agente) pierde el control de sus claves privadas -lo que no requiere nada más que perder un teléfono o que un ordenador se infecte con malware-, el usuario pierde sus activos. El extraordinario historial de hackeos, robos y estafas con bitcoins no inspira mucha confianza: según una estimación, al menos el seis por ciento de los bitcoins en circulación han sido robados al menos una vez^.39

Lecciones finales

La historia aquí descrita ofrece lecciones enriquecedoras (y complementarias) para profesionales y académicos. Los profesionales deben mostrarse escépticos ante las afirmaciones de una tecnología revolucionaria. Como se muestra aquí, la mayoría de las ideas de bitcoin que han generado entusiasmo en la empresa, como los libros de contabilidad distribuidos y el acuerdo bizantino, datan en realidad de hace 20 años o más. Reconozca que su problema puede no requerir ningún gran avance: puede haber soluciones olvidadas hace mucho tiempo en trabajos de investigación.

El mundo académico parece tener el problema opuesto, al menos en este caso: una resistencia a las ideas radicales y extrínsecas. El libro blanco de bitcoin, a pesar del pedigrí de muchas de sus ideas, era más novedoso que la mayoría de las investigaciones académicas. Además, a Nakamoto no le interesaba la revisión académica por pares y no la relacionaba plenamente con su historia. Como resultado, los académicos esencialmente ignoraron bitcoin durante varios años. Muchas comunidades académicas argumentaron informalmente que Bitcoin no podía funcionar, basándose en modelos teóricos o experiencias con sistemas anteriores, a pesar de que funcionaba en la práctica.

Hemos visto repetidamente que las ideas en la literatura de investigación pueden olvidarse gradualmente o no ser apreciadas, especialmente si se adelantan a su tiempo, incluso en áreas populares de investigación. Tanto los profesionales como los académicos harían bien en revisar viejas ideas para extraer ideas para los sistemas actuales. Bitcoin fue inusual y tuvo éxito no porque estuviera a la vanguardia de la investigación en cualquiera de sus componentes, sino porque combinó viejas ideas de muchos campos anteriormente no relacionados. Esto no es fácil de hacer, ya que requiere unir terminología dispar, suposiciones, etc., pero es un valioso modelo para la innovación.

Los profesionales se beneficiarían de ser capaces de identificar la tecnología sobredimensionada. Algunos indicadores de exageración son: dificultad para identificar la innovación técnica; dificultad para precisar el significado de términos supuestamente técnicos, debido a las empresas deseosas de enganchar sus propios productos al carro; dificultad para identificar el problema que se está resolviendo; y, por último, afirmaciones de que la tecnología resuelve problemas sociales o crea trastornos económicos/políticos.

En cambio, el mundo académico tiene dificultades para vender sus inventos. Por ejemplo, es lamentable que los investigadores originales de la prueba de trabajo no reciban ningún crédito por bitcoin, posiblemente porque el trabajo no era muy conocido fuera de los círculos académicos. Actividades como la publicación de código y la colaboración con profesionales no se recompensan adecuadamente en el mundo académico. De hecho, la rama original de la literatura académica sobre la prueba de trabajo continúa hoy sin reconocer la existencia de bitcoin. Comprometerse con el mundo real no sólo ayuda a obtener crédito, sino que también reducirá la reinvención y es una fuente de ideas frescas.

Sidebars

Redes resistentes a los sibilinos

En su artículo sobre los ataques Sybil, John Douceur propuso que todos los nodos participantes en un protocolo BFT tuvieran que resolver puzzles de hashcash. Si un nodo se hiciera pasar por N nodos, sería incapaz de resolver N acertijos a tiempo, y las identidades falsas se purgarían. Sin embargo, un nodo malicioso aún podría obtener una ventaja moderada sobre un nodo honesto que reivindicara una sola identidad. Un artículo de ²⁰⁰⁵¹ sugería que los nodos honestos deberían imitar el comportamiento de los nodos maliciosos y reclamar tantas identidades virtuales como pudieran permitirse computacionalmente. Con estas identidades virtuales ejecutando un protocolo BFT, la suposición «Como máximo una fracción f de nodos son defectuosos» puede sustituirse por la suposición «La fracción de la potencia computacional total controlada por nodos defectuosos es como máximo f«. Así, ya no es necesario validar identidades, y las redes abiertas entre iguales pueden ejecutar un protocolo BFT. Bitcoin utiliza exactamente esta idea. Pero Nakamoto plantea otra pregunta: ¿Qué motiva a los nodos a realizar pruebas de trabajo computacionalmente costosas? La respuesta requiere otro salto: la moneda digital.

Contratos inteligentes

Un contrato inteligente toma la idea de poner los datos en un libro de contabilidad seguro y la extiende a la computación. En otras palabras, es un protocolo de consenso para la correcta ejecución de un programa especificado públicamente. Los usuarios pueden invocar funciones en estos programas de contratos inteligentes, sujetas a cualquier restricción especificada por el programa, y el código de la función es ejecutado en tándem por los mineros. Los usuarios pueden confiar en la salida sin tener que rehacer el cálculo y pueden escribir sus propios programas para actuar sobre la salida de otros programas. Los contratos inteligentes son especialmente potentes cuando se combinan con una plataforma de criptomoneda, porque los programas en cuestión pueden manejar dinero: poseerlo, transferirlo, destruirlo y, en algunos casos, incluso imprimirlo.

Bitcoin implementa un lenguaje de programación restrictivo para los contratos inteligentes. Una transacción «estándar» (es decir, una que mueve moneda de una dirección a otra) se especifica como una breve secuencia de comandos en este lenguaje. Ethereum ofrece un lenguaje más permisivo y potente.

La idea de los contratos inteligentes fue propuesta por Nick Szabo en ¹⁹⁹⁴⁴¹ y se denominaron así porque los consideraba análogos a los contratos legales, pero con un cumplimiento automatizado. (Este punto de vista ha sido criticado por Karen ^Levy31 y Ed Felten^.16) En su momento, Szabo presentó los contratos inteligentes como extensiones de los protocolos de dinero digital y reconoció que el acuerdo bizantino y las firmas digitales (entre otros) podrían utilizarse como bloques de construcción. El éxito de las criptomonedas ha hecho que los contratos inteligentes sean prácticos, y la investigación sobre el tema también ha florecido. Por ejemplo, los investigadores de lenguajes de programación han adaptado sus métodos y herramientas para descubrir automáticamente errores en los contratos inteligentes y escribir contratos verificablemente correctos.

Blockchains autorizadas

Aunque en este artículo se ha hecho hincapié en que las cadenas de bloques privadas o autorizadas omiten la mayoría de las innovaciones de bitcoin, esto no pretende restar importancia al interesante trabajo que se está llevando a cabo en este ámbito. Una cadena de bloques autorizada impone restricciones sobre quién puede unirse a la red, escribir transacciones o minar bloques. En concreto, si los mineros se limitan a una lista de participantes de confianza, la prueba de trabajo puede abandonarse en favor de un enfoque BFT más tradicional. Así, gran parte de la investigación es un renacimiento de la BFT que plantea preguntas como: ¿Podemos utilizar árboles hash para simplificar los algoritmos de consenso? ¿Y si la red sólo puede fallar de determinadas maneras?

Además, hay consideraciones importantes en torno a la identidad y la infraestructura de clave pública, el control de acceso y la confidencialidad de los datos almacenados en la blockchain. Estas cuestiones no se plantean en gran medida en entornos de cadenas de bloques públicas, ni se estudian en la bibliografía tradicional sobre BFT.

Por último, también hay que tener en cuenta el trabajo de ingeniería que supone escalar las cadenas de bloques para obtener un alto rendimiento y adaptarlas a diversas aplicaciones, como la gestión de la cadena de suministro y la tecnología financiera.

---

Agradecimientos

Los autores agradecen a Adam Back, Andrew Miller, Edward Felten, Harry Kalodner, Ian Goldberg, Ian Grigg, Joseph Bonneau, Malte Möser, Mike Just, Neha Narula, Steven Goldfeder y Stuart Haber sus valiosos comentarios sobre un borrador.

Referencias

1. Aspnes, J., et al. 2005. Exposing computationally challenged Byzantine imposters. Departamento de Informática de la Universidad de Yale; http://cs.yale.edu/publications/techreports/tr1332.pdf.

2. Back, A. 1997. A partial hash collision based postage scheme; http://www.hashcash.org/papers/announce.txt.

3. Back, A. 2001. Hash cash; https://web.archive.org/web/20010614013848/http://cypherspace.org/hashcash/.

4. Back, A. 2002. Hashcash-a denial of service counter measure; http://www.hashcash.org/papers/hashcash.pdf.

5. Bayer, D., Haber, S., Stornetta, W. S. Improving the efficiency and reliability of digital time-stamping. Actas de Sequences 1991; https://link.springer.com/chapter/10.1007/978-1-4613-9323-8_24.

6. Benaloh, J., de Mare, M. 1991. Efficient broadcast timestamping; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9199.

7. Boyle, T. F. 1997. GLT and GLR: Component architecture for general ledgers; https://linas.org/mirrors/www.gldialtone.com/2001.07.14/GLT-GLR.htm.

8. Castro, M., Liskov, B. 1999. Practical Byzantine fault tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation; http://pmg.csail.mit.edu/papers/osdi99.pdf.

9. Chaum, D. 1981. Untraceable electronic mail, return addresses, and digital pseudonyms. Comunicaciones de la ACM 24(2): 84-90; https://dl.acm.org/citation.cfm?id=358563.

10. Chaum, D. 1983. Blind signatures for untraceable payments. Avances en criptología: 199-203.

11. Chaum, D. 1985. Security without identification: transaction systems to make Big Brother obsolete. Comunicaciones de la ACM 28(10): 1030-1044; https://dl.acm.org/citation.cfm?id=4373.

12. Chaum, D., et al. 1988. Untraceable electronic cash. Avances en criptología: 319-327; https://dl.acm.org/citation.cfm?id=88969.

13. Dai, W. 1998; http://www.weidai.com/bmoney.txt.

14. Douceur, J. R. 2002. The Sybil attack; https://dl.acm.org/citation.cfm?id=687813.

15. Dwork, C., Naor, M. 1992. Pricing via processing or combatting junk mail; https://dl.acm.org/citation.cfm?id=705669.

16. Felten, E. 2017. Contratos inteligentes: ¿ni inteligentes ni contratos? Freedom to Tinker; https://freedom-to-tinker.com/2017/02/20/smart-contracts-neither-smart-not-contracts/.

17. Franklin, M. K., Malkhi, D. 1997. Auditable metering and lightweight security; http://www.hashcash.org/papers/auditable-metering.pdf.

18. Gabber, E., et al. 1998. Curbing Junk E-Mail via Secure Classiffication. http://www.hashcash.org/papers/secure-classification.pdf.

19. Garay, J. A., et al. 2015. El protocolo backbone de bitcoin: análisis y aplicaciones. Advances in Cryptology: 281-310; https://eprint.iacr.org/2014/765.pdf.

20. Goldberg, I. 2000. A pseudonymous communications infrastructure for the Internet. Tesis doctoral, Universidad de California Berkeley; http://moria.freehaven.net/anonbib/cache/ian-thesis.pdf.

21. Grigg, I. 2005. Triple entry accounting; http://iang.org/papers/triple_entry.html.

22. Haber, S., Stornetta, W. S. 1991. How to timestamp a digital document. Journal of Cryptology 3(2): 99-111; https://link.springer.com/chapter/10.1007/3-540-38424-3_32.

23. Haber, S., Stornetta, W. S. 1997. Secure names for bit-strings. En Proceedings of the^4th ACM Conference on Computer and Communications Security: 28-35; http://dl.acm.org/citation.cfm?id=266430.

24. Jakobsson, M., Juels, A. 1999. Proofs of work and bread pudding protocols; http://www.hashcash.org/papers/bread-pudding.pdf.

25. Juels, A., Brainard, J. 1999. Client puzzles: a cryptographic countermeasure against connection completion attacks. Actas de Networks and Distributed Security Systems: 151-165; https://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/juels.pdf.

26. Just, M. 1998. Some timestamping protocol failures; http://www.isoc.org/isoc/conferences/ndss/98/just.pdf.

27. Lamport, L., et al. 1982. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems 4(3): 382-401; https://dl.acm.org/citation.cfm?id=357176.

28. Lamport, L. 1989. El parlamento a tiempo parcial. Digital Equipment Corporation; https://computerarchive.org/files/mirror/www.bitsavers.org/pdf/dec/tech_reports/SRC-RR-49.pdf.

29. Lamport, L. 2001. Paxos made simple; http://lamport.azurewebsites.net/pubs/paxos-simple.pdf.

30. Laurie, B. 2014. Certificate Transparency. acmqueue 12(8); https://queue.acm.org/detail.cfm?id=2668154.

31. Levy, K. E. C. 2017. Book-smart, not street-smart: blockchain-based smart contracts and the social workings of law. Engaging Science, Technology, and Society 3: 1-15; http://estsjournal.org/article/view/107.

32. Melara, M., et al. 2015. CONIKS: llevando la transparencia de las claves a los usuarios finales. Actas del^24º Simposio de Seguridad Usenix; https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf.

33. Merkle, R. C. 1980. Protocols for public key cryptosystems. Simposio del IEEE sobre seguridad y privacidad; http://www.merkle.com/papers/Protocols.pdf.

34. Nakamoto, S. 2008. Bitcoin: a peer-to-peer electronic cash system; https://bitcoin.org/bitcoin.pdf.

35. Nakamoto, S. 2008. Re: Bitcoin P2P e-cash paper; http://satoshi.nakamotoinstitute.org/emails/cryptography/11/.

36. Narayanan, A., et al. 2016. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press; http://bitcoinbook.cs.princeton.edu/.

37. Pass, R., et al. 2017. Análisis del protocolo blockchain en redes asíncronas. Conferencia Internacional Anual sobre Teoría y Aplicaciones de Técnicas Criptográficas; https://link.springer.com/chapter/10.1007/978-3-319-56614-6_22.

38. Pinkas, B., Sander, T. 2002. Securing passwords against dictionary attacks. Proceedings of the Ninth ACM Conference on Computer and Communications Security: 161-170; https://dl.acm.org/citation.cfm?id=586133.

39. Reuters. 2014. Mind your wallet: why the underworld loves bitcoin; http://www.cnbc.com/2014/03/14/mind-your-wallet-why-the-underworld-loves-bitcoin.html.

40. Sirer, E. G. 2016. Bitcoin garantiza una consistencia fuerte, no eventual. Hacking, Distributed; http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/.

41. Szabo, N. 1994. Smart contracts; http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html.

42. Szabo, N. 2008. Bit gold. Unenumerated; https://unenumerated.blogspot.com/2005/12/bit-gold.html.

43. Wattenhofer, R. 2016. La ciencia de la cadena de bloques. Inverted Forest Publishing.

44. Rivest, R. L., Shamir, A. 1996. PayWord y MicroMint: Two simple micropayment schemes. Taller internacional sobre protocolos de seguridad.

Arvind Narayanan es profesor adjunto de informática en Princeton. Dirige el Princeton Web Transparency and Accountability Project (Proyecto de Transparencia y Responsabilidad Web de Princeton) para descubrir cómo las empresas recopilan y utilizan nuestra información personal. Narayanan también dirige un equipo de investigación que estudia la seguridad, el anonimato y la estabilidad de las criptomonedas, así como nuevas aplicaciones de las cadenas de bloques. Es coautor de un curso en línea masivo y abierto y de un libro de texto sobre bitcoin y las tecnologías de las criptomonedas. Su investigación doctoral mostró los límites fundamentales de la desidentificación, por lo que recibió el Premio a las Tecnologías de Mejora de la Privacidad. Narayanan es profesor afiliado del Centro de Política de Tecnologías de la Información de Princeton y académico afiliado del Centro de Internet y Sociedad de la Facultad de Derecho de Stanford. Puede seguirle en Twitter en @random_walker.

Jeremy Clark es profesor adjunto en el Instituto Concordia de Ingeniería de Sistemas de Información. Obtuvo su doctorado en la Universidad de Waterloo, donde su tesis, galardonada con la medalla de oro, versó sobre el diseño y despliegue de sistemas de votación seguros, entre ellos Scantegrity, el primer sistema verificable criptográficamente utilizado en unas elecciones del sector público. Escribió uno de los primeros artículos académicos sobre bitcoin, llevó a cabo varios proyectos de investigación en este campo y colaboró en el primer libro de texto. Más allá de la investigación, ha trabajado con varios municipios en tecnología de votación y ha testificado ante el Senado canadiense sobre bitcoin. Puede seguirle en Twitter en @PulpSpy.

Artículo originalmente publicado el 29 agosto 2017 en ACMqueue.