El año 2018, que ha pasado, se había llegado a la cúspide y, quizá, iniciado el declive consiguiente de la palabra de moda “blockchain”. No solo esto, sino que como natural evolución ha surgido el término DLT, que en teoría es un super-conjunto de todo lo anterior. Es decir que “Distributed Ledger Technology” (DLT) se convierte en una característica tecnológica que hace que un sistema “blockchain” obtenga mayor atractivo al alejarse del concepto de consenso y otras características de esas divisas virtuales oscuras que se usan para las drogas y el tráfico. Una suerte de certificación en la que da lo mismo si te pasaste estudiando el tema por 4 años o solo viste un vídeo de YouTube y aprobaste el examen. Antes de todo quiero decirle amable lector que Bitcoin no es ni “blockchain”, ni “DLT”; y voy a explicar el porqué, naturalmente.
Incluso cuando tanto ni el código de Bitcoin o el artículo original de Satoshi Nakamoto mencionan por algún lado el término “ledger”, algunas personas mal atribuyen la característica de registro distribuido, libro mayor o de “blockchain” a Bitcoin.
Time chain
Ciertamente Bitcoin dentro de las estructuras de datos que utiliza ha inventado lo que se conoce ahora como cadena de bloques, y que es precisamente eso, una cadena de bloques. Es decir bloques enlazados unos con otros formando una cadena desde el bloque génesis o bloque cero hasta este momento en que tenemos el bloque número 569940. Sin embargo, quizá se pregunte ¿cuál es el propósito de este artificio tecnológico?
El propósito de la cadena de bloques no es, como se cree, el que todos los nodos posean la misma información. Su propósito es el de ser una marca de tiempo, un contador, que diga que viene primero, qué segundo y qué tercero. Satoshi Nakamoto ha buscado con este mecanismo el resolver el problema del doble gasto, ordenando las transacciones en bloques de manera que exista una secuencia desde el bloque origen o génesis.
Es precisamente por esta razón que esta estructura de datos originalmente se ha llamado “Time chain” o cadena de tiempo, como se puede observar en la imagen de una captura de pantalla del código original de Bitcoin que Satoshi había implementado.
Allí Satoshi explica en el comentario de la clase CBlock:
Los nodos reúnen nuevas transacciones en un bloque, obtienen su hash y las ubican en un árbol hash, y buscan valores nonce para hacer que el hash del bloque satisfaga los requisitos de la prueba de trabajo. Cuando resuelven la prueba de trabajo anuncian el bloque y el bloque se añade a la cadena de tiempo. La primera transacción en el bloque es de un tipo especial que crea una nueva unidad cuyo dueño es el creador del bloque.
¿Cómo es que se resuelve el problema de doble gasto con este mecanismo? Haciendo que cada transacción se registre una vez y que si se detecta una transacción idéntica posterior, incluso segundos después, se le rechace y no se procese, puesto que ya se ha registrado una previamente. Hasta antes de Bitcoin esto era muy difícil de resolver y las entidades financieras siempre han tenido formas de gestionarlo, mas no resolverlo, trasladando el costo al cliente final, por supuesto.
¿Y qué pasa con el libro mayor?
Pues, para empezar, podemos citar nuevamente el comentario del código.
las nuevas transacciones se reúnen en un bloque, se obtiene su hash y se ubican en un árbol hash.
Esto quiere decir que un bloque solo contiene como datos un árbol hash.
El tamaño de un bloque definido en el código es de 1MB, aunque luego de la activación de SegWit puede ser mayor, en promedio cerca de los 2MB efectivos. En su estructura cada bloque tiene 5 campos, donde los primeros 4 no superan los 100 bytes. Esto significa que, en el mejor de los casos, quedan 1.9999MB para la estructura de árbol hash de transacciones.
Estas transacciones, por supuesto representan el pasado y no tienen como objetivo el ser un registro contable. Sin entrar en detalles sobre si hablamos de asientos de doble o triple entrada, la cadena de bloques no busca tampoco representar el estado de las cosas bajo el concepto de cuentas. Es decir, no es una base de datos que podamos consultar para saber quién tiene que.
El espacio de UTXO
En Bitcoin el estado de las cosas se representa a través del conjunto de UTXO. Una “Unspent Transaction Output” (UTXO) es la representación de un elemento o pedazo del estado. El balance de Bitcoin de una llave privada se calcula, por tanto, sumando todos los UTXO que esta clave puede gastar. Cuando se efectúa una transacción nueva se utilizan todos los UTXO disponibles para una llave privada y se genera dos o más UTXO. Uno que es la transferencia de fondos a una dirección tercera y otro, como mínimo, devolviendo el restante al propietario. Por la naturaleza de Bitcoin las UTXO se generan del lado del cliente, por esto pueden existir UTXO que no se anuncian a la red (transacciones “off-chain”), UTXO que se pagan de acuerdo a la lógica de “scripts” o programas, y las propias “coinbase” que no tienen UTXO de entrada.
El estado global de Bitcoin está definido, entonces, por el conjunto de UTXO de un momento dado. Las transacciones solo representan cambios en el conjunto de UTXO, donde se utilizan antiguos para crear nuevos. Las UTXO no están registradas en ninguna parte salvo en el cliente local para su propio sub-conjunto variable de UTXO. No existe, por tanto, un lugar en donde saber quién tiene que; y, por eso, en ningún caso el estado de las cosas se puede entender en base al registro de las transacciones en los bloques o de acuerdo a un modelo basado en cuentas y balances.
¿Qué pasa entonces con lo de distribuido, resistente a la censura, inmutable, etc.?
Todas esas propiedades están. Pero no como se les visualiza usualmente. La red Bitcoin se basa en un protocolo entre pares (p2p), lo cual significa que cada nodo se conecta a otros nodos directamente, sin un lugar central que determine los miembros aprobados o dados de alta. Esta red sirve para la propagación de datos de los bloques y las transacciones.
mempool de transacciones
La mempool es el grupo de transacciones anunciadas en la red y que se difunde a todos los nodos a través de un mensaje de tipo “broadcast”. Estas transacciones están a la espera de ser incorporadas en el siguiente bloque de manera que se llegue a cumplir un nivel de certeza de que no serán revocadas. En el caso de los nodos completos, que no generan nuevos bloques, la “mempool” sirve para conocer las nuevas transacciones y efectuar alguna operación con ellas, por ejemplo, anunciarlas en la interfaz gráfica, registrarlas en alguna base de datos para posterior análisis o como historial (explorador de transacciones).
En términos prácticos es también el único modo de conocer transacciones o movimientos de fondos entre cuentas que no son las tuyas, o las que gestiona tu par de llaves privada/pública. No existe en el protocolo o en la interfaz API de Bitcoin una orden que permita saber directamente el balance de una dirección pública.
bloques, reorganizaciones y bifurcaciones
Cuando se genera un nuevo nodo completo los bloques se descargan de los pares a los que el nodo está conectado. Sin embargo, cada nodo es independiente. Y aquí también, como en las matemáticas, ofrezco otro contra-ejemplo del porqué no se puede hablar de “libro mayor”, o “ledger”.
Cada nodo es independiente en cuanto a las reglas que quiere ejecutar. Existen reglas de la red que pueden ocasionar bifurcaciones o simplemente una reorganización. Sin entrar en el detalle técnico, aunque si quiere leer más al respecto adelante; podemos señalar que existen casos en que el cambio de reglas en cada nodo puede ocasionar una partición en la cadena, a menos que todos los nodos participantes actualicen el software. Por otro lado, cada nodo también está en capacidad de crear su propia cadena en paralelo y no anunciarla hasta que así lo considere. Esto generalmente se intenta hacer (porque no es tan sencillo de llevarlo a la realidad) con el objeto de efectuar algún ataque de mayoría de “hashpower”, o poder de generación de hashes, que tiene por objetivo re-escribir bloques que ya fueron incorporados en la cadena para poder gastar UTXO doblemente.