El libro oculto de Satoshi Nakamoto creador de bitcoin, al descubierto
Bitcoin: un sistema de dinero en
efectivo electrónico entre iguales.
Satoshi
Nakamotowww.bitcoin.org
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.