109 / 736RPOW

Reusable Proofs of Work

RPOW: el experimento de Finney para transferir pruebas de trabajo

Un ordenador realiza un trabajo y produce una ficha digital. ¿Cómo entregársela a otra persona sin que quien la envía conserve una copia igual de válida? En 2004, Hal Finney puso en marcha una respuesta: invalidar la ficha antigua y sustituirla por otra al transferirla. RPOW fue un experimento importante en el camino hacia el dinero digital, aunque seguía dependiendo de un servidor especial y de la confianza en sus protecciones técnicas.

Reusable Proofs of Work, o RPOW, fue un sistema experimental de Hal Finney que convertía pruebas de trabajo computacional Hashcash en fichas digitales transferibles. Cada ficha solo podía canjearse una vez en el servidor indicado, el servicio que atendía las peticiones de los usuarios, pero el receptor obtenía otra con el mismo valor de trabajo. Una tarjeta IBM 4758 y la comprobación remota del programa en ejecución debían proteger los canjes. No era una red descentralizada ni bitcoin.

El 15 de agosto de 2004, Hal Finney invitó a los participantes de una lista de correo sobre criptografía a probar su nuevo experimento. Partía de Hashcash, de Adam Back: el ordenador ensaya distintas entradas hasta encontrar un resultado que cumpla una condición. La búsqueda consume tiempo de cálculo; comprobar el resultado es rápido. A esa prueba la llamamos Proof of Work, prueba de trabajo. Para combatir el correo basura puede servir como un sello postal computacional. Finney quería saber si esa prueba podía pasar de una persona a otra, en lugar de agotar su utilidad tras un solo uso. De ahí el nombre RPOW: pruebas de trabajo reutilizables. [1] [2] [4]

Imaginemos que Ana tiene una ficha digital válida y se la envía a Pedro. Si solo le ha entregado un archivo, puede haberse guardado una copia. Pedro presenta la ficha al servidor RPOW y pide cambiarla. El servidor comprueba que no se haya usado, la marca como consumida y firma otra nueva que ha preparado el programa de Pedro. La copia de la ficha antigua que conserva Ana ya no sirve para otro canje. Pedro puede enviar después la nueva ficha a Eva, que repetirá el proceso. Lo que se reutiliza es el valor transferido, no un mismo archivo que siga siendo válido indefinidamente. Hasta que el receptor termina el canje, el remitente todavía podría gastar antes la ficha original. [2] [11]

La entrada podía ser un Hashcash recién calculado o una ficha RPOW aún sin usar. La salida era una ficha nueva con una firma digital RSA: una confirmación del servidor verificable mediante matemáticas. RSA es un método para calcular esa firma: se crea con una clave de firma secreta y se comprueba con la clave pública correspondiente. Son datos numéricos verificables, no una imagen de una firma manuscrita. La firma permitía comprobar el origen de la ficha, pero no revelaba por sí sola si ya se había canjeado. Para eso existía el registro de entradas utilizadas. Los siguientes traspasos no exigían repetir la búsqueda costosa de Hashcash: se obtenía una nueva firma a cambio de invalidar la prueba anterior. No se reciclaba electricidad ni se podían multiplicar gratuitamente los derechos sobre un trabajo ya realizado. [2]

El valor expresaba un nivel de dificultad computacional, no un precio en coronas checas o dólares. El Hashcash de aquella época usaba SHA-1, una función que produce una huella numérica breve de unos datos, y buscaba una huella con cierto número de bits iniciales a cero. Un bit es un dígito binario. Cada cero adicional exigido duplica aproximadamente el número medio de intentos. Así, una ficha de nivel 21 representaba el mismo trabajo esperado que dos de nivel 20 y podía dividirse en ellas. Al combinar o dividir fichas, debía conservarse la suma de ese valor computacional. Eso no establecía un tipo de cambio fijo ni garantizaba poder adquisitivo: los ordenadores más rápidos podían producir el mismo tipo de ficha a menor coste. [2] [10]

Double spend significa gastar dos veces el mismo valor. Para impedirlo, RPOW necesitaba una lista de pruebas ya canjeadas. La base de datos completa no estaba dentro de la tarjeta protegida: la almacenaba el ordenador anfitrión. La tarjeta conservaba una huella de su estado y verificaba pruebas criptográficas al consultar los datos. Utilizaba el principio de Merkle Tree, un árbol de huellas que permite comprobar una parte de los datos frente a una única huella común. El objetivo era detectar tanto cambios en los registros como la restauración de una base antigua que todavía no incluyera una ficha recién gastada. Sin esa protección, el operador podría convertir la misma entrada en fichas nuevas repetidamente. [3]

