Una ficha de Hashcash con propietario y de por vida

Este artículo se disfruta mejor si el lector ya tiene algún conocimiento del cifrado de clave pública y , funciones de hash seguras (criptográficas, unidireccionales) y familiaridad con el sistema Hashcash o prueba de -Trabajo basado en funciones hash seguras. Vale la pena explorar estos temas por sí mismos y no son demasiado difíciles de entender desde el punto de vista de ser un usuario de estas funciones (que es lo que soy, no soy un criptógrafo ni un experto en seguridad, ni siquiera particularmente fuerte en nada matemático) relacionado). En cualquier caso, repasaré brevemente estos temas mientras explico cómo podemos crear tokens Hashcash transferibles que también tengan “genes de envejecimiento”.

En el sistema Hashcash original y en la acuñación de encabezados de bloques de Bitcoin, el desafío principal es, dado un “número” de entrada (un montón de bits cero y uno de cualquier tamaño, en realidad), ejecutarlo a través de un función hash segura unidireccional como SHA256, y obtener suficientes bits “cero” como prefijo del número de salida, o “hash” del número de entrada original. La clave aquí es que cuando alimenta una pieza lógica estándar como SHA256 con un montón de bits, no tiene forma de determinar de antemano cuál será la salida; es, desde su punto de vista, completamente aleatorio.

El “valor” y la “rareza” de los bloques de Bitcoin o de los tokens Hashcash viene dado por el número de bits puestos a cero en una fila que obtiene cuando lo alimenta con algunos datos de entrada. En el caso de Bitcoin, usted introduce cosas del bloque anterior y del bloque actual en la función hash, que es lo que le da a la “cadena” en el nombre de “blockchain”. En el caso de Hashcash, que era un sistema para encarecer el spam de correo electrónico, se le da el mensaje de correo electrónico. Tienes un 50% de posibilidades de obtener un prefijo con un cero, un 25% de posibilidades de conseguir dos ceros, un 12,5% de posibilidades de conseguir tres ceros, y así sucesivamente. Para extraer un bloque de bitcoins, debes obtener muchos ceros, mucho más de 20 seguidos.

Pero si le da a la función hash datos estáticos como un mensaje de correo electrónico o un bloque de bitcoin anterior como entrada, ¿no siempre le devolverá el mismo resultado? Si. Es por eso que parte de la entrada a la función hash es siempre un número aleatorio, p. Ej. un número de 64 bits. Entonces, lo que están haciendo los “mineros” y los remitentes de correo electrónico habilitados para Hashcash es recorrer la función hash, dando la misma entrada que quieren validar más un número aleatorio. Lo hacen millones de veces, hasta que obtienen un hash en la salida que tiene el número requerido de ceros. Esto es lo que le da “rareza” a los bloques Hashcash y Bitcoin.

Ahora, en Bitcoin, una referencia al “propietario” de las recompensas de un bloque que ha sido extraído se registra en el propio bloque. Hay una clave pública escrita en algún lugar del bloque, y el minero (el generador del bloque) la coloca allí. Esa clave pública tiene una clave privada vinculada matemáticamente a ella que solo conoce la persona que resolvió el desafío del bloque. Esta clave privada se puede usar más tarde para firmar criptográficamente un comando (una “transacción”) a la red Bitcoin diciéndole que transfiera la propiedad de la recompensa en bloque a otra clave pública que pertenezca a otra persona.

El bloque extraído permanece para siempre en la cadena de bloques de Bitcoin-the-network. La recompensa está implícitamente fechada por el número de bloque (el orden en la cadena), que es lo que usan las monedas habilitadas para estadías, como Freicoin, para depreciar la recompensa de ese bloque.

