Criptomonedas

Bitcoin: un sistema de dinero electrónico entre iguales (P2P).

 

Resumen 

 

Una versión de dinero electrónico que se basa sólo en principios P2P1 permitiría efectuar pagos en Internet de forma directa, entre un usuario y otro, sin tener que pasar a través de una entidad financiera. Las firmas digitales2 representan parte de la solución, pero los beneficios más importantes se pierden cuando tiene que intervenir un tercero de confianza para evitar que se lleve a cabo un gasto doble3. En este documento se propone el uso de una red P2P como solución al problema del gasto doble. Mediante un sello de tiempo4, la red marca cada transacción5 al codificarla en un hash6 e introducirla en una cadena7 en desarrollo que se basa en estos hashes a modo de comprobante de trabajo8, formando así un registro que no se puede modificar a menos que se rehaga el comprobante de trabajo. La extensión de la cadena no sólo constituye una prueba que describe la secuencia de eventos ocurridos, sino que al mismo tiempo demuestra que proviene de la mayor reserva de recursos de la CPU9. Se podrá generar una cadena ilimitada que se mantenga con ventaja ante los ataques siempre que los nodos que no tienen intención de atacar a la red controlen la mayor parte de recursos de la CPU. La red en sí requiere una estructura mínima: los mensajes se difunden a través del esfuerzo colectivo; los nodos pueden unirse a la red o abandonarla en cualquier momento, rigiéndose siempre por la cadena de comprobantes de trabajo más extensa, que les mostrará lo que ha ocurrido mientras no estaban.

 

 

Introducción

 

El comercio en Internet depende casi de forma exclusiva de las entidades financieras, que actúan como terceros de confianza en el procesamiento de los pagos electrónicos. Aunque para la mayoría de transacciones resulte lo bastante efectivo, este sistema todavía carga consigo las debilidades inherentes del modelo de confianza en el que está basado. Las transacciones irreversibles no son del todo posibles, ya que las entidades financieras deben mediar para resolver las disputas. Esta intervención incrementa los costes de transacción, limitando así la cantidad mínima que resulta viable transferir y suprimiendo la opción de enviar pequeñas cantidades de dinero de forma puntual. Además, la imposibilidad de exigir pagos irreversibles a cambio de servicios que no se pueden devolver representa un coste aún mayor. La posibilidad de retroceder un pago hace que se extienda la necesidad de establecer una relación de confianza. Los comerciantes deben ser precavidos, de manera que exigen a sus clientes más información de la que hace falta. Resulta inevitable asumir cierto porcentaje de operaciones fraudulentas. Se pueden evitar estos costes, así como la inseguridad en los pagos, cuando se utiliza dinero físico en persona. Sin embargo, no existe ningún mecanismo que permita hacer pagos a través de otro canal de comunicación a menos que intervenga un tercero de confianza.

 

Se requiere un sistema de pago electrónico, basado en hechos criptográficos10 y no en la confianza, que permita que dos individuos dispuestos a transferirse dinero realicen la transacción directamente sin precisar a un tercero de confianza. Las transacciones que no se pueden retroceder de ninguna manera a nivel computacional favorecerían a los vendedores ante posibles casos de estafa. Además, con el fin de proteger a los compradores, se podrían implementar con facilidad los mecanismos de garantía bloqueada11 habituales. En este documento, se propone una solución al problema del doble gasto, que consiste en usar un servidor de sellado de tiempo12 de tipo P2P para generar un registro computacional del orden cronológico de las transacciones. El sistema es seguro siempre que los nodos honrados controlen en conjunto un mayor porcentaje de los recursos de la CPU, manteniéndose con ventaja ante cualquier otro grupo de nodos que coopere en la red con intención de atacarla.

 

 

 

 

Transacciones

Definimos una moneda electrónica como la cadena de firmas digitales que la constituyen. Cada vez que un propietario transfiere una moneda a un nuevo poseedor, se firma digitalmente tanto el hash de la transacción previa como la clave pública del siguiente dueño. Estas firmas se añaden al final de la moneda correspondiente, de manera que el beneficiario de un pago puede comprobarlas para verificar la cadena de propiedad de dicha moneda.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Resulta un problema evidente el hecho de que el beneficiario del cobro no sea capaz de comprobar si alguno de los propietarios ha realizado un doble gasto. Una solución habitual consiste en incorporar una autoridad central de confianza (una ceca o casa de monedas) que verifica cada transacción para comprobar que ningún fondo se haya gastado más de una vez. Tras cada transacción, la moneda debe volver a la ceca, que se encargará de emitir una nueva moneda. Con este sistema, sólo se puede confiar en las monedas emitidas directamente por la ceca para estar seguro de que no se ha producido un gasto doble. No obstante, esta solución presenta el inconveniente de que el destino del sistema monetario al completo depende de la entidad que controla la casa de monedas, ya que cada transacción tiene que pasar a través de ésta, como si se tratara de un banco.

 

