coin, hash, p2p, nodos, blockchain, timestamp, pow, nonce, cpu
Imagine que en lugar de tener una base de datos en una red de pagos digitales en la forma de registros contables convencionales, se tiene una base de datos en una red de pagos electrónicos en la forma de cadena de bloques. Ambas bases de datos son distintas pero contienen la misma información contable: el intercambio de propiedad en un sistema monetario. Los ítems relevantes en estas bases de datos son las transacciones o intercambios de un bien monetario. Qué características tiene cada sistema de base de datos?.
En la base de datos digital tradicional, se define la moneda digital como una colección de registros contables de intercambios de propiedad, registros contables de pagos. La información contable (centralizada en los bancos) registrada en las cuentas de los usuarios, se va actualizando según un sistema de registros tradicionales (tipo filas y columnas) a medida que los usuarios realizan transacciones --de transferencias de propiedad-- las que son enviadas al servidor del banco para ser certificadas y aprobadas por la autoridad bancaria. Esta actualización es de suma cero estricta --SzS-- en el sentido en que la cantidad de dinero digital que sale de una cuenta (un pago) va a parar a otras cuentas no más de una única vez; es decir que, seleccionada una cantidad de moneda digital, no es posible usar esa cantidad para hacer pagos duplicados, por lo que no hay doble pago.
Esto es así porque a la moneda digital la acuña el banco. El usuario envía sólo la orden de transacción, de transferencia de propiedad, pero es el banco el que acuña el registro contable y confirma, o no, la trasferencia de propiedad de la moneda. Así, este modelo de control implementado en el servidor del banco, evita el doble pago en el sentido en que no es posible hacer el cambio correspondiente de un mismo registro más de una vez. Lo que llega al servidor es una orden de cambio de registro pero el cambio no se hace sin chequear si hay fondos disponibles. La autoridad es consciente del orden de llegada de todas las transacciones porque las ve a todas ellas; por esto puede identificar peticiones duplicadas y autorizar sólo una de ellas.
En la otra base de datos, Satoshi define la electronic coin como una cadena de firmas digitales. Aquí también se cumple la suma cero, pues contiene la misma información de pagos, pero se administra de manera distinta; el chequeo SzS se hace usando un modelo que es independiente de una autoridad que autoriza pagos. Como se ve en el esquema de abajo, cada dueño transfiere (la propiedad de) la coin al próximo dueño firmando digitalmente un hash que contiene el hash de la transacción previa y la cuenta pública del próximo dueño; luego agrega este hash al final de la coin. Por esto, un usuario del sistema puede chequear las firmas para verificar la cadena de propiedad.
TXS: Esquema tomado del paper de Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
El problema de este esquema es que el usuario no puede verificar si se hizo un doble pago. Satoshi sostiene que una solución posible a este problema es introducir una autoridad central confiable, un acuñador, que chequee el doble pago en cada transacción. Después de cada transacción, la coin se retorna al acuñador quien emite una nueva coin que envía al nuevo dueño, y sólo la coin emitida por el acuñador será considerada libre de doble pago; el acuñador ve todas las transacciones, por lo que podrá detectar el doble pago. El problema de este modelo con autoridad es que el destino de todo el sistema monetario depende de la compañía encargada del acuñaje. Esto último sería equivalente a transferir la emisión de la coin a una autoridad, lo cual nos deja en el modelo basado en la confianza discutido para el caso de la moneda digital centralizada.
En un esquema descentralizado, en una red p2p, es en la instancia de transacción donde se define la electronic coin, es ahí donde se autoriza el evento de transferencia de propiedad. En ninguna otra instancia ocurre este evento. Esta transacción es empaquetada en un hash y enviada al nuevo dueño. Será tarea de los nodos de la red verificar si las transacciones son genuinas y generar las condiciones para evitar el doble pago. En estos servidores todas las transacciones se empaquetan en un bloque que se ensambla a una cadena de bloques técnicamente llamada blockchain.
En una blockchain no se van actualizando los campos de las cuentas como si fueran registros contables digitales, sino que son los dueños de la coin quienes crean nuevos hash para cada transacción y colocan el hash al final de una cadena de hash de firmas digitales. Las transacciones son verificadas, empaquetadas y ensambladas a la blockchain, a intervalos fijos de tiempo, por servidores independientes, después de realizar un cierto trabajo para resolver un problema matemático complejo.
Como se dijo, el nuevo problema que surge en este modelo sin autoridad central es que el usuario no puede verificar si el dueño hizo otros pagos previos con la misma coin. Podría haber hecho varios pagos! Para este propósito la transacción más antigua es la que cuenta; las posteriores se descartan. Para asegurar la ausencia de una transacción alcanza con tener conciencia (o coincidencia) sobre todas las transacciones que ocurren en la red.
En una red p2p, esto se logra comunicando públicamente las transacciones y acordando un sistema sobre una única y simple historia del orden de llegada de dichas transacciones. Los beneficiarios necesitan una prueba de que al momento de cada transacción, la mayoría de los nodos están de acuerdo sobre que ella fue la primera transacción recibida; es decir, de todos los (doble) pagos que un dueño podría ordenar con la misma coin, el pago más antiguo es el que vale. De este modo quien recibe un pago se asegura que no es un doble pago.
La solución que se propone comienza con un timestamp server. El timestamp server le pone una marca de tiempo al bloque de hash de transacciones, lo hashea y lo publica ampliamente en la red. La marca de tiempo proporciona una prueba de que los datos (las transacciones) existieron al momento de colocarse dentro del hash del bloque; además, dentro de ese hash no hay ningún doble pago. El hash del timestamp contiene el hash del timestamp previo formando así una cadena de hash de timestamp que refuerza los timestamp previos.
HASH: Esquema tomado del paper de Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
Para implementar el timestamp server sobre la base de una red p2p, se necesita implementar un sistema de prueba de trabajo pow que implica escanear un valor que cuando es hasheado con una función hash, este hash comienza con cierto números de dígitos binarios en cero. El trabajo requerido es exponencial con el números de ceros y puede ser fácilmente verificado mediante la función hash. El número de ceros determina la dificultad del trabajo a realizar. Para la red timestamp de Bitcoin, la pow se implementa incrementado el nonce en el bloque hasta que le da al has del bloque el número de ceros requeridos.
POW: Esquema tomado del paper de Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
Tal como se observa en la figura previa, la blockchain puede ser entendida como una base de datos de cadenas de transacciones hasheadas anidadas que están empaquetadas en bloques hasheados anidados que son ensamblados secuencialmente con una marca temporal y una prueba de trabajo que evita el doble pago y vuelve inmutables las transacciones.
Una vez que se ha gastado un esfuerzo de cpu para satisfacer la pow, el bloque queda sellado y ensamblado en la blockchain y no puede ser modificado sin rehacer la pow. Si nuevos bloques son ensamblados después de él, el esfuerzo requerido para hacer cambios en el bloque incluye el esfuerzo de cpu demandado para rehacer todos los bloques posteriores. Esta última exigencia, es una estrategia muy ingeniosa para asegurar la inmutabilidad de los datos de la blockchain.
La pow implementada en la blockchain de Bitcoin también resuelve el problema de las mayorías en la toma de decisiones en redes descentralizadas p2p. Un esquema de consenso 1 ip 1 voto, puede ser fácilmente desvirtuado si un minero coloca a minar varios nodos con distinta ip. Con la regla de decisión 1 cpu 1 voto, la mayoría es determinada por la capacidad de cómputo; así se garantiza la inmutabilidad de la blockchain mientras el cpu de nodos honestos sobrepasa al cpu del atacante deshonesto.
La marca de tiempo y la prueba de trabajo impiden el doble pago y otorgan inmutabilidad a los datos. Si un usuario intenta realizar un doble pago enviando la misma transacción a dos destinos distintos, sólo se aprueba una de esas transacciones. Si un minero verifica ambas transacciones mientras arma su bloque, aprueba la primera transacción y descarta la segunda por falta de fondos. Mientras que si el bloque ensamblado sólo verificó una de las transacciones, entonces la otra pasa para el siguiente bloque en donde se descarta por falta de fondos en la cuenta origen. Así es como los nodos de una red p2p logran ver todas las transacciones.
Si varios nodos trabajan coordinadamente en una red p2p efectuando la misma tarea (ejecutada exactamente por el mismo software) para verificar transacciones a intervalos fijos, el primer nodo que logra completar la pow es el que ensambla el hash de su bloque en la cadena. Al ser ensamblado, el has queda agregado a la blockchain de modo que si algún minero malintencionado de la red quiere cambiar los registros de transacciones para hacer un doble pago, tendrá que gastar la misma cantidad de cómputo para desarmar el bloque y luego realizar otro trabajo para rearmar el bloque y todos los bloques posteriores que se agregaron a la cadena.
Una vez ensamblado un nuevo bloque, todos los demás mineros tendrán que verificar si las transacciones incorporadas en el bloque son genuinas. Si la mayoría de cpu lo ratifica, si la mayoría coopera en la red, entonces el bloque es confirmado y los mineros pasan a verificar transacciones del próximo bloque, con lo cual el posible fork o bifurcación de la cadena generada por el minero maligno queda sin efecto, porque hay una mayoría que continúa ensamblando bloques en la cadena principal y no en la cadena generada por el minero malicioso.
En resumen, para que la transferencia de propiedad funcione en una red p2p, se requiere que la red ensamble en una única cadena de bloques las transferencias de propiedad inicialmente autorizadas por los usuarios. Se necesita armar una base de datos de bloques y no una base tradicional de registros y campos fijos. La lógica es: armar una única cadena que está en todos los nodos y es aceptada por todos ellos. En cada nodo un mismo software verifica transacciones hasheadas y, pasado un tiempo fijo, las sella en un bloque, les pone una marca temporal, hashea el bloque e intenta ensamblar ese hash en la cadena principal luego de una pow previa. El nodo que tiene la mayor capacidad de cómputo es el que logra ensamblar en la cadena el bloque que logró sellar. Los demás mineros, más lentos, certifican si las transacciones empaquetadas son genuinas. Si una mayoría de cpu está de acuerdo con esto, el bloque queda definitivamente ensamblado y se pasa a verificar el próximo bloque. Las transferencias de propiedad así constituidas son genuinas e inmutables.
-Satoshi Nakamoto. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System, satoshin@gmx.com,
https://bitcoin.org.
-Albert Jay Nock. 2009. Nuestro Enemigo El Estado. Traductor: Jorge Antonio Soler. MisesHispano,
https://mises.org/library/book/our-enemy-state.
En la base de datos digital tradicional, se define la moneda digital como una colección de registros contables de intercambios de propiedad, registros contables de pagos. La información contable (centralizada en los bancos) registrada en las cuentas de los usuarios, se va actualizando según un sistema de registros tradicionales (tipo filas y columnas) a medida que los usuarios realizan transacciones --de transferencias de propiedad-- las que son enviadas al servidor del banco para ser certificadas y aprobadas por la autoridad bancaria. Esta actualización es de suma cero estricta --SzS-- en el sentido en que la cantidad de dinero digital que sale de una cuenta (un pago) va a parar a otras cuentas no más de una única vez; es decir que, seleccionada una cantidad de moneda digital, no es posible usar esa cantidad para hacer pagos duplicados, por lo que no hay doble pago.
Esto es así porque a la moneda digital la acuña el banco. El usuario envía sólo la orden de transacción, de transferencia de propiedad, pero es el banco el que acuña el registro contable y confirma, o no, la trasferencia de propiedad de la moneda. Así, este modelo de control implementado en el servidor del banco, evita el doble pago en el sentido en que no es posible hacer el cambio correspondiente de un mismo registro más de una vez. Lo que llega al servidor es una orden de cambio de registro pero el cambio no se hace sin chequear si hay fondos disponibles. La autoridad es consciente del orden de llegada de todas las transacciones porque las ve a todas ellas; por esto puede identificar peticiones duplicadas y autorizar sólo una de ellas.
En la otra base de datos, Satoshi define la electronic coin como una cadena de firmas digitales. Aquí también se cumple la suma cero, pues contiene la misma información de pagos, pero se administra de manera distinta; el chequeo SzS se hace usando un modelo que es independiente de una autoridad que autoriza pagos. Como se ve en el esquema de abajo, cada dueño transfiere (la propiedad de) la coin al próximo dueño firmando digitalmente un hash que contiene el hash de la transacción previa y la cuenta pública del próximo dueño; luego agrega este hash al final de la coin. Por esto, un usuario del sistema puede chequear las firmas para verificar la cadena de propiedad.
TXS: Esquema tomado del paper de Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
En un esquema descentralizado, en una red p2p, es en la instancia de transacción donde se define la electronic coin, es ahí donde se autoriza el evento de transferencia de propiedad. En ninguna otra instancia ocurre este evento. Esta transacción es empaquetada en un hash y enviada al nuevo dueño. Será tarea de los nodos de la red verificar si las transacciones son genuinas y generar las condiciones para evitar el doble pago. En estos servidores todas las transacciones se empaquetan en un bloque que se ensambla a una cadena de bloques técnicamente llamada blockchain.
En una blockchain no se van actualizando los campos de las cuentas como si fueran registros contables digitales, sino que son los dueños de la coin quienes crean nuevos hash para cada transacción y colocan el hash al final de una cadena de hash de firmas digitales. Las transacciones son verificadas, empaquetadas y ensambladas a la blockchain, a intervalos fijos de tiempo, por servidores independientes, después de realizar un cierto trabajo para resolver un problema matemático complejo.
Como se dijo, el nuevo problema que surge en este modelo sin autoridad central es que el usuario no puede verificar si el dueño hizo otros pagos previos con la misma coin. Podría haber hecho varios pagos! Para este propósito la transacción más antigua es la que cuenta; las posteriores se descartan. Para asegurar la ausencia de una transacción alcanza con tener conciencia (o coincidencia) sobre todas las transacciones que ocurren en la red.
En una red p2p, esto se logra comunicando públicamente las transacciones y acordando un sistema sobre una única y simple historia del orden de llegada de dichas transacciones. Los beneficiarios necesitan una prueba de que al momento de cada transacción, la mayoría de los nodos están de acuerdo sobre que ella fue la primera transacción recibida; es decir, de todos los (doble) pagos que un dueño podría ordenar con la misma coin, el pago más antiguo es el que vale. De este modo quien recibe un pago se asegura que no es un doble pago.
La solución que se propone comienza con un timestamp server. El timestamp server le pone una marca de tiempo al bloque de hash de transacciones, lo hashea y lo publica ampliamente en la red. La marca de tiempo proporciona una prueba de que los datos (las transacciones) existieron al momento de colocarse dentro del hash del bloque; además, dentro de ese hash no hay ningún doble pago. El hash del timestamp contiene el hash del timestamp previo formando así una cadena de hash de timestamp que refuerza los timestamp previos.
HASH: Esquema tomado del paper de Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
POW: Esquema tomado del paper de Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
La pow implementada en la blockchain de Bitcoin también resuelve el problema de las mayorías en la toma de decisiones en redes descentralizadas p2p. Un esquema de consenso 1 ip 1 voto, puede ser fácilmente desvirtuado si un minero coloca a minar varios nodos con distinta ip. Con la regla de decisión 1 cpu 1 voto, la mayoría es determinada por la capacidad de cómputo; así se garantiza la inmutabilidad de la blockchain mientras el cpu de nodos honestos sobrepasa al cpu del atacante deshonesto.
La marca de tiempo y la prueba de trabajo impiden el doble pago y otorgan inmutabilidad a los datos. Si un usuario intenta realizar un doble pago enviando la misma transacción a dos destinos distintos, sólo se aprueba una de esas transacciones. Si un minero verifica ambas transacciones mientras arma su bloque, aprueba la primera transacción y descarta la segunda por falta de fondos. Mientras que si el bloque ensamblado sólo verificó una de las transacciones, entonces la otra pasa para el siguiente bloque en donde se descarta por falta de fondos en la cuenta origen. Así es como los nodos de una red p2p logran ver todas las transacciones.
Si varios nodos trabajan coordinadamente en una red p2p efectuando la misma tarea (ejecutada exactamente por el mismo software) para verificar transacciones a intervalos fijos, el primer nodo que logra completar la pow es el que ensambla el hash de su bloque en la cadena. Al ser ensamblado, el has queda agregado a la blockchain de modo que si algún minero malintencionado de la red quiere cambiar los registros de transacciones para hacer un doble pago, tendrá que gastar la misma cantidad de cómputo para desarmar el bloque y luego realizar otro trabajo para rearmar el bloque y todos los bloques posteriores que se agregaron a la cadena.
Una vez ensamblado un nuevo bloque, todos los demás mineros tendrán que verificar si las transacciones incorporadas en el bloque son genuinas. Si la mayoría de cpu lo ratifica, si la mayoría coopera en la red, entonces el bloque es confirmado y los mineros pasan a verificar transacciones del próximo bloque, con lo cual el posible fork o bifurcación de la cadena generada por el minero maligno queda sin efecto, porque hay una mayoría que continúa ensamblando bloques en la cadena principal y no en la cadena generada por el minero malicioso.
En resumen, para que la transferencia de propiedad funcione en una red p2p, se requiere que la red ensamble en una única cadena de bloques las transferencias de propiedad inicialmente autorizadas por los usuarios. Se necesita armar una base de datos de bloques y no una base tradicional de registros y campos fijos. La lógica es: armar una única cadena que está en todos los nodos y es aceptada por todos ellos. En cada nodo un mismo software verifica transacciones hasheadas y, pasado un tiempo fijo, las sella en un bloque, les pone una marca temporal, hashea el bloque e intenta ensamblar ese hash en la cadena principal luego de una pow previa. El nodo que tiene la mayor capacidad de cómputo es el que logra ensamblar en la cadena el bloque que logró sellar. Los demás mineros, más lentos, certifican si las transacciones empaquetadas son genuinas. Si una mayoría de cpu está de acuerdo con esto, el bloque queda definitivamente ensamblado y se pasa a verificar el próximo bloque. Las transferencias de propiedad así constituidas son genuinas e inmutables.
-Satoshi Nakamoto. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System, satoshin@gmx.com,
https://bitcoin.org.
-Albert Jay Nock. 2009. Nuestro Enemigo El Estado. Traductor: Jorge Antonio Soler. MisesHispano,
https://mises.org/library/book/our-enemy-state.
No hay comentarios:
Publicar un comentario