sirpask
Será en Octubre
- Desde
- 16 Oct 2009
- Mensajes
- 51.272
- Reputación
- 115.558
Blockchain para Superdummies
Blockchain? Si, claro. Eso es lo de las Bitcoins, no? mmmm pues bueno. Si.
Pero además es un estupendo buzzword del que muchos hablamos, incorporamos a nuestro discurso (he estado en reuniones donde se planteaba la creación de comisiones de Blockchain ) y pretendo explicarlo un poco en este post pos veraniego de forma cero técnica. Es más, casi consigo que mi progenitora, una señora de edad indeterminada (la que ella quiera), entienda el concepto básico (eso, o la inmensa paciencia de una progenitora con el friki de su hijo)
Al final del post comento igualmente donde reside el interés de Microsoft en la plataforma Blockchain y Azure en el mundo de la empresa.[https://i]
Y lo mejor es recurrir en la medida de lo posible a ejemplos cotidianos.
Ya que acabamos de terminar el verano, supongamos, y es un suponer, que mi hija mayor se hubiera ido alegremente de vacaciones con sus amigos, y debido a algunos contratiempos (aunque a mi me parecieran más que previsibles: gasolina, comida.. vamos… llamadme vidente ) se ha quedado sin dinero antes de lo previsto, y si quiero tenerla de vuelta en algún momento, tendré que tras*ferirle dinero para el viaje de regreso. Tras valorar los pros y contras de tenerla de vuelta*[https://s]*(pobrecita, ella sabe que es broma), decidimos hacerle esa tras*ferencia de 20€.
Es mi hija, hay confianza, hay voluntad de hacer esa tras*ferencia, y por parte de ella, sin duda, de recibirla. Pero aun así, yo estoy en Madrid, mi hija en Cádiz, y necesitamos de un tercero que “bendiga” esa tras*acción. La Bendición consiste en comprobar que yo soy yo, que tengo más de 20€ en mi cuenta, que tengo la voluntad de dárselos a mi hija, que mi hija los acepta (lo garantizo si más ciencia de por medio), que se suman en su cuenta y que desaparecen de la mía.
Ese tercero, mi banco en este caso, en el que apenas pongo un pie por cierto (todo lo hago on line), y que bien podría cambiar de un día para otro a golpe de click, habrá creado en algún momento un apunte donde quede registrado que:
El 5 de Agosto del 2017, Héctor tras*firió 20€ a Marina.
Esto solo lo sabemos Yo, el Banco y por supuesto Marina.
Nadie ha tocado un billete (ni mi hija, que lo utilizó para echar gasolina y pago desde su tarjeta de debito). Es decir, lo único que realmente ha ocurrido es la creación de un apunte en un registro creado por un tercero, el banco, en el que todos hemos acordado confiar.
Es decir, que para establecer una relación de confianza entre mi hija Marina y yo hemos dependido de un tercero. Sin valorar la confianza o no que podamos tener en ese tercero, todo comienza con la pregunta… ¿Por qué? ¿No hay alguna otra forma en la que podamos crear y mantener ese registro, que al final parece ser lo más importante, sin que un único tercero en concreto tenga que hacerlo por nosotros?
Adicionalmente, alguien podría pensar que la ubicuidad física del banco, existencia de cajeros, etc, es un valor importante. Bien. Es cierto, aunque en este caso concreto, no hiciera ninguna falta. Y es que es evidente que la posibilidad de tras*misión de información, cualquier tipo de información, de un punto a otro en plena era Internet NO solo está al alcance de una entidad financiera.
Pues como podemos ir adivinando, la respuesta a esta situación que hemos planteado respecto a la “vida” de ese registro, se basa en Blockchain.
Volvamos a Marina y a su Padre, que soy yo.[https://i]
¿Tenemos alguna forma de no depender de un único tercero de confianza para crear y mantener ese maldito registro de los 20€? Pues si. La forma es depender de muchos.
Es decir, tiene que haber mucha más gente que no quiera depender de un solo tercero de confianza en sus tras*acciones, y que además estén dispuestos a mantener una*tras*parencia*insólita respecto a los movimientos de sus finanzas, en la misma medida que lo hago yo.
Es decir, no solo Marina y yo compartiremos la información de ese registro de los 20€ que le tras*ferí, sino que esa información la compartimos además con toda esa comunidad que ha decidido, al igual que nosotros, confiar en este nuevo sistema de confianza en lugar de en una sola entidad (bancaria, en este caso).
Ahora todos los que participamos en este mecanismo sabemos que Héctor le hizo una tras*ferencia de 20€ a Marina el 5 de Agosto del 2017 porque TODOS tenemos una copia idéntica de ese registro donde se van anotando las tras*acciones.
En esa hoja aparece que Héctor le hizo una tras*ferencia a Marina de 20€, pero también que Pilar se la hizo a Andrés de 45€, que Juan recibió una tras*ferencia de Manuel de 2500€ ….. etc… Y esa hoja, con TODOS los apuntes que vamos anotando, está en poder de TODOS.
Todos han podido ver mi intención de tras*ferir 20€ a Marina, y ver que previamente tenía al menos esa cantidad en mi cuenta para poder hacerlo. Y todos han tomado nota en sus registros de esta tras*acción. En ese momento, la tras*acción ya está completa y es efectiva. Enhorabuena Marina. De vuelta a casa.
Creo que es bueno adelantar, llegados a este punto, y ante el más que probable susto que algún lector habrá sentido al leer cosas como “tras*parencia insólita de mis finanzas”, “todos sabemos lo de todos”, “ todos han podido ver mi tras*acción a Marina” etc.. que estoy utilizando identidades de personas para facilitar la compresión del mecanismo y solo con fines didácticos. En la realidad, las identidades de los usuarios de blockchain no están asociadas ni almacenan ninguna información sobre la identidad física y real de las personas. Son un*pseudónimo. Una identidad en blockchain no será más que una clave pública (elemento fundamental en los sistemas de criptografía asimétrica pero que obviamente no es el objetivo de este post explicarlo aquí) sin asociación a ninguna identidad física. De hecho es común que una misma persona pueda utilizar diferentes identidades en Blockchain por motivos o propósitos diferentes.[https://betanews]
Volvamos al ejemplo. Muchos pensareis que la cantidad de registros que tenemos que ir copiando todos es enorme. Y en efecto lo es. Por eso cada vez que completamos una hoja con un número determinado de registros, la cerramos, la almacenamos, y abrimos una nueva para seguir apuntando nuevas tras*acciones y registros.
El proceso de ir cerrando y almacenando esa pila de hojas de registros es muy importante. Ahí reside la memoria histórica de todo lo que ocurre en el sistema y por tanto de ello depende su futura consistencia y fiabilidad.
Por eso lo mejor es que esas hojas con los registros que vayamos completando, apilando y almacenando, los protejamos adecuadamente.
Para ello todos hemos decidido utilizar un mecanismo para proteger esa información según la vayamos almacenando. Pero… ¿Protegerla de qué?
¿Qué es lo peor que podría pasarle a esa información almacenada para que el sistema se viniera abajo?
¿Vulnerar la confidencialidad de esa información? Noooo. Hemos dicho que todos conocemos las tras*ferencias que todos han hecho y recibido.
¿Qué alguien la robe? ¿Perdón? Tenemos millones de copias. Al menos cada persona tiene o ha tenido una copia ….
¿Qué alguien vulnere su integridad, es decir, que modifique algún registro? ¿Os imagináis que alguien pudiera generar nuevos registros falsos?¿O duplicarlos llevando el sistema a situaciones de “doble gasto” (en este caso los mismos 20€ utilizados no solo por Marina, sino también por.. ¿Nadia? desde la más árida estepa Siberiana?) Eso si sería un problema. Bueno, mas bien eso sería EL PROBLEMA.
Por tanto pensemos de que forma garantizamos entro todos la INTEGRIDAD de esos registros almacenados. Es decir, como nos aseguramos que esa información permanece inalterable bajo 7 llaves (de ello depende todas las garantías que sustentan el sistema).
Sin eso, todo se desmoronaría como un castillo de naipes. Si alguien consiguiera sustituir los 20€ de Marina por 20000€, el sistema ...y yo... nos resentiríamos de fin. O si nuestra Nadia consiguiera gastarse los mismos 20€ de Marina, pero en polvorones “La Estepa” al otro lado del mundo, el sistema simplemente ya no nos serviría para nada.
Es por eso por lo que este mecanismo de protección de la integridad de los registros es sin duda la piedra angular de todo el mecanismo y donde reside parte de la sofisticación del sistema Blockchain.
Hasta aquí, tecnología cero.
Pero ahora si hace falta entender un sencillo concepto ampliamente conocido para cualquier ingeniero o matemático, pero probablemente desconocido para personas menos técnicas. Lo llamaremos algo así como “la prueba del 9” de que algo no ha sido modificado (la he llamado así para seguir manteniendo enganchado a cualquier lector no técnico, igual que la podría haber llamado la “función chivata” o cualquier otra cosa). En este caso, la garantía de que todas las hojas almacenadas permanecen integras y nadie ha modificado ningún dato. Esa “prueba del 9” de la integridad (o P9 que llamaré a partir de ahora), se llama función de Hash (Lo sé, es obvio para muchos, pero intento dejarme en el camino al menor número de personas).
Dejando de lado toda la criptografía asociada a esa función, recordemos que pretendemos ser cero técnicos, sepamos que esa función se caracteriza por devolver un resultado diferente y único a una entrada concreta. Es decir, si a nuestra función “Prueba del 9” le damos como dato de entrada el número 20, nos devuelve un resultado. Por ejemplo, y me lo invento, el resultado es este palabro: Xds21Wa.
Y SIEMPRE que presentemos el número 20 a la función, nos dará el mismo resultado: Xds21Wa. Y será único. Es decir, ningún otro número de entrada a la función dará el mismo resultado.
Por otro lado, no hay forma de aplicar esa función en sentido contrario. Es decir, si nos dan el palabro Xds21Wa, nunca podremos deducir que viene del número 20. Tan solo podremos confirmar una y otra vez que dando como entrada el número 20, SIEMPRE obtenemos Xds21Wa.
Por qué es útil esto? Porque si aplicamos esta función “prueba del 9” a la famosa hoja de registros almacenados cuya integridad queremos proteger a toda costa, obtendremos un resultado diferente para cada hoja. ¿Y si alguien modificara un registro de esa hoja? Pues nuestra función “prueba del 9” daría un valor diferente.
Es decir si aplicamos “Prueba del 9” a nuestra hoja número 324, nos dará el resultado único de R34t%6dg (me lo acabo de inventar de nuevo). Y cualquiera, en cualquier lugar del mundo que aplique la función “Prueba el 9” a la Hoja 324, obtendrá idéntico resultado (R34t%6dg).
Si alguien hábilmente modifica un registro de nuestra Hoja 324, al aplicar la función “Prueba del 9” dará un resultado distinto a R34t%6dg, dejando en evidencia ante todos, porque todos podemos efectuar esa operación, que algún registro ha sido modificado. Por tanto, no admitiremos esa modificación.
El Sudoku es un buen ejemplo para entender el concepto detrás de estas funciones: difícil de resolver, pero muuuyyy sencillo de comprobar por cualquiera.
Releyendo hasta aquí creo que no habré perdido a nadie por el camino. Pero vamos a complicarlo solo un poquito, de verdad, con tres operaciones nuevas:
Primera: Supongamos que nos inventamos una condición al resultado de aplicar la función “Prueba del 9”.
Por ejemplo ¿Cuántos números, A, me darán como resultado de aplicarles la función “prueba del 9”, un resultado que empiece, por ejemplo, por “1234”? Es decir, algo así:
P9(A)=1234...
Ufff. Pues me parece que no nos va a quedar más remedio que comenzar a probar números y números a lo bruto para ver cuáles de ellos dan como resultado algo que empiece por “1234”. Y es que no hay una forma aritmética de deducirlos porque precisamente las funciones de Hash (nuestra función “Prueba del 9”) están diseñadas para que no sea posible deducir el número de entrada de una función, dado el resultado.
Por tanto creo que estaremos de acuerdo que solo podemos hacerlo por*fuerza bruta. Es decir, comenzando a introducir números y números y números en nuestra función “prueba del 9” e ir quedándonos con aquellos cuyo resultado haya comenzado por 1234. Es importante entender en este punto que lógicamente esto requerirá un esfuerzo computacional, verdad?
Al final, de tanto probar y probar, habremos encontrado por ejemplo que nuestra Función “prueba del 9” aplicada al número, por ejemplo, 39874, nos ha dado el resultado*12349845.
Por tanto el número 39874 cumple la condición.
Y resulta que la función “prueba del 9” aplicada al número 3909001, también nos ha dado como resultado el numero*12349082375, cumpliendo igualmente la condición que habíamos definido.
Es decir, de todos los números que hemos ido probando hasta este momento, ya hemos encontrado dos, el 39874 y el 3909001, que cumplen la condición de dar como resultado un número que empiece por 1234. Pues bien, podemos seguir buscando.
Segunda: Vamos a añadir un pequeñísima dificultad en este proceso. No se trata más que de prestar un poco de atención a ese dato de entrada de nuestra función “Prueba del 9”. Vamos a cambiar ese dato de entrada por una suma de dos datos en lugar de un solo dato, ok? Es decir, en lugar de hablar de un número, al que se le aplica la función “Prueba del 9”, y que nos da un número que cumple la condición de comenzar por 1234, hablaremos de una suma de dos números a los que le aplicamos la función “prueba del 9”. Algo así como:
P9(A+B)=1234…..
Es decir, nuestra función “Prueba del 9”, que aplicada a la suma de A más B, cumpla la condición de dar un número que comience por 1234, ok?
Ya nos habremos dado cuenta de que el número de soluciones será infinito a no ser que fijemos el valor de uno de los dos números. Hagámoslo. Fijamos el valor de A=20, por ejemplo.
Ahora tengo que aplicar la función “prueba del 9” a la suma de 20, el valor de A, más un número B para que nos de un número que comience por 1234, ok?. Algo así:
P9(20+B)=1234….
Ahora tendríamos que probar en nuestra función “prueba del 9” un montón de valores de B para que, sumados a 20, nos de como resultado un número que cuando se le aplique la función P9, cumpla la condición de empezar por 1234, ok?
Bueno. No parece una complejidad muy grande respecto a lo anterior, verdad?. Pero en este caso es interesante ver que estamos encontrando una bonita relación casi romántica obsesiva entre un par de números, convirtiéndose uno en el “guardián” del otro. B guardará la integridad de A, y A guardará la integridad de B.
Es decir, podríamos decir que la integridad de A esta garantizada por B. Si alguien modificara A, al sumarse con B y aplicar a la suma nuestra función “prueba del 9”, daría un número que no comenzaría por 1234, dejando en evidencia la vulneración de la integridad de A. Y Viceversa.
Podríamos decir que B se convierte en el garante de la integridad de A.
Si volvemos por fin al ejemplo del registro de la olvidada tras*acción que hice a mi hija Marina por importe de 20€, podemos identificar esa tras*acción como la tras*acción A, y B será el guardian de que nadie modifique esa tras*acción. Si alguien modificara esa tras*acción A, al añadirle el valor de B (su guardian), veríamos que al aplicar la función “prueba del 9” a la suma, el resultado no cumpliría la condición de comenzar por 1234 (en un caso real la condición es diferente a esta simpleza que nos hemos inventado de que el resultado comience por 1234… , pero seguro que el ejemplo ha sido útil para entender todos estos conceptos básicos.* En la realidad, las condiciones tienen que ver con el numero de "ceros" con el que comience el resultado)
Es decir, en el sistema de Blockchain, todos los participantes pueden comprobar de forma autónoma que B es el guardián de A, y que si se modifica cualquiera de ellos, el otro evidenciará esa vulneración de la integridad. Parece que la información de mi tras*acción a Marina está a salvo y hay mucha gente que está de acuerdo.
Tercera. Si hemos llegado hasta aquí sin perdernos, esto ya está hecho. Pero nos falta un pequeño detalle. La tras*acción que hice a Marina, la tras*acción A, ya está hecha, guardada, almacenada, bendecida con su clave B que impide que nadie pueda modificarla. Pero ¿Y si alguien estuviera muy interesado en modificar ese registro A, que podría hacer? Pues se me ocurre que podría realizar la modificación deseada en A, y volver a calcular un nuevo número B que sumado a A cumpliera de nuevo la condición de arrojar un resultado que comenzara por 1234. Hago la sustitución de A y B por sus nuevos valores, y ya está. El sistema vulnerado*[https://s]. Pues vaya… ¿Para este corto viaje tantas alforjas?
¿Cuál ha sido el problema y como podríamos resolverlo? Básicamente, no podemos tratar las tras*acciones como hechos aislados, sin ningún tipo de conexión entre si. Todo el mecanismo que hemos descrito nos ha servido para garantizar la integridad de cualquier registro en particular de forma autosostenida, y que todos los demás puedan verlo, pero independientemente de la existencia del registro vecino. De esa forma, se podría manipular y vulnerar un registro aunque no sin cierta dificultad.
Llegados a este punto, estaría muy bien que pudiéramos introducir un nuevo elemento que nos relacione mi tras*acción A, no solo con esa especie de sello o guardian que hemos llamado B hasta ahora, sino que también lo hiciera con otra tras*acción vecina, que a su vez también estaría relacionada con otra, y esta con otra… y si… aquí aparece por primera vez el por que de la palabra “cadena”, chain, en esta tecnología.
En este escenario, modificar un registro significaría modificar tooooda la cadena de registros vecinos….. y eso ya tiene muy pocas probabilidades de poder realizarse, verdad ?.
Es decir, ese nuevo elemento que nos relacione un registro con el registro vecino lo vamos a llamar C, ok? Y que mejor que representar a ese registro vecino que con el resultado de su “prueba del 9”?
De esta forma la integridad de cada registro A estará custodiada no solo por ese guardian B, sino que también por ese otro valor de C que depende del registro vecino. Es decir, que el registro A que recoge la información de la tras*ferencia de 20€ que le hice a Marina está custodiada por ese clave B que definíamos anteriormente, pero que a su vez depende de otro elemento C que nos trae información sobre el registro vecino, en este caso el de la tras*ferencia que Juan le hizo a Mónica por valor de 1500€…. por ejemplo.
Es decir, antes teníamos que P9(A+B)= 1234….. donde A es el registro a proteger, y B tenía que ser calculado para cumplir la condición de dar un número que comenzara por 1234. Ahora tenemos que:
P9(A+B+C)=1234…..
donde A es de nuevo el registro a proteger, B tendrá que ser de nuevo calculado y C es el resultado de aplicar P9 al registro anterior. Es decir, también un número que comenzaría por 1234…. en nuestro ejemplo.
De esta forma, la protección de cada registro depende de parámetros del registro anterior. Si alguien quisiera modificar el registro A utilizando ese truquillo descrito al principio de este punto, tendría que modificar el contenido de A, calcular la clave de protección B de todos los registros siguientes para mantener la consistencia del sistema. Y eso ya es bastante más que improbable que suceda (aunque un ejercicio teórico en el que todos los participantes del sistema blockchain, ¿millones? nos volviéramos malos malísimos, y diéramos por buena esa cadena inconsistente, se podría llevar teóricamente el sistema al traste).
*
Y ya para terminar, incorporemos otro concepto fundamental. Hemos hablado con bastante ligereza de aplicar funciones (nuestra manida “prueba el 9”), calcular números que cumplan condiciones etc.. Y además estos cálculos son imprescindibles para ir “sellando” los registros con esas claves B que hemos ido comentando. El sistema necesita esas claves.
Pues bien, el esfuerzo computacional para realizar estos cálculos no es menor. Es muy intenso. Probar millones de entradas con nuestras función de hash (Prueba del 9) para ver cuales nos devuelven un resultado que cumpla una determinada condición (empezar por 1234), requiere mucha capacidad de proceso …. y algo de suerte*[https://s].
En un sistema descentralizado como este nos podemos preguntar, ¿Quién lo hace? ¿Y por que lo va a hacer?
La respuesta a la primera pregunta es clara: cualquiera de los participantes en el sistema de Blockchain lo puede hacer (siempre y cuando cuente con alguna capacidad de proceso). Pero siendo un proceso que requiere unos cálculos intensos, que acarrean gastos importantes en tiempo y energía, proceso, por que alguien querría hacerlo? ¿Altruismo? ¿experimentación? Pues la respuesta a ello es una recompensa tan poco original, como genial en este caso….: dinero.
Si, dinero, pero como no podría ser de otra forma, en forma de Bitcoins.
De hecho, el Bitcoin, como cualquier otra moneda, circula, se tras*fiere, se gasta, se compra, se invierte, se cambia, se regala, se roba, se ….. todo. Pero ¿Cómo se crea? O utilizando términos apropiados ¿Cómo se acuña? No existe un Banco Central que “fabrique moneda”, no. La única forma de crear Bitcoin de la nada e inyectarlos en el sistema es trabajando para el sistema ¿Cómo? Aportando potencia de cálculo para obtener esas claves B que nos vayan cerrando y guardando los registros, y que como hemos visto, son imprescindibles para la seguridad e integridad de todo el mecanismo. Si habíais oído el término “minar Bitcoins”, ya sabéis a que se refiere, por qué se hace y que se obtiene a cambio. Este esfuerzo computacional es a lo que se le denomina una*prueba de trabajo, concepto fundamental en el mundo Bitcoin/Blockchain.
En el proceso de minar Bitcoins, se da el dicho de “the First takes it all”. El primero que consigue una clave B válida, es decir que cumple la condición de P9(A+B+C)=1234…, cerrará ese registro, se lleva toda la recompensa y continuara trabajando simultáneamente sobre el resto de registros.
El sistema autoregula de forma automática el factor de dificultad de la condición a cumplir para sellar un registro (cálculo de B). Si la condición “número que comienza por 1234” comienza a ser demasiado sencilla, pongo por caso, y se tarde menos de 10 minutos de media en el cálculo de B, se incrementa automáticamente la dificultad de la condición a cumplir, por ejemplo, cambiándola por “comenzar por 12345” (recordar que es un ejemplo didáctico. En la realidad hablaremos de añadir "ceros" a la condición)
En relación a su implementación tecnológica, es interesante igualmente exponer que todo el código fuente de Bitcoin es*software libre*(bajo una licencia libre permisiva no-copyleft), que es un proyecto de código abierto tras el que no hay nadie detrás, que cualquiera con las skills adecuadas puede participar, que nadie lo controla, sino que se gestiona en github y listas de correo públicas como cualquier otro proyecto de software libre.
Y en relación a su utilización, es obvio que no hay que conocer NADA de lo que he descrito en este post para ser un feliz usuario de Bitcoins, blockchain o de cualquier otro proyecto basado en esta tecnología.
Se habla mucho del uso de la tecnología de Blockchain en el ámbito empresarial, si bien algunas de sus caractaerísticas diseñadas originalmente para funcionar en un ámbito absolútamente público, descentralizado y sin gobierno, como característica fundamental de su disño, necesitan de alguna modificacón en términos de goberbnanza, confidencialidad o rendimiento,* para que se uso pueda ser ampliamente aceptado en el mundo de la empresa.[http://guiabitcoin]
Lo escenarios de la empresa que miran a Blockchain como una solución importante a muchos retos, tienen que ver no solo con las criptomonedas o sector bancario. Hablamos de ámbitos de tras*ferencias, registros, seguros (caso*Microsoft & Maersk) votaciones, seguimiento de productos y servicios, internet de las cosas, contratos inteligentes, previsiones, musica on line, compartición de vehículos, compra de acciones y un etcetera tan largo como queramos.
En este sentido,*Microsoft*se ha convertido en el proveedor de servicios en cloud con más atención a esta tecnologia y no en vano se acaba de anunciar por parte del CTO de la compañía,*Mark Russinovich, la existencia del denominado*Coco Framework*sobre*Microsoft Azure. Unas plataforma Open Source que habilita un Blockchain con características pensadas*para su uso en el mundo de la empresa*en términos de escalabilidad, gobernanza, confidencialidad. Algunos de los primeros proyectos sobre la plataforma Coco está siendo la integación de*Ethereum.[https://msdnshared]
Y creo que lo voy a dejar aquí, pero no sin antes agradecer a mi amigo*Miguel Vidal, que hace ya unos años me descubrió la existencia de este mundo, con una cerveza de por medio, y que desde entonces no he dejado de aprender de él en especial desde sus artículos, opiniones y comentarios en diferentes redes sociales, siendo en mi opinión uno de los mayores expertos en el tema. Solo con su Visto Bueno, y habiendo incorporado lo que él humildemente ha llamado “recomendaciones” ( aunque las recomendaciones de un experto son órdenes para mí*[https://s]), me he atrevido a publicar este post.
Blockchain? Si, claro. Eso es lo de las Bitcoins, no? mmmm pues bueno. Si.
Pero además es un estupendo buzzword del que muchos hablamos, incorporamos a nuestro discurso (he estado en reuniones donde se planteaba la creación de comisiones de Blockchain ) y pretendo explicarlo un poco en este post pos veraniego de forma cero técnica. Es más, casi consigo que mi progenitora, una señora de edad indeterminada (la que ella quiera), entienda el concepto básico (eso, o la inmensa paciencia de una progenitora con el friki de su hijo)
Al final del post comento igualmente donde reside el interés de Microsoft en la plataforma Blockchain y Azure en el mundo de la empresa.[https://i]
Y lo mejor es recurrir en la medida de lo posible a ejemplos cotidianos.
Ya que acabamos de terminar el verano, supongamos, y es un suponer, que mi hija mayor se hubiera ido alegremente de vacaciones con sus amigos, y debido a algunos contratiempos (aunque a mi me parecieran más que previsibles: gasolina, comida.. vamos… llamadme vidente ) se ha quedado sin dinero antes de lo previsto, y si quiero tenerla de vuelta en algún momento, tendré que tras*ferirle dinero para el viaje de regreso. Tras valorar los pros y contras de tenerla de vuelta*[https://s]*(pobrecita, ella sabe que es broma), decidimos hacerle esa tras*ferencia de 20€.
Es mi hija, hay confianza, hay voluntad de hacer esa tras*ferencia, y por parte de ella, sin duda, de recibirla. Pero aun así, yo estoy en Madrid, mi hija en Cádiz, y necesitamos de un tercero que “bendiga” esa tras*acción. La Bendición consiste en comprobar que yo soy yo, que tengo más de 20€ en mi cuenta, que tengo la voluntad de dárselos a mi hija, que mi hija los acepta (lo garantizo si más ciencia de por medio), que se suman en su cuenta y que desaparecen de la mía.
Ese tercero, mi banco en este caso, en el que apenas pongo un pie por cierto (todo lo hago on line), y que bien podría cambiar de un día para otro a golpe de click, habrá creado en algún momento un apunte donde quede registrado que:
El 5 de Agosto del 2017, Héctor tras*firió 20€ a Marina.
Esto solo lo sabemos Yo, el Banco y por supuesto Marina.
Nadie ha tocado un billete (ni mi hija, que lo utilizó para echar gasolina y pago desde su tarjeta de debito). Es decir, lo único que realmente ha ocurrido es la creación de un apunte en un registro creado por un tercero, el banco, en el que todos hemos acordado confiar.
Es decir, que para establecer una relación de confianza entre mi hija Marina y yo hemos dependido de un tercero. Sin valorar la confianza o no que podamos tener en ese tercero, todo comienza con la pregunta… ¿Por qué? ¿No hay alguna otra forma en la que podamos crear y mantener ese registro, que al final parece ser lo más importante, sin que un único tercero en concreto tenga que hacerlo por nosotros?
Adicionalmente, alguien podría pensar que la ubicuidad física del banco, existencia de cajeros, etc, es un valor importante. Bien. Es cierto, aunque en este caso concreto, no hiciera ninguna falta. Y es que es evidente que la posibilidad de tras*misión de información, cualquier tipo de información, de un punto a otro en plena era Internet NO solo está al alcance de una entidad financiera.
Pues como podemos ir adivinando, la respuesta a esta situación que hemos planteado respecto a la “vida” de ese registro, se basa en Blockchain.
Volvamos a Marina y a su Padre, que soy yo.[https://i]
¿Tenemos alguna forma de no depender de un único tercero de confianza para crear y mantener ese maldito registro de los 20€? Pues si. La forma es depender de muchos.
Es decir, tiene que haber mucha más gente que no quiera depender de un solo tercero de confianza en sus tras*acciones, y que además estén dispuestos a mantener una*tras*parencia*insólita respecto a los movimientos de sus finanzas, en la misma medida que lo hago yo.
Es decir, no solo Marina y yo compartiremos la información de ese registro de los 20€ que le tras*ferí, sino que esa información la compartimos además con toda esa comunidad que ha decidido, al igual que nosotros, confiar en este nuevo sistema de confianza en lugar de en una sola entidad (bancaria, en este caso).
Ahora todos los que participamos en este mecanismo sabemos que Héctor le hizo una tras*ferencia de 20€ a Marina el 5 de Agosto del 2017 porque TODOS tenemos una copia idéntica de ese registro donde se van anotando las tras*acciones.
En esa hoja aparece que Héctor le hizo una tras*ferencia a Marina de 20€, pero también que Pilar se la hizo a Andrés de 45€, que Juan recibió una tras*ferencia de Manuel de 2500€ ….. etc… Y esa hoja, con TODOS los apuntes que vamos anotando, está en poder de TODOS.
Todos han podido ver mi intención de tras*ferir 20€ a Marina, y ver que previamente tenía al menos esa cantidad en mi cuenta para poder hacerlo. Y todos han tomado nota en sus registros de esta tras*acción. En ese momento, la tras*acción ya está completa y es efectiva. Enhorabuena Marina. De vuelta a casa.
Creo que es bueno adelantar, llegados a este punto, y ante el más que probable susto que algún lector habrá sentido al leer cosas como “tras*parencia insólita de mis finanzas”, “todos sabemos lo de todos”, “ todos han podido ver mi tras*acción a Marina” etc.. que estoy utilizando identidades de personas para facilitar la compresión del mecanismo y solo con fines didácticos. En la realidad, las identidades de los usuarios de blockchain no están asociadas ni almacenan ninguna información sobre la identidad física y real de las personas. Son un*pseudónimo. Una identidad en blockchain no será más que una clave pública (elemento fundamental en los sistemas de criptografía asimétrica pero que obviamente no es el objetivo de este post explicarlo aquí) sin asociación a ninguna identidad física. De hecho es común que una misma persona pueda utilizar diferentes identidades en Blockchain por motivos o propósitos diferentes.[https://betanews]
Volvamos al ejemplo. Muchos pensareis que la cantidad de registros que tenemos que ir copiando todos es enorme. Y en efecto lo es. Por eso cada vez que completamos una hoja con un número determinado de registros, la cerramos, la almacenamos, y abrimos una nueva para seguir apuntando nuevas tras*acciones y registros.
El proceso de ir cerrando y almacenando esa pila de hojas de registros es muy importante. Ahí reside la memoria histórica de todo lo que ocurre en el sistema y por tanto de ello depende su futura consistencia y fiabilidad.
Por eso lo mejor es que esas hojas con los registros que vayamos completando, apilando y almacenando, los protejamos adecuadamente.
Para ello todos hemos decidido utilizar un mecanismo para proteger esa información según la vayamos almacenando. Pero… ¿Protegerla de qué?
¿Qué es lo peor que podría pasarle a esa información almacenada para que el sistema se viniera abajo?
¿Vulnerar la confidencialidad de esa información? Noooo. Hemos dicho que todos conocemos las tras*ferencias que todos han hecho y recibido.
¿Qué alguien la robe? ¿Perdón? Tenemos millones de copias. Al menos cada persona tiene o ha tenido una copia ….
¿Qué alguien vulnere su integridad, es decir, que modifique algún registro? ¿Os imagináis que alguien pudiera generar nuevos registros falsos?¿O duplicarlos llevando el sistema a situaciones de “doble gasto” (en este caso los mismos 20€ utilizados no solo por Marina, sino también por.. ¿Nadia? desde la más árida estepa Siberiana?) Eso si sería un problema. Bueno, mas bien eso sería EL PROBLEMA.
Por tanto pensemos de que forma garantizamos entro todos la INTEGRIDAD de esos registros almacenados. Es decir, como nos aseguramos que esa información permanece inalterable bajo 7 llaves (de ello depende todas las garantías que sustentan el sistema).
Sin eso, todo se desmoronaría como un castillo de naipes. Si alguien consiguiera sustituir los 20€ de Marina por 20000€, el sistema ...y yo... nos resentiríamos de fin. O si nuestra Nadia consiguiera gastarse los mismos 20€ de Marina, pero en polvorones “La Estepa” al otro lado del mundo, el sistema simplemente ya no nos serviría para nada.
Es por eso por lo que este mecanismo de protección de la integridad de los registros es sin duda la piedra angular de todo el mecanismo y donde reside parte de la sofisticación del sistema Blockchain.
Hasta aquí, tecnología cero.
Pero ahora si hace falta entender un sencillo concepto ampliamente conocido para cualquier ingeniero o matemático, pero probablemente desconocido para personas menos técnicas. Lo llamaremos algo así como “la prueba del 9” de que algo no ha sido modificado (la he llamado así para seguir manteniendo enganchado a cualquier lector no técnico, igual que la podría haber llamado la “función chivata” o cualquier otra cosa). En este caso, la garantía de que todas las hojas almacenadas permanecen integras y nadie ha modificado ningún dato. Esa “prueba del 9” de la integridad (o P9 que llamaré a partir de ahora), se llama función de Hash (Lo sé, es obvio para muchos, pero intento dejarme en el camino al menor número de personas).
Dejando de lado toda la criptografía asociada a esa función, recordemos que pretendemos ser cero técnicos, sepamos que esa función se caracteriza por devolver un resultado diferente y único a una entrada concreta. Es decir, si a nuestra función “Prueba del 9” le damos como dato de entrada el número 20, nos devuelve un resultado. Por ejemplo, y me lo invento, el resultado es este palabro: Xds21Wa.
Y SIEMPRE que presentemos el número 20 a la función, nos dará el mismo resultado: Xds21Wa. Y será único. Es decir, ningún otro número de entrada a la función dará el mismo resultado.
Por otro lado, no hay forma de aplicar esa función en sentido contrario. Es decir, si nos dan el palabro Xds21Wa, nunca podremos deducir que viene del número 20. Tan solo podremos confirmar una y otra vez que dando como entrada el número 20, SIEMPRE obtenemos Xds21Wa.
Por qué es útil esto? Porque si aplicamos esta función “prueba del 9” a la famosa hoja de registros almacenados cuya integridad queremos proteger a toda costa, obtendremos un resultado diferente para cada hoja. ¿Y si alguien modificara un registro de esa hoja? Pues nuestra función “prueba del 9” daría un valor diferente.
Es decir si aplicamos “Prueba del 9” a nuestra hoja número 324, nos dará el resultado único de R34t%6dg (me lo acabo de inventar de nuevo). Y cualquiera, en cualquier lugar del mundo que aplique la función “Prueba el 9” a la Hoja 324, obtendrá idéntico resultado (R34t%6dg).
Si alguien hábilmente modifica un registro de nuestra Hoja 324, al aplicar la función “Prueba del 9” dará un resultado distinto a R34t%6dg, dejando en evidencia ante todos, porque todos podemos efectuar esa operación, que algún registro ha sido modificado. Por tanto, no admitiremos esa modificación.
El Sudoku es un buen ejemplo para entender el concepto detrás de estas funciones: difícil de resolver, pero muuuyyy sencillo de comprobar por cualquiera.
Releyendo hasta aquí creo que no habré perdido a nadie por el camino. Pero vamos a complicarlo solo un poquito, de verdad, con tres operaciones nuevas:
Primera: Supongamos que nos inventamos una condición al resultado de aplicar la función “Prueba del 9”.
Por ejemplo ¿Cuántos números, A, me darán como resultado de aplicarles la función “prueba del 9”, un resultado que empiece, por ejemplo, por “1234”? Es decir, algo así:
P9(A)=1234...
Ufff. Pues me parece que no nos va a quedar más remedio que comenzar a probar números y números a lo bruto para ver cuáles de ellos dan como resultado algo que empiece por “1234”. Y es que no hay una forma aritmética de deducirlos porque precisamente las funciones de Hash (nuestra función “Prueba del 9”) están diseñadas para que no sea posible deducir el número de entrada de una función, dado el resultado.
Por tanto creo que estaremos de acuerdo que solo podemos hacerlo por*fuerza bruta. Es decir, comenzando a introducir números y números y números en nuestra función “prueba del 9” e ir quedándonos con aquellos cuyo resultado haya comenzado por 1234. Es importante entender en este punto que lógicamente esto requerirá un esfuerzo computacional, verdad?
Al final, de tanto probar y probar, habremos encontrado por ejemplo que nuestra Función “prueba del 9” aplicada al número, por ejemplo, 39874, nos ha dado el resultado*12349845.
Por tanto el número 39874 cumple la condición.
Y resulta que la función “prueba del 9” aplicada al número 3909001, también nos ha dado como resultado el numero*12349082375, cumpliendo igualmente la condición que habíamos definido.
Es decir, de todos los números que hemos ido probando hasta este momento, ya hemos encontrado dos, el 39874 y el 3909001, que cumplen la condición de dar como resultado un número que empiece por 1234. Pues bien, podemos seguir buscando.
Segunda: Vamos a añadir un pequeñísima dificultad en este proceso. No se trata más que de prestar un poco de atención a ese dato de entrada de nuestra función “Prueba del 9”. Vamos a cambiar ese dato de entrada por una suma de dos datos en lugar de un solo dato, ok? Es decir, en lugar de hablar de un número, al que se le aplica la función “Prueba del 9”, y que nos da un número que cumple la condición de comenzar por 1234, hablaremos de una suma de dos números a los que le aplicamos la función “prueba del 9”. Algo así como:
P9(A+B)=1234…..
Es decir, nuestra función “Prueba del 9”, que aplicada a la suma de A más B, cumpla la condición de dar un número que comience por 1234, ok?
Ya nos habremos dado cuenta de que el número de soluciones será infinito a no ser que fijemos el valor de uno de los dos números. Hagámoslo. Fijamos el valor de A=20, por ejemplo.
Ahora tengo que aplicar la función “prueba del 9” a la suma de 20, el valor de A, más un número B para que nos de un número que comience por 1234, ok?. Algo así:
P9(20+B)=1234….
Ahora tendríamos que probar en nuestra función “prueba del 9” un montón de valores de B para que, sumados a 20, nos de como resultado un número que cuando se le aplique la función P9, cumpla la condición de empezar por 1234, ok?
Bueno. No parece una complejidad muy grande respecto a lo anterior, verdad?. Pero en este caso es interesante ver que estamos encontrando una bonita relación casi romántica obsesiva entre un par de números, convirtiéndose uno en el “guardián” del otro. B guardará la integridad de A, y A guardará la integridad de B.
Es decir, podríamos decir que la integridad de A esta garantizada por B. Si alguien modificara A, al sumarse con B y aplicar a la suma nuestra función “prueba del 9”, daría un número que no comenzaría por 1234, dejando en evidencia la vulneración de la integridad de A. Y Viceversa.
Podríamos decir que B se convierte en el garante de la integridad de A.
Si volvemos por fin al ejemplo del registro de la olvidada tras*acción que hice a mi hija Marina por importe de 20€, podemos identificar esa tras*acción como la tras*acción A, y B será el guardian de que nadie modifique esa tras*acción. Si alguien modificara esa tras*acción A, al añadirle el valor de B (su guardian), veríamos que al aplicar la función “prueba del 9” a la suma, el resultado no cumpliría la condición de comenzar por 1234 (en un caso real la condición es diferente a esta simpleza que nos hemos inventado de que el resultado comience por 1234… , pero seguro que el ejemplo ha sido útil para entender todos estos conceptos básicos.* En la realidad, las condiciones tienen que ver con el numero de "ceros" con el que comience el resultado)
Es decir, en el sistema de Blockchain, todos los participantes pueden comprobar de forma autónoma que B es el guardián de A, y que si se modifica cualquiera de ellos, el otro evidenciará esa vulneración de la integridad. Parece que la información de mi tras*acción a Marina está a salvo y hay mucha gente que está de acuerdo.
Tercera. Si hemos llegado hasta aquí sin perdernos, esto ya está hecho. Pero nos falta un pequeño detalle. La tras*acción que hice a Marina, la tras*acción A, ya está hecha, guardada, almacenada, bendecida con su clave B que impide que nadie pueda modificarla. Pero ¿Y si alguien estuviera muy interesado en modificar ese registro A, que podría hacer? Pues se me ocurre que podría realizar la modificación deseada en A, y volver a calcular un nuevo número B que sumado a A cumpliera de nuevo la condición de arrojar un resultado que comenzara por 1234. Hago la sustitución de A y B por sus nuevos valores, y ya está. El sistema vulnerado*[https://s]. Pues vaya… ¿Para este corto viaje tantas alforjas?
¿Cuál ha sido el problema y como podríamos resolverlo? Básicamente, no podemos tratar las tras*acciones como hechos aislados, sin ningún tipo de conexión entre si. Todo el mecanismo que hemos descrito nos ha servido para garantizar la integridad de cualquier registro en particular de forma autosostenida, y que todos los demás puedan verlo, pero independientemente de la existencia del registro vecino. De esa forma, se podría manipular y vulnerar un registro aunque no sin cierta dificultad.
Llegados a este punto, estaría muy bien que pudiéramos introducir un nuevo elemento que nos relacione mi tras*acción A, no solo con esa especie de sello o guardian que hemos llamado B hasta ahora, sino que también lo hiciera con otra tras*acción vecina, que a su vez también estaría relacionada con otra, y esta con otra… y si… aquí aparece por primera vez el por que de la palabra “cadena”, chain, en esta tecnología.
En este escenario, modificar un registro significaría modificar tooooda la cadena de registros vecinos….. y eso ya tiene muy pocas probabilidades de poder realizarse, verdad ?.
Es decir, ese nuevo elemento que nos relacione un registro con el registro vecino lo vamos a llamar C, ok? Y que mejor que representar a ese registro vecino que con el resultado de su “prueba del 9”?
De esta forma la integridad de cada registro A estará custodiada no solo por ese guardian B, sino que también por ese otro valor de C que depende del registro vecino. Es decir, que el registro A que recoge la información de la tras*ferencia de 20€ que le hice a Marina está custodiada por ese clave B que definíamos anteriormente, pero que a su vez depende de otro elemento C que nos trae información sobre el registro vecino, en este caso el de la tras*ferencia que Juan le hizo a Mónica por valor de 1500€…. por ejemplo.
Es decir, antes teníamos que P9(A+B)= 1234….. donde A es el registro a proteger, y B tenía que ser calculado para cumplir la condición de dar un número que comenzara por 1234. Ahora tenemos que:
P9(A+B+C)=1234…..
donde A es de nuevo el registro a proteger, B tendrá que ser de nuevo calculado y C es el resultado de aplicar P9 al registro anterior. Es decir, también un número que comenzaría por 1234…. en nuestro ejemplo.
De esta forma, la protección de cada registro depende de parámetros del registro anterior. Si alguien quisiera modificar el registro A utilizando ese truquillo descrito al principio de este punto, tendría que modificar el contenido de A, calcular la clave de protección B de todos los registros siguientes para mantener la consistencia del sistema. Y eso ya es bastante más que improbable que suceda (aunque un ejercicio teórico en el que todos los participantes del sistema blockchain, ¿millones? nos volviéramos malos malísimos, y diéramos por buena esa cadena inconsistente, se podría llevar teóricamente el sistema al traste).
*
Y ya para terminar, incorporemos otro concepto fundamental. Hemos hablado con bastante ligereza de aplicar funciones (nuestra manida “prueba el 9”), calcular números que cumplan condiciones etc.. Y además estos cálculos son imprescindibles para ir “sellando” los registros con esas claves B que hemos ido comentando. El sistema necesita esas claves.
Pues bien, el esfuerzo computacional para realizar estos cálculos no es menor. Es muy intenso. Probar millones de entradas con nuestras función de hash (Prueba del 9) para ver cuales nos devuelven un resultado que cumpla una determinada condición (empezar por 1234), requiere mucha capacidad de proceso …. y algo de suerte*[https://s].
En un sistema descentralizado como este nos podemos preguntar, ¿Quién lo hace? ¿Y por que lo va a hacer?
La respuesta a la primera pregunta es clara: cualquiera de los participantes en el sistema de Blockchain lo puede hacer (siempre y cuando cuente con alguna capacidad de proceso). Pero siendo un proceso que requiere unos cálculos intensos, que acarrean gastos importantes en tiempo y energía, proceso, por que alguien querría hacerlo? ¿Altruismo? ¿experimentación? Pues la respuesta a ello es una recompensa tan poco original, como genial en este caso….: dinero.
Si, dinero, pero como no podría ser de otra forma, en forma de Bitcoins.
De hecho, el Bitcoin, como cualquier otra moneda, circula, se tras*fiere, se gasta, se compra, se invierte, se cambia, se regala, se roba, se ….. todo. Pero ¿Cómo se crea? O utilizando términos apropiados ¿Cómo se acuña? No existe un Banco Central que “fabrique moneda”, no. La única forma de crear Bitcoin de la nada e inyectarlos en el sistema es trabajando para el sistema ¿Cómo? Aportando potencia de cálculo para obtener esas claves B que nos vayan cerrando y guardando los registros, y que como hemos visto, son imprescindibles para la seguridad e integridad de todo el mecanismo. Si habíais oído el término “minar Bitcoins”, ya sabéis a que se refiere, por qué se hace y que se obtiene a cambio. Este esfuerzo computacional es a lo que se le denomina una*prueba de trabajo, concepto fundamental en el mundo Bitcoin/Blockchain.
En el proceso de minar Bitcoins, se da el dicho de “the First takes it all”. El primero que consigue una clave B válida, es decir que cumple la condición de P9(A+B+C)=1234…, cerrará ese registro, se lleva toda la recompensa y continuara trabajando simultáneamente sobre el resto de registros.
El sistema autoregula de forma automática el factor de dificultad de la condición a cumplir para sellar un registro (cálculo de B). Si la condición “número que comienza por 1234” comienza a ser demasiado sencilla, pongo por caso, y se tarde menos de 10 minutos de media en el cálculo de B, se incrementa automáticamente la dificultad de la condición a cumplir, por ejemplo, cambiándola por “comenzar por 12345” (recordar que es un ejemplo didáctico. En la realidad hablaremos de añadir "ceros" a la condición)
En relación a su implementación tecnológica, es interesante igualmente exponer que todo el código fuente de Bitcoin es*software libre*(bajo una licencia libre permisiva no-copyleft), que es un proyecto de código abierto tras el que no hay nadie detrás, que cualquiera con las skills adecuadas puede participar, que nadie lo controla, sino que se gestiona en github y listas de correo públicas como cualquier otro proyecto de software libre.
Y en relación a su utilización, es obvio que no hay que conocer NADA de lo que he descrito en este post para ser un feliz usuario de Bitcoins, blockchain o de cualquier otro proyecto basado en esta tecnología.
Se habla mucho del uso de la tecnología de Blockchain en el ámbito empresarial, si bien algunas de sus caractaerísticas diseñadas originalmente para funcionar en un ámbito absolútamente público, descentralizado y sin gobierno, como característica fundamental de su disño, necesitan de alguna modificacón en términos de goberbnanza, confidencialidad o rendimiento,* para que se uso pueda ser ampliamente aceptado en el mundo de la empresa.[http://guiabitcoin]
Lo escenarios de la empresa que miran a Blockchain como una solución importante a muchos retos, tienen que ver no solo con las criptomonedas o sector bancario. Hablamos de ámbitos de tras*ferencias, registros, seguros (caso*Microsoft & Maersk) votaciones, seguimiento de productos y servicios, internet de las cosas, contratos inteligentes, previsiones, musica on line, compartición de vehículos, compra de acciones y un etcetera tan largo como queramos.
En este sentido,*Microsoft*se ha convertido en el proveedor de servicios en cloud con más atención a esta tecnologia y no en vano se acaba de anunciar por parte del CTO de la compañía,*Mark Russinovich, la existencia del denominado*Coco Framework*sobre*Microsoft Azure. Unas plataforma Open Source que habilita un Blockchain con características pensadas*para su uso en el mundo de la empresa*en términos de escalabilidad, gobernanza, confidencialidad. Algunos de los primeros proyectos sobre la plataforma Coco está siendo la integación de*Ethereum.[https://msdnshared]
Y creo que lo voy a dejar aquí, pero no sin antes agradecer a mi amigo*Miguel Vidal, que hace ya unos años me descubrió la existencia de este mundo, con una cerveza de por medio, y que desde entonces no he dejado de aprender de él en especial desde sus artículos, opiniones y comentarios en diferentes redes sociales, siendo en mi opinión uno de los mayores expertos en el tema. Solo con su Visto Bueno, y habiendo incorporado lo que él humildemente ha llamado “recomendaciones” ( aunque las recomendaciones de un experto son órdenes para mí*[https://s]), me he atrevido a publicar este post.