Hace falta un sistema que permita al beneficiario de una transacción comprobar que los propietarios anteriores de ese dinero no han firmado ninguna transacción previa. Para este propósito, la primera operación es la que tiene valor, de manera que no se toma en cuenta ningún intento posterior para hacer un gasto doble. Sólo es posible verificar la ausencia de una transacción si se está al tanto de todas las operaciones. En el sistema de la casa de monedas, esta autoridad está al corriente de todas las transacciones y decide cuál se efectúa antes. Para poder conseguir esto sin la necesidad de un intermediario de confianza, las transacciones deben ser públicas [1]. Por tanto, los participantes han de acordar un sistema que les permita acceder a un único historial que refleje el orden en el que se recibieron las transferencias. El beneficiario requiere una prueba que le demuestre que, en el momento en que se ejecuta la transacción, la mayor parte de nodos de la red coincide en que se trata de la primera petición.

 

 

Servidor de sellado de tiempo

La solución que se propone comienza con un servidor de sellado de tiempo. Este tipo de sistemas tiene la función de asignar un sello cronológico al hash de cada bloque de elementos y publicar este hash para que la información sea de fácil acceso, como si se tratara de un periódico o de un artículo de Usenet13 [2-5]. El sello de tiempo demuestra que la información existía en ese momento, como es evidente, ya que de lo contrario no podría formar parte del hash. Cada sello de tiempo contiene en su hash el sello cronológico previo, formando así una secuencia en cadena en la que cada sello refuerza los anteriores.

 

 

 

 

 

 

 

 

 

Comprobante de trabajo

 

Para implementar un servidor de sellado de tiempo en una red P2P, más que artículos de periódico o de Usenet, hace falta un sistema de comprobantes de trabajo similar a Hashcash de Adam Back [6]. El comprobante de trabajo implica la búsqueda de un valor que al ser codificado en un hash, como puede ser ‘SHA-256′, produce un hash que comienza con un número determinado de bits a cero. El promedio del trabajo exigido es exponencial en el número de bits a cero requerido, y se puede comprobar al ejecutar un solo hash.

 

En nuestra red de sellado de tiempo, implementamos el comprobante de trabajo al ir añadiendo un número de un solo uso al bloque (nonce14), hasta que se halla el valor que proporciona el número de bits a cero requerido por el hash. Una vez que se destinan los recursos de la CPU a resolver el comprobante de trabajo, el bloque no se puede modificar a menos de que se repita la operación. A medida que se van enlazando nuevos bloques a la cadena, el trabajo que se requiere para cambiar un bloque implica rehacer también todos los bloques posteriores.

 

 

 

 

 

 

 

 

 

 

 

 

El comprobante de trabajo también sirve para resolver el problema que supone determinar la representación mayoritaria en la toma de decisiones. Si el recuento se basara en un sistema que atribuye un voto a cada IP, toda persona con conocimientos para asignar múltiples direcciones IP podría manipular el resultado. El comprobante de trabajo asigna un voto a cada CPU. La voluntad de la mayoría está representada en la cadena de mayor extensión, que contiene el esfuerzo más grande de comprobantes de trabajo. Si la mayor parte de recursos de la CPU se encuentra controlada por nodos honrados, la cadena honrada crecerá más rápido que las demás y superará al resto de cadenas. Para modificar un bloque antiguo, el transgresor se vería obligado a rehacer el comprobante de trabajo del bloque en cuestión y, también, de todos los bloques posteriores. Por otro lado, tendría que alcanzar a los nodos honrados y superar su trabajo. Más adelante, demostraremos que la probabilidad de que un transgresor más lento se ponga al día disminuye de forma exponencial conforme se van agregando nuevos bloques a la cadena.

 

Para compensar el aumento de la velocidad de los sistemas informáticos y el interés variable de los nodos operativos a lo largo del tiempo, la dificultad asociada al comprobante de trabajo se determina mediante un promedio flexible que atiende al número de bloques que se produce de media en el transcurso de una hora. Si se generan demasiado rápido, la dificultad aumenta.

 

 

Red

 

Los pasos necesarios para el funcionamiento correcto de la red son los siguientes:

 

1. Las nuevas transacciones se comunican a todos los nodos.

2. Cada nodo agrupa las transacciones nuevas en un bloque.

3. Los nodos se esfuerzan para resolver el complejo comprobante de trabajo sujeto a su bloque.

4. Cuando un nodo resuelve el comprobante de trabajo, difunde el bloque a todos los nodos.

5. Los nodos sólo aceptan bloques si todas las transacciones que contienen son válidas y no han sido contabilizadas con anterioridad.

6. Los nodos dan su consentimiento para cada bloque cuando comienzan a trabajar en la creación del siguiente bloque de la cadena, empleando el hash del bloque aceptado como referencia para el próximo hash.

 

 

Los nodos siempre dan por válida la cadena más larga y trabajan para continuar extendiéndola. Si dos nodos difunden diferentes versiones para el siguiente bloque de forma simultánea, el resto de nodos recibirán una de las dos versiones en primer lugar. En ese caso, seguirán trabajando sobre la primera que reciban, pero guardarán la otra rama por si llegara a ser más larga. El desempate ocurrirá cuando se resuelva un nuevo comprobante de trabajo y una de las dos ramas adquiera mayor extensión. Los nodos que se encontraban trabajando en la otra rama pasarán a ocuparse de la nueva versión.

 

