Autor: Satoshi Nakamoto; Traducción al chino: Li Xiaolai
Resumen: Una versión puramente peer-to-peer de un sistema de efectivo electrónico que permitirá que los pagos en línea se envíen directamente de una parte a otra sin pasar por una institución financiera. Si bien las firmas digitales ofrecen algunas soluciones, los principales beneficios de los pagos electrónicos se compensan cuando aún se necesita un tercero de confianza para evitar el doble gasto. Proponemos una solución que utiliza una red peer-to-peer para resolver el problema del doble gasto. La red peer-to-peer marcará la hora de cada transacción ingresando los datos hash de la transacción en una extensa cadena de prueba de trabajo basada en hash que es imposible de cambiar a menos que se rehaga por completo. La cadena más larga se utiliza para probar los eventos que se han presenciado y su orden, y por otro lado, para demostrar que proviene de la mayor reserva de potencia de hash de la CPU. Mientras la gran mayoría de la potencia de cómputo de la CPU esté controlada por nodos benignos, es decir, que no cooperen con aquellos que intentan atacar la red, los nodos benignos generarán la cadena más larga y superarán al atacante. La red en sí misma necesita una estructura mínima. La información se difundirá sobre la base de los mejores esfuerzos, y los nodos irán y vendrán libremente; Sin embargo, a la hora de incorporarse, siempre es necesario aceptar la cadena más larga de pruebas de trabajo como prueba de todo lo que sucedió durante el periodo en el que no estuvieron involucrados.
1. Introducción
El comercio por Internet depende casi por completo de las instituciones financieras como terceros de confianza para procesar los pagos electrónicos. Si bien el sistema es bastante bueno para la mayoría de las transacciones, todavía se ve obstaculizado por los defectos inherentes de los modelos basados en la confianza. Una transacción completamente irreversible no es posible en la práctica, ya que las instituciones financieras no pueden evitar las disputas de arbitraje. El costo del arbitraje aumenta los costos de transacción, lo que a su vez limita el tamaño de la transacción mínima posible y simplemente evita muchas transacciones de micropagos. Además de eso, hay un costo aún mayor: el sistema no puede hacer pagos irreversibles por servicios que no son reversibles. La posibilidad de una reversión ha creado una necesidad generalizada de confianza. Los comerciantes tienen que desconfiar de sus clientes, molestándolos para que proporcionen más información que no sería necesaria si no lo fuera (si se confía). Un cierto porcentaje de fraude se considera inevitable. Estos costos e incertidumbres de pago se pueden evitar cuando los pagos se realizan directamente entre personas utilizando moneda física; Sin embargo, no existe un mecanismo para que ambas partes realicen pagos a través de canales de comunicación sin que una de ellas sea de confianza.
Lo que realmente necesitamos es un sistema de pago electrónico basado en pruebas criptográficas en lugar de confianza, que permita a dos partes realizar transacciones directamente sin tener que confiar en un tercero. La transacción irreversible de la garantía de hashrate puede ayudar a los vendedores a evitar el fraude, y el mecanismo de garantía diaria para proteger a los compradores es fácil de implementar. En este artículo, propondremos una solución para el doble gasto, utilizando un servidor de marca de tiempo distribuido de igual a igual para generar pruebas basadas en hashrate que registren cada transacción en orden cronológico. El sistema es seguro, siempre y cuando los nodos honestos generalmente tengan más potencia de CPU que los atacantes que cooperan entre sí.
2. Transacciones
Definimos una moneda electrónica como una cadena de firmas digitales. Cuando un propietario da una moneda a otra persona, lo hace añadiendo la siguiente firma digital al final de la cadena de firma digital: el hash de la transacción anterior y la clave pública del nuevo propietario. El beneficiario puede verificar la propiedad de la cadena de firma digital verificando la firma.
El problema con esta ruta es que el destinatario no puede verificar que nadie haya pagado dos veces entre los propietarios anteriores. Una solución común es traer una autoridad centralizada de confianza, o "mint", y hacer que verifique si hay doble gasto en cada transacción. Después de cada transacción, la moneda debe devolverse a la Casa de la Moneda, que emite una nueva moneda. Además, sólo las monedas emitidas directamente por la Casa de la Moneda son creíbles y no han sido pagadas dos veces. El problema con esta solución es que el destino de todo el sistema monetario está ligado a la empresa que administra la casa de la moneda (como un banco), y cada transacción debe pasar por ella.
Necesitábamos una forma de que el destinatario confirmara que el propietario anterior no había firmado ninguna transacción anterior. Para nuestros propósitos, solo cuentan las transacciones más tempranas, por lo que no nos importan los intentos posteriores de doble gasto. La única forma de confirmar que una transacción no existe es estar informado de todas las transacciones. En el modelo de ceca, la ceca está al tanto de todas las transacciones y puede confirmar el orden de esas transacciones. Para poder lograr esto sin la participación de una "parte de confianza", el registro de transacciones debe declararse públicamente1, y necesitamos un sistema que permita a los participantes acordar el mismo historial de transacciones único que reciben. El beneficiario debe demostrar que, en el momento de cada transacción, la mayoría de los nodos pueden estar de acuerdo en que fue la primera en recibirse.
3. Servidor de marca de tiempo
Esta solución comienza con un servidor de marca de tiempo. Así es como funciona un servidor de marca de tiempo: marca el hash de un conjunto de registros y luego transmite el hash, como lo hace un periódico o como una publicación en Usenet.2 3 4 5. Obviamente, una marca de tiempo demuestra que los datos existían antes de ese momento, de lo contrario no se habría generado el hash. Cada marca de tiempo contiene una marca de tiempo anterior en su hash, formando así una cadena; Cada nueva marca de tiempo se agrega después de la marca de tiempo anterior.
Para implementar un servidor de marca de tiempo distribuido basado en peer-to-peer, necesitamos usar un sistema de prueba de trabajo como Hash Cash 6 de Adam Burke, en lugar de algo como una publicación de periódico o grupo de noticias. La llamada prueba de trabajo es encontrar un valor; Para que este valor sea verdadero: después de extraer un valor hash para él, por ejemplo, usando SHA-256 para calcular un valor hash, el valor hash debe comenzar con un cierto número de ceros. Cada requisito adicional de 0 aumenta exponencialmente la cantidad de trabajo, y la verificación de esta cantidad de trabajo solo requiere que se calcule un hash.
En nuestra red de marcas de tiempo, implementamos proof-of-work de la siguiente manera: seguimos agregando un nonce a un bloque hasta que se encuentra un valor que satisfaga las condiciones; La condición para esto es que el hash del bloque comience con el número especificado de 0. Una vez que el resultado del consumo de energía de cómputo de la CPU satisface la prueba de trabajo, el bloque ya no se puede cambiar a menos que se vuelva a hacer todo el trabajo anterior. Como se agregan nuevos bloques todo el tiempo, cambiar el bloque actual significa volver a pintar todos los bloques posteriores.
La prueba de trabajo también resuelve el problema de cómo decidir quién puede tomar decisiones en nombre de la mayoría. Si la llamada "mayoría" se basa en un enfoque de "una dirección IP, un voto", entonces cualquiera que pueda manejar muchas direcciones IP puede considerarse una "mayoría". La prueba de trabajo es esencialmente "una CPU, un voto". La llamada "decisión mayoritaria" está representada por la cadena más larga, porque es la cadena en la que más trabajo se ha invertido. Si la mayor parte de la potencia de cómputo de la CPU está controlada por nodos honestos, entonces la cadena honesta crecerá más rápido y será mucho más rápida que otras cadenas de la competencia. Para cambiar un bloque que ya se ha producido, un atacante tendría que volver a completar la prueba de trabajo para ese bloque y todos los bloques posteriores, y luego ponerse al día y superar el trabajo del nodo honesto. Este artículo muestra por qué la probabilidad de que un atacante retrasado se ponga al día disminuye exponencialmente a medida que aumenta el número de bloqueos.
Con el fin de hacer frente al creciente número de potencia de cálculo de hardware y al número de contribuciones de nodos que pueden cambiar con el tiempo, la dificultad de la prueba de trabajo está determinada por una media móvil del número de bloques producidos por hora en promedio. Si el bloque se genera demasiado rápido, la dificultad aumentará.
5. Red
Los pasos para ejecutar la red son los siguientes:
Todas las transacciones nuevas se transmiten a todos los nodos;
Cada nodo empaqueta las nuevas transacciones en un bloque;
Cada nodo comienza a encontrar una prueba de trabajo difícil para este bloque;
Cuando un bloque encuentra su prueba de trabajo, transmite el bloque a todos los nodos;
Muchos otros nodos aceptarán el bloqueo si y solo si se cumplen las siguientes condiciones: todas las transacciones son válidas y no han sido pagadas dos veces;
Muchos nodos indican a la red que aceptan el bloque tratando el hash del bloque aceptado como el hash antes del nuevo bloque cuando se crea el siguiente bloque.
El nodo siempre piensa que la cadena más larga es la correcta y sigue añadiéndole nuevos datos. Si dos nodos transmiten simultáneamente dos versiones diferentes de "Next Block" a la red, algunos nodos recibirán una de ellas primero, mientras que otros recibirán la otra primero. En este caso, los nodos continuarán trabajando en el bloque que recibieron primero, pero también guardarán la otra rama en caso de que se convierta en la cadena más larga. Cuando se encuentra la siguiente prueba de trabajo y una de las ramas se hace más larga, esta divergencia temporal se resuelve y los nodos que trabajan en la otra rama cambian a una cadena más larga.
Las nuevas transacciones no necesariamente tienen que transmitirse a todos los nodos. Siempre que se alcancen suficientes nodos, no pasará mucho tiempo antes de que esas transacciones se empaqueten en un bloque. Las difusiones en bloque también permiten descartar algunos mensajes. Si un nodo no recibe un bloque, el nodo se dará cuenta de que perdió el bloque anterior cuando reciba el siguiente bloque y realizará una solicitud para reemplazar el bloque que falta.
6. Incentivos
Por convención, la primera transacción de cada bloque es una transacción especial que genera una nueva moneda y pertenece al generador del bloque. Al hacerlo, recompensa a los nodos por apoyar la red y proporcionar una forma de emitir monedas en circulación, en un sistema en el que no existe una autoridad centralizada para emitir esas monedas de todos modos. Por lo tanto, agregar constantemente un cierto número de nuevas monedas a la circulación es como si los mineros de oro usaran constantemente sus recursos para agregar oro a la circulación. En nuestro sistema, los recursos que se consumen son el tiempo que la CPU está funcionando y la potencia que utilizan.
Las recompensas también pueden provenir de tarifas de transacción. Si el valor de salida de una transacción es menor que su valor de entrada, entonces la diferencia es la tarifa de transacción; La tarifa de transacción se utiliza para recompensar a los nodos por empaquetar la transacción en este bloque. Una vez que el número establecido de monedas esté en circulación, las recompensas estarán totalmente cubiertas por las tarifas de transacción y no habrá absolutamente ninguna inflación.
El mecanismo de recompensa también puede animar a los nodos a ser honestos. Si un atacante codicioso puede atrapar más potencia de CPU que todos los nodos honestos, debe tomar una decisión: ¿debería usar esa potencia de cálculo para engañar a otros robando el dinero que gastó? ¿O usar este poder de cómputo para generar nuevas monedas? Debería poder encontrar más rentable jugar según las reglas, que ahora le permiten ganar más monedas que todos los demás combinados, lo que es claramente más rentable que destruir secretamente el sistema y reducir su riqueza a la nada.
7. Recuperación de espacio en disco
Si la transacción más reciente de una moneda ocurrió antes de suficientes bloques, el historial de transacciones de gasto de la moneda antes de esa transacción se puede descartar para ahorrar espacio en disco. Para hacer esto sin romper el hash del bloque, el hash del registro de transacción se incluirá en un árbol de Merkle, y solo la raíz del árbol se incluirá en el hash del bloque. Al cortar las ramas, los bloques viejos se pueden comprimir. No es necesario guardar el hash interno.
Un encabezado de bloque sin ningún historial de transacciones es de aproximadamente 80 bytes. Suponiendo que se produce un bloque cada diez minutos, 80 bytes multiplicados por 6 por 24 por 365 equivalen a 4,2 millones por año. A partir de 2008, la mayoría de las computadoras a la venta venían con 2 GB de RAM, y la Ley de Moore predice que se agregarán 1.2 GB por año, incluso si el encabezado del bloque tiene que almacenarse en la memoria.
8. Confirmación de pago simplificada
Es posible confirmar los pagos incluso sin tener que ejecutar un nodo de red completo. Todo lo que el usuario necesita es una copia del encabezado del bloque de la cadena más larga con prueba de trabajo (puede verificar el nodo en línea para confirmar que tiene la cadena más larga) y luego obtener el nodo de rama del árbol de Merkle, que a su vez se conecta a la transacción cuando se marcó la hora del bloque. El usuario no puede verificar la transacción por sí mismo, pero al conectarse a un lugar determinado de la cadena, puede ver que un nodo de la red ha aceptado la transacción, y el bloque agregado después de eso confirma aún más que la red ha aceptado la transacción.
Mientras los nodos honestos sigan teniendo el control de la red, la verificación es fiable. Sin embargo, cuando la red está controlada por un atacante, la verificación es menos confiable. Aunque los nodos de la red pueden verificar las transacciones por sí mismos, siempre que el atacante mantenga el control de la red, el método de verificación simplificado puede ser engañado por los registros de transacciones falsificados del atacante. Una de las contramedidas es que el software cliente acepte advertencias de los nodos de red. Cuando un nodo de red encuentra un bloque no válido, envía una alerta y aparece una notificación en el software del usuario para informarle que descargue el bloque completo y advertirle que confirme la coherencia de la transacción. Los comerciantes con pagos de alta frecuencia deberían seguir queriendo ejecutar su propio nodo completo para garantizar una seguridad más independiente y una confirmación de transacciones más rápida.
9. Combinación y división de valores
Aunque es posible procesar monedas una por una, es engorroso establecer un registro separado para cada centavo. Para permitir la división y consolidación de valores, las transacciones contienen múltiples entradas y salidas. En general, ya sea un solo insumo de una transacción anterior relativamente grande o una combinación de muchos insumos de un monto menor; Al mismo tiempo, hay como máximo dos salidas: una para el pago (al beneficiario) y otra para el cambio (al remitente) si es necesario.
Es importante tener en cuenta que la "distribución ramificada" no es un problema aquí: "distribución ramificada" significa que una transacción depende de varias transacciones, y esas transacciones dependen de más transacciones. Nunca es necesario extraer una copia histórica completa e independiente de ninguna transacción.
10. Privacidad
Los modelos bancarios tradicionales logran cierto grado de protección de la privacidad al restringir el acceso a la información sobre los operadores y terceros de confianza. Este enfoque fue rechazado debido a la necesidad de hacer públicos todos los registros de transacciones. Sin embargo, mantener la privacidad se puede lograr cortando el flujo de información en otro lugar: el anonimato de la clave pública. El público puede ver que fulano de tal transfirió una cierta cantidad de dinero a fulano de tal, sin embargo, no hay información que apunte a una determinada persona. Este nivel de divulgación de información es un poco como el comercio del mercado de valores, solo se anuncia la hora y el monto de la transacción individual, sin embargo, nadie sabe quiénes son los dos lados de la transacción.
Hay otra capa de cortafuegos. Los comerciantes deben habilitar un nuevo par de claves públicas y privadas para cada transacción, de modo que nadie más pueda rastrear estas transacciones hasta el mismo propietario. Algunas transacciones de insumos múltiples siguen siendo inevitablemente retroactivas, ya que esos insumos inevitablemente se identificarán como provenientes del mismo propietario. El peligro es que si el propietario de una clave pública queda expuesto, todas las demás transacciones relacionadas con ella quedarán expuestas.
11. Cálculos
Supongamos un escenario en el que un atacante intenta generar una cadena alternativa que sea más rápida que la honesta. Incluso si tiene éxito, no puede hacer ningún cambio en el sistema, es decir, no puede crear valor de la nada, y no puede obtener dinero que nunca le pertenece. Los nodos de la red no tratan una transacción no válida como un pago, y los nodos honestos nunca aceptarán un bloque que contenga dicho pago. En el mejor de los casos, el atacante puede modificar sus propias transacciones e intentar recuperar el dinero que ya ha gastado.
La rivalidad entre la cadena honesta y el atacante puede describirse mediante un binomio paseo aleatorio. Un evento de éxito es cuando se acaba de agregar un nuevo bloque a la cadena honesta, aumentando su ventaja en 1, mientras que un evento de falla es cuando la cadena del atacante acaba de agregar un nuevo bloque, reduciendo la ventaja de la cadena honesta en 1.
La probabilidad de que un atacante sea capaz de alcanzarlo por detrás es similar al problema de un jugador que va a la bancarrota. Supongamos que un jugador con fichas ilimitadas comienza con un déficit y le permite apostar un número ilimitado de veces, con el objetivo de llenar el déficit que ya tiene. Podemos calcular la probabilidad de que eventualmente pueda llenar el déficit, es decir, la probabilidad de que el atacante pueda alcanzar a la cadena honesta, de la siguiente manera:
Dado que hemos asumido que p>,q Dado que el atacante necesita ponerse al día con más y más bloques, la probabilidad de éxito disminuye exponencialmente. Si el atacante no tiene la suerte de dar un salto adelante al principio, su porcentaje de victorias se desvanecerá mientras se queda más atrás.
Ahora considere cuánto tiempo tendrá que esperar el destinatario de una nueva transacción para estar completamente seguro de que el remitente no puede cambiar la transacción. Suponemos que el remitente es un atacante que intenta convencer al beneficiario de que ha pagado el pago durante un período de tiempo y luego transferirse el dinero a sí mismo. Cuando esto sucede, el destinatario recibirá, por supuesto, una advertencia, pero el remitente espera que el bote de madera ya esté en el bote.
El destinatario crea un nuevo par de claves públicas y privadas y, a continuación, comunica las claves públicas al remitente poco antes de firmar. Esto evita una situación en la que el remitente prepara un bloque en la cadena por adelantado con un cálculo continuo, y tiene la suerte de estar lo suficientemente adelantado como para ejecutar la transacción hasta entonces. Una vez que se ha enviado el dinero, el remitente deshonesto comienza a trabajar en secreto en otra parachain, tratando de agregarle una versión inversa de la transacción.
El beneficiario espera hasta que la transacción se empaqueta en un bloque, y ya hay bloques z que se han agregado posteriormente. No sabe exactamente qué tan bien lo están haciendo los atacantes, pero puede suponer que los bloques honestos pasan una cantidad promedio de tiempo en el proceso de generar cada bloque; La progresión potencial de un atacante se ajusta a una distribución de Poisson, con un valor esperado de:
Para calcular la probabilidad de que un atacante aún pueda ponerse al día, tenemos que multiplicar la densidad de probabilidad de la distribución de Parzon por el número de bloques que el atacante necesita alcanzar por la probabilidad de que pueda ponerse al día si está detrás de ese número de bloques:
Proponemos un sistema de comercio electrónico que no tenga que depender de la confianza; El punto de partida es un marco de moneda simple que utiliza firmas digitales y, aunque ofrece un sólido control de propiedad, no puede evitar el doble gasto. Para resolver este problema, proponemos una red peer-to-peer que utiliza un mecanismo de prueba de trabajo para registrar un historial de transacciones públicas, y siempre que el nodo honesto pueda controlar la mayor parte de la potencia de cálculo de la CPU, es imposible que un atacante manipule con éxito el sistema solo en términos de potencia de cálculo. La robustez de esta red radica en su simplicidad no estructurada. Los nodos pueden trabajar simultáneamente en un instante con poca colaboración. Ni siquiera necesitan ser reconocidos, porque la ruta del mensaje no depende de un destino específico; Los mensajes solo deben difundirse en la medida de lo posible. Los nodos van y vienen libremente, y cuando se vuelven a unir, solo necesitan aceptar la cadena de prueba de trabajo como prueba de todo lo que sucedió mientras estaban fuera de línea. Votan sobre la potencia de su CPU e indican su aceptación de transacciones válidas agregando constantemente nuevos bloques válidos a la cadena y rechazando bloques no válidos. Las reglas y recompensas necesarias se pueden hacer cumplir a través de este mecanismo de consenso.
Referencias
b-money Dai Wei (1998-11-01)
Diseño de un servicio de sellado de tiempo seguro con requisitos mínimos de confianza Henri Massias, Xavier Serret-Avila, Jean-Jacques Quisquater 20º Simposio sobre Teoría de la Información en el Benelux (1999-05)
Cómo sellar la hora de un documento digital Stuart Haber, W.Scott Stornetta Journal of Cryptology (1991) DOI: 10.1007/bf00196791
Mejora de la eficiencia y la fiabilidad del sellado de tiempo digital Dave Bayer, Stuart Haber, W. Scott Stornetta Secuencias II (1993) DOI: 10.1007/978-1-4613-9323-8_24
Nombres seguros para cadenas de bits Stuart Haber, W. Scott Stornetta Actas de la 4ª conferencia de la ACM sobre seguridad informática y de las comunicaciones - CCS '97(1997) DOI: 10.1145/266420.266430
Hashcash - Una contramedida de denegación de servicio Adam Back (2002-08-01)
Protocolos para criptomonedas de clave pública Ralph C. Merkle 1980 IEEE Symposium on Security and Privacy (1980-04) DOI: 10.1109/sp.1980.10006
Una introducción a la teoría de la probabilidad y sus aplicaciones William Feller John Wiley & Sons (1957)
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Relectura clásica del 15º aniversario: el texto completo de la versión china del libro blanco de Bitcoin
Autor: Satoshi Nakamoto; Traducción al chino: Li Xiaolai
Resumen: Una versión puramente peer-to-peer de un sistema de efectivo electrónico que permitirá que los pagos en línea se envíen directamente de una parte a otra sin pasar por una institución financiera. Si bien las firmas digitales ofrecen algunas soluciones, los principales beneficios de los pagos electrónicos se compensan cuando aún se necesita un tercero de confianza para evitar el doble gasto. Proponemos una solución que utiliza una red peer-to-peer para resolver el problema del doble gasto. La red peer-to-peer marcará la hora de cada transacción ingresando los datos hash de la transacción en una extensa cadena de prueba de trabajo basada en hash que es imposible de cambiar a menos que se rehaga por completo. La cadena más larga se utiliza para probar los eventos que se han presenciado y su orden, y por otro lado, para demostrar que proviene de la mayor reserva de potencia de hash de la CPU. Mientras la gran mayoría de la potencia de cómputo de la CPU esté controlada por nodos benignos, es decir, que no cooperen con aquellos que intentan atacar la red, los nodos benignos generarán la cadena más larga y superarán al atacante. La red en sí misma necesita una estructura mínima. La información se difundirá sobre la base de los mejores esfuerzos, y los nodos irán y vendrán libremente; Sin embargo, a la hora de incorporarse, siempre es necesario aceptar la cadena más larga de pruebas de trabajo como prueba de todo lo que sucedió durante el periodo en el que no estuvieron involucrados.
1. Introducción
El comercio por Internet depende casi por completo de las instituciones financieras como terceros de confianza para procesar los pagos electrónicos. Si bien el sistema es bastante bueno para la mayoría de las transacciones, todavía se ve obstaculizado por los defectos inherentes de los modelos basados en la confianza. Una transacción completamente irreversible no es posible en la práctica, ya que las instituciones financieras no pueden evitar las disputas de arbitraje. El costo del arbitraje aumenta los costos de transacción, lo que a su vez limita el tamaño de la transacción mínima posible y simplemente evita muchas transacciones de micropagos. Además de eso, hay un costo aún mayor: el sistema no puede hacer pagos irreversibles por servicios que no son reversibles. La posibilidad de una reversión ha creado una necesidad generalizada de confianza. Los comerciantes tienen que desconfiar de sus clientes, molestándolos para que proporcionen más información que no sería necesaria si no lo fuera (si se confía). Un cierto porcentaje de fraude se considera inevitable. Estos costos e incertidumbres de pago se pueden evitar cuando los pagos se realizan directamente entre personas utilizando moneda física; Sin embargo, no existe un mecanismo para que ambas partes realicen pagos a través de canales de comunicación sin que una de ellas sea de confianza.
Lo que realmente necesitamos es un sistema de pago electrónico basado en pruebas criptográficas en lugar de confianza, que permita a dos partes realizar transacciones directamente sin tener que confiar en un tercero. La transacción irreversible de la garantía de hashrate puede ayudar a los vendedores a evitar el fraude, y el mecanismo de garantía diaria para proteger a los compradores es fácil de implementar. En este artículo, propondremos una solución para el doble gasto, utilizando un servidor de marca de tiempo distribuido de igual a igual para generar pruebas basadas en hashrate que registren cada transacción en orden cronológico. El sistema es seguro, siempre y cuando los nodos honestos generalmente tengan más potencia de CPU que los atacantes que cooperan entre sí.
2. Transacciones
Definimos una moneda electrónica como una cadena de firmas digitales. Cuando un propietario da una moneda a otra persona, lo hace añadiendo la siguiente firma digital al final de la cadena de firma digital: el hash de la transacción anterior y la clave pública del nuevo propietario. El beneficiario puede verificar la propiedad de la cadena de firma digital verificando la firma.
! [sQZAt4qlbgm150hgxHy4ui11TxFPpIbbi5Z7GUia.jpeg] (https://img.jinse.cn/7126684_watermarknone.png "7126684")
El problema con esta ruta es que el destinatario no puede verificar que nadie haya pagado dos veces entre los propietarios anteriores. Una solución común es traer una autoridad centralizada de confianza, o "mint", y hacer que verifique si hay doble gasto en cada transacción. Después de cada transacción, la moneda debe devolverse a la Casa de la Moneda, que emite una nueva moneda. Además, sólo las monedas emitidas directamente por la Casa de la Moneda son creíbles y no han sido pagadas dos veces. El problema con esta solución es que el destino de todo el sistema monetario está ligado a la empresa que administra la casa de la moneda (como un banco), y cada transacción debe pasar por ella.
Necesitábamos una forma de que el destinatario confirmara que el propietario anterior no había firmado ninguna transacción anterior. Para nuestros propósitos, solo cuentan las transacciones más tempranas, por lo que no nos importan los intentos posteriores de doble gasto. La única forma de confirmar que una transacción no existe es estar informado de todas las transacciones. En el modelo de ceca, la ceca está al tanto de todas las transacciones y puede confirmar el orden de esas transacciones. Para poder lograr esto sin la participación de una "parte de confianza", el registro de transacciones debe declararse públicamente1, y necesitamos un sistema que permita a los participantes acordar el mismo historial de transacciones único que reciben. El beneficiario debe demostrar que, en el momento de cada transacción, la mayoría de los nodos pueden estar de acuerdo en que fue la primera en recibirse.
3. Servidor de marca de tiempo
Esta solución comienza con un servidor de marca de tiempo. Así es como funciona un servidor de marca de tiempo: marca el hash de un conjunto de registros y luego transmite el hash, como lo hace un periódico o como una publicación en Usenet.2 3 4 5. Obviamente, una marca de tiempo demuestra que los datos existían antes de ese momento, de lo contrario no se habría generado el hash. Cada marca de tiempo contiene una marca de tiempo anterior en su hash, formando así una cadena; Cada nueva marca de tiempo se agrega después de la marca de tiempo anterior.
! [IkJWI40CL5rPFbmKNx829DpApCPH8JY1zjTQ9neY.jpeg] (https://img.jinse.cn/7126685_watermarknone.png "7126685")
4. Prueba de trabajo
Para implementar un servidor de marca de tiempo distribuido basado en peer-to-peer, necesitamos usar un sistema de prueba de trabajo como Hash Cash 6 de Adam Burke, en lugar de algo como una publicación de periódico o grupo de noticias. La llamada prueba de trabajo es encontrar un valor; Para que este valor sea verdadero: después de extraer un valor hash para él, por ejemplo, usando SHA-256 para calcular un valor hash, el valor hash debe comenzar con un cierto número de ceros. Cada requisito adicional de 0 aumenta exponencialmente la cantidad de trabajo, y la verificación de esta cantidad de trabajo solo requiere que se calcule un hash.
En nuestra red de marcas de tiempo, implementamos proof-of-work de la siguiente manera: seguimos agregando un nonce a un bloque hasta que se encuentra un valor que satisfaga las condiciones; La condición para esto es que el hash del bloque comience con el número especificado de 0. Una vez que el resultado del consumo de energía de cómputo de la CPU satisface la prueba de trabajo, el bloque ya no se puede cambiar a menos que se vuelva a hacer todo el trabajo anterior. Como se agregan nuevos bloques todo el tiempo, cambiar el bloque actual significa volver a pintar todos los bloques posteriores.
! [L5fHgxjJJ6fSYcFToKfNERzgNlhNgUwdgMiNG2N5.jpeg] (https://img.jinse.cn/7126686_watermarknone.png "7126686")
La prueba de trabajo también resuelve el problema de cómo decidir quién puede tomar decisiones en nombre de la mayoría. Si la llamada "mayoría" se basa en un enfoque de "una dirección IP, un voto", entonces cualquiera que pueda manejar muchas direcciones IP puede considerarse una "mayoría". La prueba de trabajo es esencialmente "una CPU, un voto". La llamada "decisión mayoritaria" está representada por la cadena más larga, porque es la cadena en la que más trabajo se ha invertido. Si la mayor parte de la potencia de cómputo de la CPU está controlada por nodos honestos, entonces la cadena honesta crecerá más rápido y será mucho más rápida que otras cadenas de la competencia. Para cambiar un bloque que ya se ha producido, un atacante tendría que volver a completar la prueba de trabajo para ese bloque y todos los bloques posteriores, y luego ponerse al día y superar el trabajo del nodo honesto. Este artículo muestra por qué la probabilidad de que un atacante retrasado se ponga al día disminuye exponencialmente a medida que aumenta el número de bloqueos.
Con el fin de hacer frente al creciente número de potencia de cálculo de hardware y al número de contribuciones de nodos que pueden cambiar con el tiempo, la dificultad de la prueba de trabajo está determinada por una media móvil del número de bloques producidos por hora en promedio. Si el bloque se genera demasiado rápido, la dificultad aumentará.
5. Red
Los pasos para ejecutar la red son los siguientes:
El nodo siempre piensa que la cadena más larga es la correcta y sigue añadiéndole nuevos datos. Si dos nodos transmiten simultáneamente dos versiones diferentes de "Next Block" a la red, algunos nodos recibirán una de ellas primero, mientras que otros recibirán la otra primero. En este caso, los nodos continuarán trabajando en el bloque que recibieron primero, pero también guardarán la otra rama en caso de que se convierta en la cadena más larga. Cuando se encuentra la siguiente prueba de trabajo y una de las ramas se hace más larga, esta divergencia temporal se resuelve y los nodos que trabajan en la otra rama cambian a una cadena más larga.
Las nuevas transacciones no necesariamente tienen que transmitirse a todos los nodos. Siempre que se alcancen suficientes nodos, no pasará mucho tiempo antes de que esas transacciones se empaqueten en un bloque. Las difusiones en bloque también permiten descartar algunos mensajes. Si un nodo no recibe un bloque, el nodo se dará cuenta de que perdió el bloque anterior cuando reciba el siguiente bloque y realizará una solicitud para reemplazar el bloque que falta.
6. Incentivos
Por convención, la primera transacción de cada bloque es una transacción especial que genera una nueva moneda y pertenece al generador del bloque. Al hacerlo, recompensa a los nodos por apoyar la red y proporcionar una forma de emitir monedas en circulación, en un sistema en el que no existe una autoridad centralizada para emitir esas monedas de todos modos. Por lo tanto, agregar constantemente un cierto número de nuevas monedas a la circulación es como si los mineros de oro usaran constantemente sus recursos para agregar oro a la circulación. En nuestro sistema, los recursos que se consumen son el tiempo que la CPU está funcionando y la potencia que utilizan.
Las recompensas también pueden provenir de tarifas de transacción. Si el valor de salida de una transacción es menor que su valor de entrada, entonces la diferencia es la tarifa de transacción; La tarifa de transacción se utiliza para recompensar a los nodos por empaquetar la transacción en este bloque. Una vez que el número establecido de monedas esté en circulación, las recompensas estarán totalmente cubiertas por las tarifas de transacción y no habrá absolutamente ninguna inflación.
El mecanismo de recompensa también puede animar a los nodos a ser honestos. Si un atacante codicioso puede atrapar más potencia de CPU que todos los nodos honestos, debe tomar una decisión: ¿debería usar esa potencia de cálculo para engañar a otros robando el dinero que gastó? ¿O usar este poder de cómputo para generar nuevas monedas? Debería poder encontrar más rentable jugar según las reglas, que ahora le permiten ganar más monedas que todos los demás combinados, lo que es claramente más rentable que destruir secretamente el sistema y reducir su riqueza a la nada.
7. Recuperación de espacio en disco
Si la transacción más reciente de una moneda ocurrió antes de suficientes bloques, el historial de transacciones de gasto de la moneda antes de esa transacción se puede descartar para ahorrar espacio en disco. Para hacer esto sin romper el hash del bloque, el hash del registro de transacción se incluirá en un árbol de Merkle, y solo la raíz del árbol se incluirá en el hash del bloque. Al cortar las ramas, los bloques viejos se pueden comprimir. No es necesario guardar el hash interno.
! [GOSWSMEutHTHRctOsFIZ6l0XiCZpQDCytysccOvF.jpeg] (https://img.jinse.cn/7126687_watermarknone.png "7126687")
Un encabezado de bloque sin ningún historial de transacciones es de aproximadamente 80 bytes. Suponiendo que se produce un bloque cada diez minutos, 80 bytes multiplicados por 6 por 24 por 365 equivalen a 4,2 millones por año. A partir de 2008, la mayoría de las computadoras a la venta venían con 2 GB de RAM, y la Ley de Moore predice que se agregarán 1.2 GB por año, incluso si el encabezado del bloque tiene que almacenarse en la memoria.
8. Confirmación de pago simplificada
Es posible confirmar los pagos incluso sin tener que ejecutar un nodo de red completo. Todo lo que el usuario necesita es una copia del encabezado del bloque de la cadena más larga con prueba de trabajo (puede verificar el nodo en línea para confirmar que tiene la cadena más larga) y luego obtener el nodo de rama del árbol de Merkle, que a su vez se conecta a la transacción cuando se marcó la hora del bloque. El usuario no puede verificar la transacción por sí mismo, pero al conectarse a un lugar determinado de la cadena, puede ver que un nodo de la red ha aceptado la transacción, y el bloque agregado después de eso confirma aún más que la red ha aceptado la transacción.
! [ZUtmrmdPnropshOMBHizRFDwDh0pncg5VGNnzWcI.jpeg] (https://img.jinse.cn/7126688_watermarknone.png "7126688")
Mientras los nodos honestos sigan teniendo el control de la red, la verificación es fiable. Sin embargo, cuando la red está controlada por un atacante, la verificación es menos confiable. Aunque los nodos de la red pueden verificar las transacciones por sí mismos, siempre que el atacante mantenga el control de la red, el método de verificación simplificado puede ser engañado por los registros de transacciones falsificados del atacante. Una de las contramedidas es que el software cliente acepte advertencias de los nodos de red. Cuando un nodo de red encuentra un bloque no válido, envía una alerta y aparece una notificación en el software del usuario para informarle que descargue el bloque completo y advertirle que confirme la coherencia de la transacción. Los comerciantes con pagos de alta frecuencia deberían seguir queriendo ejecutar su propio nodo completo para garantizar una seguridad más independiente y una confirmación de transacciones más rápida.
9. Combinación y división de valores
Aunque es posible procesar monedas una por una, es engorroso establecer un registro separado para cada centavo. Para permitir la división y consolidación de valores, las transacciones contienen múltiples entradas y salidas. En general, ya sea un solo insumo de una transacción anterior relativamente grande o una combinación de muchos insumos de un monto menor; Al mismo tiempo, hay como máximo dos salidas: una para el pago (al beneficiario) y otra para el cambio (al remitente) si es necesario.
! [rRreBWdF8I1swfs5QtBILVrI0guXumj1ulPkbKyu.jpeg] (https://img.jinse.cn/7126689_watermarknone.png "7126689")
Es importante tener en cuenta que la "distribución ramificada" no es un problema aquí: "distribución ramificada" significa que una transacción depende de varias transacciones, y esas transacciones dependen de más transacciones. Nunca es necesario extraer una copia histórica completa e independiente de ninguna transacción.
10. Privacidad
Los modelos bancarios tradicionales logran cierto grado de protección de la privacidad al restringir el acceso a la información sobre los operadores y terceros de confianza. Este enfoque fue rechazado debido a la necesidad de hacer públicos todos los registros de transacciones. Sin embargo, mantener la privacidad se puede lograr cortando el flujo de información en otro lugar: el anonimato de la clave pública. El público puede ver que fulano de tal transfirió una cierta cantidad de dinero a fulano de tal, sin embargo, no hay información que apunte a una determinada persona. Este nivel de divulgación de información es un poco como el comercio del mercado de valores, solo se anuncia la hora y el monto de la transacción individual, sin embargo, nadie sabe quiénes son los dos lados de la transacción.
! [FACNxW4jyufvrE53ONTept7HLlHzayQU9CwIg4eX.jpeg] (https://img.jinse.cn/7126690_watermarknone.png "7126690")
Hay otra capa de cortafuegos. Los comerciantes deben habilitar un nuevo par de claves públicas y privadas para cada transacción, de modo que nadie más pueda rastrear estas transacciones hasta el mismo propietario. Algunas transacciones de insumos múltiples siguen siendo inevitablemente retroactivas, ya que esos insumos inevitablemente se identificarán como provenientes del mismo propietario. El peligro es que si el propietario de una clave pública queda expuesto, todas las demás transacciones relacionadas con ella quedarán expuestas.
11. Cálculos
Supongamos un escenario en el que un atacante intenta generar una cadena alternativa que sea más rápida que la honesta. Incluso si tiene éxito, no puede hacer ningún cambio en el sistema, es decir, no puede crear valor de la nada, y no puede obtener dinero que nunca le pertenece. Los nodos de la red no tratan una transacción no válida como un pago, y los nodos honestos nunca aceptarán un bloque que contenga dicho pago. En el mejor de los casos, el atacante puede modificar sus propias transacciones e intentar recuperar el dinero que ya ha gastado.
La rivalidad entre la cadena honesta y el atacante puede describirse mediante un binomio paseo aleatorio. Un evento de éxito es cuando se acaba de agregar un nuevo bloque a la cadena honesta, aumentando su ventaja en 1, mientras que un evento de falla es cuando la cadena del atacante acaba de agregar un nuevo bloque, reduciendo la ventaja de la cadena honesta en 1.
La probabilidad de que un atacante sea capaz de alcanzarlo por detrás es similar al problema de un jugador que va a la bancarrota. Supongamos que un jugador con fichas ilimitadas comienza con un déficit y le permite apostar un número ilimitado de veces, con el objetivo de llenar el déficit que ya tiene. Podemos calcular la probabilidad de que eventualmente pueda llenar el déficit, es decir, la probabilidad de que el atacante pueda alcanzar a la cadena honesta, de la siguiente manera:
! [dxwr3HPLYbHZisFnpwH6hIvaudm3FchUzRFXaD7m.jpeg] (https://img.jinse.cn/7126691_watermarknone.png "7126691")
Dado que hemos asumido que p>,q Dado que el atacante necesita ponerse al día con más y más bloques, la probabilidad de éxito disminuye exponencialmente. Si el atacante no tiene la suerte de dar un salto adelante al principio, su porcentaje de victorias se desvanecerá mientras se queda más atrás.
Ahora considere cuánto tiempo tendrá que esperar el destinatario de una nueva transacción para estar completamente seguro de que el remitente no puede cambiar la transacción. Suponemos que el remitente es un atacante que intenta convencer al beneficiario de que ha pagado el pago durante un período de tiempo y luego transferirse el dinero a sí mismo. Cuando esto sucede, el destinatario recibirá, por supuesto, una advertencia, pero el remitente espera que el bote de madera ya esté en el bote.
El destinatario crea un nuevo par de claves públicas y privadas y, a continuación, comunica las claves públicas al remitente poco antes de firmar. Esto evita una situación en la que el remitente prepara un bloque en la cadena por adelantado con un cálculo continuo, y tiene la suerte de estar lo suficientemente adelantado como para ejecutar la transacción hasta entonces. Una vez que se ha enviado el dinero, el remitente deshonesto comienza a trabajar en secreto en otra parachain, tratando de agregarle una versión inversa de la transacción.
El beneficiario espera hasta que la transacción se empaqueta en un bloque, y ya hay bloques z que se han agregado posteriormente. No sabe exactamente qué tan bien lo están haciendo los atacantes, pero puede suponer que los bloques honestos pasan una cantidad promedio de tiempo en el proceso de generar cada bloque; La progresión potencial de un atacante se ajusta a una distribución de Poisson, con un valor esperado de:
! [Go4WNHNh1YtPsMqjI2XbNCMTnITJUIl9w8LqM6yj.jpeg] (https://img.jinse.cn/7126692_watermarknone.png "7126692")
Para calcular la probabilidad de que un atacante aún pueda ponerse al día, tenemos que multiplicar la densidad de probabilidad de la distribución de Parzon por el número de bloques que el atacante necesita alcanzar por la probabilidad de que pueda ponerse al día si está detrás de ese número de bloques:
! [5O3ugdwP0uoNL0qOnvLbnUvNTXGMBmxJj4yS00y3.jpeg] (https://img.jinse.cn/7126694_watermarknone.png "7126694")
Convertir a un programa C...
! [XjwW5ZbFNIZCfiPFAnbg7b4iW4qp9A8g1LFKe2f2.jpeg] (https://img.jinse.cn/7126698_watermarknone.png "7126698")
Tomando algunos de los resultados, podemos ver que la probabilidad disminuye exponencialmente a medida que z aumenta:
! [452fZL5ude7CUuUz85STQEcvquwOCHxhZ3pEhKRc.jpeg] (https://img.jinse.cn/7126700_watermarknone.png "7126700")
Si P es menor que 0,1%...
! [zfsBufXK54KjstagaZXrPOUREzaoQU7VPy9eYjjX.jpeg] (https://img.jinse.cn/7126701_watermarknone.png "7126701")
12. conclusión
Proponemos un sistema de comercio electrónico que no tenga que depender de la confianza; El punto de partida es un marco de moneda simple que utiliza firmas digitales y, aunque ofrece un sólido control de propiedad, no puede evitar el doble gasto. Para resolver este problema, proponemos una red peer-to-peer que utiliza un mecanismo de prueba de trabajo para registrar un historial de transacciones públicas, y siempre que el nodo honesto pueda controlar la mayor parte de la potencia de cálculo de la CPU, es imposible que un atacante manipule con éxito el sistema solo en términos de potencia de cálculo. La robustez de esta red radica en su simplicidad no estructurada. Los nodos pueden trabajar simultáneamente en un instante con poca colaboración. Ni siquiera necesitan ser reconocidos, porque la ruta del mensaje no depende de un destino específico; Los mensajes solo deben difundirse en la medida de lo posible. Los nodos van y vienen libremente, y cuando se vuelven a unir, solo necesitan aceptar la cadena de prueba de trabajo como prueba de todo lo que sucedió mientras estaban fuera de línea. Votan sobre la potencia de su CPU e indican su aceptación de transacciones válidas agregando constantemente nuevos bloques válidos a la cadena y rechazando bloques no válidos. Las reglas y recompensas necesarias se pueden hacer cumplir a través de este mecanismo de consenso.
Referencias