Bitcoin: un sistema de dinero en efectivo electrónico entre iguales.
Satoshi Nakamoto
Resumen. Una versión puramente de igual-a-igual de dinero en efectivo electrónico permitiría
que los pagos en línea sean enviados directamente de una parte a otra sin pasar por una
institución financiera. Las firmas digitales proporcionan parte de la solución, pero los
beneficios principales se pierden si aún se requiere un tercero de confianza para evitar el doble
gasto. Proponemos una solución al problema del doble gasto utilizando una red de igual-a igual.
La red marca el tiempo de las transacciones al agruparlas en una cadena continua de
pruebas de trabajo basadas en hash, formando un registro que no se puede cambiar sin rehacer
la prueba de trabajo. La cadena más larga no solo sirve como prueba de la secuencia de eventos
presenciados, sino también como prueba de que proviene del mayor grupo de potencia de CPU.
Mientras la mayoría de la potencia de CPU esté controlada por nodos que no cooperan para
atacar la red, ellos generarán la cadena más larga y superarán a los atacantes. La propia red
requiere una estructura mínima. Los mensajes se transmiten sobre una base de mejor esfuerzo,
y los nodos pueden abandonar y unirse de nuevo a la red a voluntad, aceptando la cadena de
prueba de trabajo más larga como prueba de lo que sucedió mientras estaban fuera.
INTRODUCCIÓN
El comercio en Internet ha llegado a depender casi exclusivamente de instituciones financieras que actúan como terceros de confianza para procesar pagos electrónicos. Si bien el sistema funciona suficientemente bien para la mayoría de las transacciones, aún sufre las debilidades inherentes del modelo basado en confianza. Las transacciones completamente no reversibles no son realmente posibles, ya que las instituciones financieras no pueden evitar mediar disputas.
El costo de la mediación aumenta los costos de transacción, limitando el tamaño mínimo práctico de transacción y cortando la posibilidad de pequeñas transacciones casuales, y existe un costo más amplio en la pérdida de capacidad para realizar pagos no reversibles por servicios no reversibles. Con la posibilidad de reversión, la necesidad de confianza se extiende.
Los comerciantes deben ser cautelosos de sus clientes, molestándolos por más información de la que de otra manera necesitarían. Un cierto porcentaje de fraude es aceptado como inevitable. Estos costos y las incertidumbres de pago se pueden evitar en persona utilizando una moneda física, pero no existe ningún mecanismo para realizar pagos a través de un canal de comunicaciones sin un tercero de confianza. Lo que se necesita es un sistema de pago electrónico basado en pruebas criptográficas en lugar de confianza, que permita a dos partes interesadas cualesquiera transar directamente entre ellas sin la necesidad de un tercero de confianza.
Las transacciones que son computacionalmente imprácticas de revertir protegerían a los vendedores del fraude, y mecanismos de fideicomiso rutinarios podrían implementarse fácilmente para proteger a los compradores. En este documento, proponemos una solución al problema del doble gasto mediante el uso de un servidor de marcas de tiempo distribuido de igual-a-igual para generar prueba computacional del orden cronológico de las transacciones. El sistema es seguro siempre que los nodos honestos controlen colectivamente más potencia de CPU que cualquier grupo colaborador de nodos atacantes
TRANSACCIONES
Definimos una moneda electrónica como una cadena de firmas digitales. Cada propietario transfiere la moneda al siguiente al firmar digitalmente un hash de la transacción anterior y la llave pública del 2 siguiente propietario y agregarlos al final de la moneda. Un beneficiario puede verificar las firmas para verificar la cadena de propiedad.
El problema, por supuesto, es que
el beneficiario no puede verificar que uno de los propietarios no haya gastado
dos veces la moneda. Una solución común es introducir una autoridad central de confianza,
o casa de moneda, que verifica cada transacción por doble gasto. Después de
cada transacción, la moneda debe devolverse a la casa de moneda para emitir una
nueva moneda, y solo las monedas emitidas directamente por la casa de moneda
son confiables de no haber sido doblemente gastadas. El problema con esta
solución es que el destino de todo el sistema monetario depende de la compañía
que gestiona la casa de moneda, con cada transacción debiendo pasar a través de
ellos, justo como un banco.
Necesitamos una forma para que el
beneficiario sepa que los propietarios anteriores no firmaron ninguna
transacción previa. Para nuestros propósitos, la transacción más temprana es la
que cuenta, por lo que no nos preocupamos por los intentos posteriores de doble
gasto. La única forma de confirmar la ausencia de una transacción es estar al
tanto de todas las transacciones. En el modelo basado en la casa de moneda,
ésta estaba al tanto de todas las transacciones y decidía cuál llegaba primero.
Para lograr esto sin una tercera parte de confianza, las transacciones deben
ser anunciadas públicamente [1], y necesitamos un sistema para que los
participantes acuerden un historial único del orden en que ellas se recibieron.
El beneficiario necesita prueba de que, al momento de cada transacción, la
mayoría de los nodos acordaron que esa fue la primera recibida.
SERVIDOR DE MARCA DE TIEMPO
La solución que proponemos
comienza con un servidor de marca de tiempo. Un servidor de marca de tiempo
funciona realizando un hash de un bloque de elementos a ser marcados de tiempo
y publicando ampliamente el hash, tal como en un periódico o una publicación de
Usenet [2-5]. La marca de tiempo prueba que los datos deben haber existido en
ese momento, obviamente, para poder entrar en el hash. Cada marca de tiempo
incluye la marca de tiempo previa en su hash, formando una cadena, con cada
marca de tiempo adicional reforzando las anteriores a ésta.
PRUEBA DE TRABAJO
Para implementar un servidor de marca de tiempo distribuido de igual-a-igual, tendremos que usar un sistema de prueba de trabajo similar al Hashcash de Adam Back [6], en lugar de publicaciones de periódico o Usenet.
La prueba de trabajo implica la búsqueda de un valor que al aplicarle un hash, tal como SHA-256, el hash comienza con un número de bits cero. El trabajo promedio requerido es exponencial en el número de bits cero requeridos y se puede verificar ejecutando un simple hash. Para nuestra red de marca de tiempo, implementamos la prueba de trabajo incrementando un nonce (o número único) en el bloque hasta que se encuentre un valor que proporcione al hash del bloque los bits cero requeridos.
Una vez que el esfuerzo de la CPU se ha gastado para que cumpla con la prueba de trabajo, el bloque no se puede cambiar sin rehacer el trabajo. Como los bloques posteriores se encadenan después de éste, el trabajo para cambiar el bloque incluiría rehacer todos los bloques posteriores a éste.
La prueba de trabajo también resuelve el problema de determinar la representación en la toma de decisiones por mayoría. Si la mayoría se basara en una-dirección-IP-un-voto, podría ser subvertida por cualquier persona capaz de asignar muchas direcciones IP. La prueba de trabajo es esencialmente un-CPU-un-voto.
La decisión por mayoría está representada por la cadena más larga, que cuenta con el mayor esfuerzo de prueba de trabajo invertido en ella. Si la mayoría de la potencia de CPU está controlada por nodos honestos, la cadena honesta crecerá más rápido y superará a cualquier cadena competidora.
Para modificar un bloque del pasado, un atacante tendría que rehacer la prueba de trabajo del bloque y todos los bloques después de éste y luego alcanzar y superar el trabajo de los nodos honestos. Más adelante demostraremos que la probabilidad de que un atacante más lento se ponga al día disminuye exponencialmente a medida que se agregan bloques subsecuentes. Para compensar el aumento de la velocidad del hardware y el variable interés en ejecutar nodos a lo largo del tiempo, la dificultad de la prueba de trabajo está determinada por un promedio móvil que apunta a un número promedio de bloques por hora. Si se generan demasiado rápido, la dificultad aumenta.
LA RED
Los pasos para correr la red son los siguientes:
1) Las nuevas transacciones se transmiten a todos los nodos.
2) Cada nodo recoge nuevas transacciones en un bloque.
3) Cada nodo trabaja para encontrar una prueba de trabajo
difícil para su bloque.
4) Cuando un nodo encuentra una prueba de trabajo, difunde
el bloque a todos los nodos.
5) Los nodos aceptan el bloque solo si todas las transacciones
en él son válidas y no ya gastadas.
6) Los nodos expresan su aceptación del bloque al trabajar
en la creación del siguiente bloque en la cadena, utilizando el hash del bloque
aceptado como el hash previo.
Los nodos siempre consideran que la cadena más larga es la
correcta y seguirán trabajando en extenderla. Si dos nodos difunden versiones
diferentes del siguiente bloque simultáneamente, algunos nodos pueden recibir
uno u otro primero. En ese caso, trabajan en el primero que recibieron, pero
guardan la otra rama en caso de que se vuelva más larga. El empate se romperá
cuando se encuentre la próxima prueba de trabajo y una rama se vuelva más
larga; los nodos que estaban trabajando en la otra rama cambiarán entonces a la
más larga.
Las difusiones de nuevas transacciones no necesariamente
tienen que llegar a todos los nodos. Mientras lleguen a muchos nodos, entrarán
en un bloque en poco tiempo. Las transmisiones de bloque también toleran los
mensajes perdidos. Si un nodo no recibe un bloque, lo solicitará cuando reciba
el siguiente bloque y se dé cuenta de que perdió uno.
INCENTIVO
Por convención, la primera transacción en un bloque es una transacción especial que inicia una nueva moneda perteneciente al creador del bloque. Esto agrega un incentivo para que los nodos apoyen la red, y proporciona una manera de distribuir inicialmente monedas a circulación, ya que no hay una autoridad central para emitirlas. La adición estable de una cantidad constante de nuevas monedas es análoga a los mineros de oro que gastan recursos para agregar oro a circulación. En nuestro caso, son el tiempo de CPU y la electricidad que son gastados.
El incentivo también puede ser financiado con comisiones de
transacción. Si el valor de salida de una transacción es menor que su valor de
entrada, la diferencia es una comisión de transacción que se agrega al valor
incentivo del bloque que contiene la transacción. Una vez que un número
predeterminado de monedas haya entrado en circulación, el incentivo puede pasar
completamente a las comisiones de transacción y ser completamente libre de
inflación.
El incentivo puede
ayudar a alentar a los nodos a mantenerse honestos. Si un atacante codicioso es
capaz de ensamblar más poder de CPU que todos los nodos honestos, tendría que
elegir entre usarlo para defraudar a las personas robando de vuelta sus pagos,
o usarlo para generar nuevas monedas. Debería encontrar más rentable jugar
según las reglas, reglas tales que lo favorecen con más nuevas monedas que
todos los demás combinados, que socavar el sistema y la validez de su propia
riqueza.
RECUPERANDO ESPACIO EN DISCO
Una vez que la última transacción en una moneda está
sepultada bajo suficientes bloques, las transacciones gastadas antes de ella
pueden ser descartadas para ahorrar espacio en disco. Para facilitar esto sin
romper el hash del bloque, las transacciones son procesadas en hashes en un
árbol Merkle [7] [2] [5], con solo la raíz incluida en el hash del bloque. Los
bloques viejos se pueden entonces compactar desprendiendo las ramas del árbol.
Los hashes interiores no necesitan ser almacenados.
Una cabecera de bloque sin transacciones sería de unos 80 bytes. Si suponemos que los bloques se generan cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4,2MB por año. Con sistemas informáticos siendo típicamente vendidos con 2 GB de RAM a partir de 2008, y la Ley de Moore prediciendo un crecimiento actual de 1,2 GB por año, el almacenamiento no debería ser un problema incluso si las cabeceras de bloque deben mantenerse en la memoria.
VERIFICACIÓN SIMPLIFICADA DE PAGO
Es posible verificar los pagos sin ejecutar un nodo de red
completo. Un usuario solo necesita conservar una copia de las cabeceras de
bloque de la cadena de prueba de trabajo más larga, la cual puede obtener
consultando los nodos de la red hasta que esté convencido de que tiene la
cadena más larga, y obtener la rama Merkle que vincula la transacción con el
bloque en el que fue marcada de tiempo. El usuario no puede verificar la
transacción por sí mismo, pero al vincularla a un lugar en la cadena, puede ver
que un nodo de red la ha aceptado, y los bloques agregados después de ésta
confirman aún más que la red la ha aceptado.
Como tal, la verificación es confiable siempre que los nodos honestos controlen la red, pero es más vulnerable si la red está dominada por un atacante. Mientras que los nodos de la red pueden verificar las transacciones por sí mismos, el método simplificado puede ser engañado por las transacciones fabricadas de un atacante durante tanto tiempo como el atacante pueda seguir dominando la red. Una estrategia para protegerse contra esto sería aceptar alertas de los nodos de la red cuando detecten un bloque inválido, solicitando al software del usuario que descargue el bloque completo y las transacciones alertadas para confirmar la inconsistencia. Los negocios que reciben pagos frecuentes probablemente aún querrán ejecutar sus propios nodos para una seguridad más independiente y una verificación más rápida.
COMBINANDO Y DIVIDIENDO VALOR
Aunque sería posible manejar las monedas individualmente,
sería pesado manejar una transacción separada por cada centavo en una
transferencia. Para permitir que el valor sea dividido y combinado, las
transacciones contienen múltiples entradas y salidas. Normalmente habrá o una
entrada única de una transacción previa más grande o entradas múltiples que
combinan montos más pequeños y, como máximo, dos salidas: una para el pago y
una para devolver el cambio, si corresponde, al remitente.
Debe tenerse en cuenta que la diseminación de control, donde una transacción depende de varias transacciones, y esas transacciones dependen de muchas más, no es un problema aquí. Nunca es necesario extraer una copia independiente completa del historial de una transacción.
PRIVACIDAD
El modelo bancario tradicional logra un nivel de privacidad
al limitar el acceso a la información a las partes involucradas y al tercero de
confianza. La necesidad de anunciar públicamente todas las transacciones
imposibilita este método, pero la privacidad todavía se puede mantener
rompiendo el flujo de información en otro lugar: al mantener las llaves
públicas anónimas. El público puede ver que alguien está enviando un monto a
otra persona, pero sin información que vincule la transacción con alguien. Esto
es similar al nivel de información liberada por las bolsas de valores, donde el
tiempo y el tamaño de las operaciones individuales, la "cinta", se
hace público, pero sin indicar quiénes fueron las partes.
Como un firewall adicional, un nuevo par de llaves debería
usarse para cada transacción para evitar que se vinculen a un mismo
propietario. Cierta vinculación sigue siendo inevitable con transacciones de
múltiples entradas, que necesariamente revelan que sus entradas fueron
propiedad del mismo dueño. El riesgo es que, si se revela el propietario de una
llave, la vinculación podría revelar otras transacciones que pertenecieron al
mismo dueño.
CÁLCULOS
Consideramos el escenario de un atacante que intenta generar
una cadena alternativa más rápido que la cadena honesta. Incluso si esto se
logra, no abre el sistema a cambios arbitrarios, como crear valor de la nada o
tomar dinero que nunca perteneció al atacante. Los nodos no aceptarán una
transacción inválida como pago, y los nodos honestos nunca aceptarán un bloque
que las contenga. Un atacante solo puede intentar cambiar una de sus propias
transacciones para recuperar el dinero que gastó recientemente.
La carrera entre la cadena honesta y una cadena del atacante
puede caracterizarse como una Caminata Aleatoria Binomial. El evento de éxito
es la cadena honesta siendo extendida en un bloque, aumentando su ventaja en
+1, y el evento de fracaso es la cadena del atacante siendo extendida en un
bloque, lo que reduce la brecha en -1.
La probabilidad de que un atacante se recupere de un déficit dado es análoga al problema de la Ruina del Jugador. Supongamos que un jugador con crédito ilimitado comienza en déficit y juega potencialmente un número infinito de intentos para tratar de alcanzar el punto de equilibrio. Podemos calcular la probabilidad de que alguna vez logre alcanzar el punto de equilibrio, o de que un atacante alcance alguna vez a la cadena honesta, de la siguiente manera [8]:
Dada nuestra suposición de que p > q, la probabilidad
disminuye exponencialmente a medida que aumenta el número de bloques que el
atacante tiene que alcanzar. Con las probabilidades en contra de él, si no hace
una estocada de suerte hacia adelante al principio, sus posibilidades se
vuelven cada vez más pequeñas a medida que se queda atrás.
Ahora consideramos cuánto tiempo debe esperar el
beneficiario de una nueva transacción antes de estar suficientemente seguro de
que el remitente no puede cambiar la transacción. Asumimos que el remitente es
un atacante que quiere hacer creer al beneficiario que le pagó por un tiempo,
luego cambiarlo para pagarse a sí mismo después de que haya pasado un tiempo.
El receptor recibirá una alerta cuando eso suceda, pero el
emisor espera que sea demasiado tarde. El receptor genera un nuevo par de
llaves y le entrega la llave pública al remitente poco antes de firmar. Esto
evita que el remitente prepare una cadena de bloques de antemano trabajando continuamente
hasta que tenga la suerte de avanzar lo suficiente y luego ejecute la
transacción en ese momento. Una vez que se envía la transacción, el remitente
deshonesto comienza a trabajar en secreto en una cadena paralela que contiene
una versión alternativa de su transacción.
El beneficiario espera hasta que la transacción se haya agregado a un bloque y z cantidad de bloques haya sido vinculada después de éste. Él no sabe la cantidad exacta de progreso que ha hecho el atacante, pero asumiendo que los bloques honestos tomaron el tiempo promedio esperado por bloque, el progreso potencial del atacante será una distribución de Poisson con valor esperado:
CONCLUSIÓN
Hemos propuesto un sistema para transacciones electrónicas sin depender en la confianza. Comenzamos con el marco habitual de monedas hechas de firmas digitales, lo que proporciona un fuerte control de propiedad, pero está incompleto sin una manera de evitar el doble gasto.
Para resolver esto, propusimos una red de igual-a-igual utilizando prueba de trabajo para registrar un historial público de transacciones que rápidamente se vuelve computacional impráctico de cambiar para un atacante si los nodos honestos controlan la mayoría de la potencia de CPU.
La red es robusta en su simpleza desestructurada. Los nodos trabajan todos a la vez con poca coordinación.
Ellos no necesitan ser identificados, ya que los mensajes no se envían a ningún lugar en particular y solo deben ser entregados en base al mejor esfuerzo. Los nodos pueden abandonar y volver a unirse a la red a voluntad, aceptando la cadena de prueba de trabajo como prueba de lo que sucedió mientras estaban fuera.
Ellos votan con su poder de CPU, expresando su aceptación de bloques válidos al trabajar en extenderlos y rechazando bloques inválidos al rehusarse a trabajar en ellos. Cualesquiera reglas e incentivos necesarios pueden ser impuestos con este mecanismo de consenso.