En un sistema de cadena de bloques, toda la “extracción” o acuñación de recompensas debe realizarse en línea. La recompensa por prueba de trabajo, como en un sistema de hashcash transferible, solo se puede realizar cuando se emite un bloque; ya sea como recompensa del bloque o como transacciones especiales de “acuñación” que se envían a los bloques y se aceptan (estos no existen en Bitcoin, pero sería trivial de agregar). Por lo tanto, la acuñación de tokens Hashcash en Bitcoin no está descentralizada, sino centralizada por la propia red; generar valor requiere que se encuentre una transacción o un bloque, por lo que está limitado por el límite de Transacciones por segundo (TPS) de la red. La acuñación de tokens Hashcash en el sistema Hashcash original está descentralizada, pero el sistema Hashcash original no permite que se transfieran.

Queremos que el sistema sea escalable, por lo que no queremos que la acuñación de tokens genere un evento de red en absoluto, si podemos evitarlo. Pero queremos que estos tokens estén vinculados a un propietario, que es la base de la transferibilidad más adelante (a medida que abordamos el problema del doble gasto), así como vinculados a una fecha para que podamos “demorarlos”.

Para hacer esto, la base de nuestra entrada a la función hash segura es la siguiente: una clave pública, una fecha (UTC) y el número aleatorio obligatorio . Este hash se realiza completamente en privado, utilizando datos completamente privados como entrada. Una vez generado, el valor del token es el número de bits cero iniciales en el resultado. Pertenece a quien tiene la clave privada que puede firmar la clave pública que forma parte de su entrada. Y su valor se deprecia en alguna fórmula fija, constante y definida por el protocolo que utiliza únicamente la fecha codificada en el token como entrada. Esta acuñación de tokens Hashcash que tienen el potencial de ser transferibles (ya que tienen un propietario codificado en ellos, pero aún tenemos que vincularlos a una red y protocolo reales) y la demora (habilitada para la deflación) ocurre en “TPS infinito”, completamente fuera de línea. El token solo necesita ser conocido por alguna red de registro de transacciones cuando se transfiere por primera vez. ¡Bien!

Eso fue simple. Es un concepto simple, pero hacer que funcione en un sistema real es toda una industria de gusanos enlatados por abrir. ¡Pero al menos he publicado el concepto central y está fuera de mi cabeza! No lo he visto mencionado en ningún otro lugar, aunque parece un poco obvio, si realmente está buscando crear un sistema de criptomonedas democrático y escalable, lo cual, para sorpresa de nadie, tampoco es algo que haya visto.

En los siguientes artículos probablemente comenzaré a describir cómo es la red peer-to-peer (lo que realmente resuelve el problema central del doble gasto) y qué almacenan los nodos en ellos y por qué.

Anexo (“¡Ups, lo olvidé!”): purga de tokens Hashcash

En este punto, tenemos suficiente para ver por qué está bien que el sistema olvide los tokens que se han depreciado con el tiempo hasta un valor cero, incluso si aún no sabemos qué es una transacción, y la red que registra las transacciones, parece.

Nuestras fichas Hashcash están fechadas. Dado que la función de depreciación es constante, hay una fecha en el futuro en la que se garantiza que el token no tiene valor. Tenga en cuenta que el token Hashcash no se puede disociar de la fecha que se utilizó para acuñarlo. Por lo tanto, toda la red solo sabe cuándo un token Hashcash y todo el historial de transacciones asociado con él pueden simplemente eliminarse del almacenamiento. No es posible que el token se reintroduzca más adelante, ya que la fecha de nuestros tokens Hashcash no se puede adelantar; esto está garantizado por el uso de una función hash segura y unidireccional para evaluar el valor del token.

Esta eliminación completa de un token puede llevar años. En Freicoin, a una tasa de demora del 5% (más o menos) por año, las “monedas” tardan 20 (o fueron 30? O 15? Algo así …) años para volverse (casi) cero en valor. Puede ser un período de tiempo más corto o más largo, siempre que sea una constante incorporada al protocolo. Pero el punto es que el sistema puede funcionar a largo plazo, “para siempre”, ya que el almacenamiento de transacciones se vacía constantemente sin necesidad de coordinación alguna, salvo que cada nodo tenga una idea de la hora que es. No es necesario hacer suposiciones sobre la evolución de la tecnología de los discos duros o guerras santas sobre los límites de tamaño de los bloques (pero seguramente habrá otros argumentos).