El servidor realizaba las operaciones delicadas dentro de una IBM 4758, una tarjeta informática autónoma instalada en un ordenador corriente. Debía proteger las claves de firma y el estado sensible incluso frente al propietario de ese ordenador. Si detectaba una intervención física, podía borrar los secretos. El ordenador anfitrión transportaba mensajes y almacenaba la base de datos, pero el diseño no lo consideraba fiable. Esa era la idea de Finney: poner en marcha el servidor no debía permitir al operador crear fichas a voluntad. La protección dependía, no obstante, del funcionamiento correcto del hardware, del programa y de la custodia de las claves; no era una promesa incondicional de invulnerabilidad. [3] [9]

Publicar el código fuente no basta: el operador podría mostrar un programa y ejecutar otro. RPOW recurría a remote attestation, la certificación remota de la configuración. La tarjeta proporcionaba información firmada sobre el programa que estaba ejecutando. Cualquier interesado podía compilar el código publicado con las herramientas correspondientes y comparar la huella de la imagen resultante con la declarada por la tarjeta. No se comparaba simplemente el texto del código fuente. La confianza en las firmas seguía una cadena de certificados hasta una clave de IBM. Esto ayudaba a comprobar qué programa ejecutaba el servidor, pero no demostraba que careciera de errores ni que el fabricante o sus procedimientos de certificación no pudieran fallar. [3] [9]

RPOW recuerda a eCash porque intercambia fichas digitales, pero el funcionamiento original descrito no protegía la privacidad mediante firmas ciegas. Finney confiaba en una conexión cifrada hasta la tarjeta protegida y en un programa verificable que no conservaba los vínculos entre fichas emitidas y recibidas. El ordenador anfitrión no debía ver su contenido en claro. Aun así, podía observar la dirección de red del cliente, el momento de la comunicación y su tamaño. Presentar de nuevo la misma ficha también permitía relacionar algunos acontecimientos. La documentación conservada ya describe compatibilidad con Tor, una red que hace pasar la conexión por varios intermediarios y oculta al servidor la dirección de red original del usuario. En cambio, presenta las firmas ciegas como una posible incorporación posterior. No deben confundirse con una función del sistema descrito entonces. [8] [10]

RPOW no se quedó en una propuesta sobre papel: contaba con un servidor operativo y un programa cliente disponible. Sin embargo, Finney advirtió desde el principio que era una versión experimental temprana. Un cambio necesario en el programa del servidor podía invalidar fichas emitidas anteriormente. El proyecto reservaba las fichas para usos personales, experimentales y no comerciales, no para dinero de valor garantizado. Tampoco una tarjeta protegida podía obligar al operador a mantener encendido el servidor. El proyecto original terminó; sus páginas y código conservados son material histórico. La descripción de aquel SHA-1, de RSA y del hardware no es una recomendación para construir hoy un servicio de pagos. [1] [4] [5] [7]

Finney quería demostrar en la práctica parte de la idea de Bit Gold de Nick Szabo: crear un objeto digital podía ser costoso y, después, ese objeto podía transferirse. La documentación de RPOW también preveía varios servidores cooperando; sería simplista reducir todo el diseño a un único ordenador para siempre. Sin embargo, cada ficha indicaba el servidor en el que debía canjearse. Añadir máquinas no eliminaba por sí solo esa dependencia. Bitcoin tomó otro camino: los nodos independientes, ordenadores con software de verificación, comprueban unas reglas comunes y un historial público. Los mineros compiten por añadir nuevos bloques válidos: conjuntos de transacciones enlazados con el registro anterior. RPOW ayuda así a entender lo que Proof of Work no resuelve por sí solo: cómo reconocer un orden válido de transferencias y en quién hay que confiar para hacerlo. [1] [6] [11]

Para obtener la imagen más completa, lee esta entrada junto con Hal Finney, Adam Back, Hashcash, Nick Szabo, Bit Gold, Proof of Work. También enlazan con esta entrada b-money, Bit Gold, Hal Finney.

DOC · 001Hal Finney — RPOW overviewFuente primaria DOC · 002Hal Finney — RPOW theoryFuente primaria DOC · 003Hal Finney — RPOW security modelFuente primaria DOC · 004Hal Finney — RPOW launch announcementFuente primaria DOC · 005Nakamoto Institute — archived RPOW sourceDocumentación DOC · 006Bitcoin whitepaperFuente primaria DOC · 007Hal Finney — What is RPOW?Fuente primaria DOC · 008Hal Finney — RPOW privacy without blindingFuente primaria DOC · 009Hal Finney — IBM 4758 securityFuente primaria DOC · 010Hal Finney — RPOW frequently asked questionsFuente primaria DOC · 011Hal Finney — The RPOW worldFuente primaria
Revisado: Fuentes primero · No es asesoramiento financiero