No es necesario que todos los nodos estén al tanto de las nuevas transacciones. Basta con que haya suficientes nodos que las procesen para que pasen a formar parte de un nuevo bloque en poco tiempo. La divulgación de los bloques también está sujeta a la posible pérdida del mensaje. En caso de que un nodo pierda un bloque, lo solicitará cuando reciba el siguiente bloque y se percate de que se ha saltado uno.

 

 

Incentivo

 

Por convención, la primera transacción dentro de un bloque es de carácter especial, ya que genera una moneda nueva destinada al creador de dicho bloque. Esto aporta un incentivo para que los nodos continúen ofreciendo soporte a la red y, al mismo tiempo, permite en un inicio distribuir monedas con el fin de ponerlas en circulación, dado que no hay una autoridad central que las pueda emitir. La incorporación regular de una cantidad constante de monedas nuevas es análoga a los mineros de oro que invierten sus recursos para poner el oro en circulación. Este caso, los gastos representan el tiempo requerido por la CPU y el consumo eléctrico.

 

El incentivo también se puede financiar a través de las comisiones por transferencias. Cuando el valor de salida de una operación es inferior al valor de entrada, la diferencia se considera una tasa de servicio, que se añade al valor del incentivo asociado al bloque que contiene la transacción. Una vez que se introduce un número predeterminado de monedas en circulación, el incentivo puede basarse por completo en las comisiones por transferencias para no estar sujeto a ningún tipo de inflación.

 

Por otro lado, el incentivo puede ayudar a mantener la honradez entre los nodos. Si se diera el caso de que un transgresor codicioso consiguiera producir una capacidad de CPU más potente que la de los nodos honrados, tendría que escoger entre la posibilidad de usarlo para recuperar sus fondos y defraudar así a los demás o aprovechar esta capacidad para generar nuevas monedas. La opción más rentable debería de ser la que obedece las normas (unas normas que le proporcionan a este individuo más monedas que a todos los otros nodos juntos), y no la que debilita al sistema y desaprueba la validez de las riquezas de uno mismo.

 

 

Recuperación de espacio en el disco

 

Cuando la última transacción que se realiza con una moneda determinada queda alojada bajo suficientes bloques, las transacciones previas asociadas a la misma se pueden desechar con el fin de ahorrar espacio en el disco. Para facilitar esta tarea sin tener que deshacer el hash del bloque, las transacciones se codifican en hashes estructurados en un árbol de Merkle15 [7][2][5], donde sólo se incluye la raíz en el hash de dicho bloque. Los bloques anteriores se pueden compactar al recortar las ramas del árbol. De este modo, no es necesario almacenar los hashes interiores.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

El encabezado de un bloque que no contiene transacciones ocuparía unos 80 bytes. Si partimos de que cada 10 minutos se genera un bloque nuevo, aplicamos el siguiente cálculo: 80 bytes * 6 * 24 * 365 = 4,2 MB al año. Los sistemas informáticos que se comercializan a fecha de 2008 cuentan por lo general con 2 GB de memoria RAM. Por otro lado, la ley de Moore16 estipula un crecimiento actual en la capacidad de almacenamiento de 1,2 GB al año. En vista de estos datos, el espacio no debería de plantear ningún problema si se tienen que guardar las cabeceras de los bloques en la memoria.

 

 

Verificación de pago simplificada

 

Es posible verificar los pagos sin tener que ejecutar todo un nodo en la red. Sólo es necesario guardar una copia de las cabeceras de los bloques que componen la cadena de comprobantes de trabajo más larga. Esta copia se obtiene mediante consultas a los nodos de la red, que el usuario puede realizar hasta que esté convencido de que dispone de la cadena más larga. De esta forma, obtendrá la rama de Merkle que vincula la transacción con el bloque donde ha sido registrado el sello de tiempo. Aunque el usuario no lo puede comprobar directamente, la transacción está registrada en un lugar concreto de la cadena, de manera que puede comprobar si algún nodo de la red la ha aceptado. A su vez, los bloques que se añaden con posterioridad confirman que la red ha aceptado la transacción.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Con este sistema, la verificación resulta fiable siempre que los nodos honrados controlen la red. Sin embargo, es más vulnerable si la red está dominada por fuerzas transgresoras. A pesar de que los nodos de la red pueden verificar las transacciones directamente, el método simplificado puede ser falseado mediante transacciones inventadas por algún transgresor durante el espacio de tiempo que consiga dominar la red. Una posible solución para evitar este problema consistiría en recibir alertas de los nodos de la red cuando se detecte un bloque inválido. En estos casos, el software del usuario se descargaría el bloque entero, así como las transacciones sospechosas, para comprobar la incompatibilidad. Es probable que las empresas que reciben pagos con frecuencia prefieran operar sus propios nodos para una mayor seguridad independiente y una verificación más rápida.

 

 

 

 

 

Continúa 2da parte...