Nick Szabo escribió trabajos tempranos sobre Smart Contracts, condiciones contractuales ejecutadas mediante tecnología, y propuso Bit Gold. Relacionó cuestiones de confianza, propiedad y trabajo computacional. Sus propuestas pertenecen a la historia del dinero digital; no son otro nombre para Bitcoin.
En una compra queremos que el vendedor cobre y el cliente reciba lo prometido. Comprobar ambos lados lleva tiempo y puede requerir un intermediario. En Smart Contracts, de 1994, Nick Szabo exploró qué condiciones contractuales podía ejecutar un protocolo informático: un procedimiento establecido para intercambiar mensajes y realizar acciones. Buscaba reducir el fraude y el coste de cumplir acuerdos. La idea no se limita a blockchain: consiste en utilizar tecnología para cumplir compromisos concretos. Llamar inteligente a un programa no significa que comprenda todas las intenciones humanas. [1]
En su trabajo de 1997, Szabo conecta los protocolos contractuales con la interfaz de usuario. Su ejemplo sencillo es una máquina expendedora: vemos el precio, introducimos monedas y recibimos el producto. La interfaz comunica el intercambio y el mecanismo lo ejecuta. En una aplicación compleja, lo que sugiere la pantalla puede diferir de lo que hace el código. No basta con ejecutar correctamente el programa. Las condiciones deben ser comprensibles, hay que considerar el tiempo y reconocer qué situaciones se han podido describir en el algoritmo. La automatización debería ayudar a decidir, sin ocultar consecuencias. [2]
Un archivo digital se copia fácilmente. Szabo se preguntó si la escasez digital podía apoyarse en una producción de coste demostrable. En Bit Gold, un ordenador resuelve un problema y genera una prueba de trabajo, Proof of Work. Servicios de sellado temporal aportan información sobre el momento del resultado, mientras un registro de propiedad distribuido reparte los registros entre varios operadores. El resultado anterior proporciona el reto siguiente. Juntos, estos componentes permitirían crear, transferir y verificar piezas digitales. Encadenar cálculos no constituye por sí solo el consenso completo de Bitcoin, las reglas con que la red acuerda su historia. [3]
Imaginemos que Ana envía a Tomás un archivo con el resultado del cálculo y conserva una copia. ¿Quién posee ahora esa pieza de Bit Gold? Ambos tienen los bits, así que la posesión del archivo no prueba propiedad exclusiva. La propuesta recurre a una cadena de transferencias de titularidad firmadas digitalmente y anotadas en un registro. Tomás debe comprobar esa historia, el trabajo computacional y el sello temporal. La prueba de trabajo informa sobre la producción; el registro aborda la propiedad. Ninguna tarea desaparece porque los datos hayan sido costosos de crear. [3]
Un resultado de igual longitud no exige el mismo esfuerzo a todos. Alguien puede disponer de un ordenador más eficiente, y nuevos equipos pueden abaratar un trabajo antes costoso. Bit Gold considera por ello la época de producción y las diferencias entre máquinas. Sus piezas no son automáticamente fungibles, es decir, intercambiables como unidades equivalentes por tener la misma longitud. La propuesta contempla comerciantes que agrupan piezas de valores distintos en lotes de valor aproximadamente igual. Esto añade reglas y valoración. Una producción costosa no proporciona por sí sola todo lo que esperamos del dinero. [3]
El texto menciona RPOW, de Hal Finney, como un experimento relacionado que sí se implementó. El nombre significa Reusable Proofs of Work: pruebas de trabajo reutilizables. Son importantes un servidor protegido y la atestación remota, un método para comprobar qué programa ejecuta un dispositivo distante. Esto ayuda a preguntar qué podemos verificar por nuestra cuenta y dónde dependemos de supuestos sobre el hardware o su operador. Bit Gold, RPOW y BTC no forman un solo sistema. Comparten temas, pero difieren en los registros, las transferencias y la concentración de confianza. [3]
Ya en 1994, Szabo describía un coche financiado cuyo acceso a las llaves podría depender de las cuotas pagadas. Parece una regla sencilla hasta imaginar el coche circulando por una autopista: desactivarlo entonces sería peligroso. Por eso el diseño contempla excepciones de funcionamiento seguro y la retirada de restricciones tras pagar el préstamo. El ejemplo resume su enfoque: no basta con imponer una condición; también importan el momento, las consecuencias y cómo termina la restricción. Una posibilidad técnica aún no es un producto terminado y seguro. [1]
El whitepaper que explica el diseño de Bitcoin apareció bajo el nombre Satoshi Nakamoto. Los temas de Szabo tienen conexiones intelectuales con él, pero las semejanzas no demuestran autoría. Saber de dinero digital o escribir sobre confianza no prueba que alguien usara ese seudónimo. Resulta más útil examinar qué propone cada texto: cómo nacen las unidades, quién registra las transferencias y qué debe verificar quien recibe. Así podemos valorar la aportación de Szabo sin construir la historia sobre una suposición no demostrada. [4]
Para obtener la imagen más completa, lee esta entrada junto con Wei Dai, David Chaum, Bit Gold. También enlazan con esta entrada b-money, Bit Gold, Reusable Proofs of Work, Wei Dai.