Cómo evitar otro proyecto Blockchain sin sentido

Este artículo que he visto por casualidad en twitter me ha parecido muy interesante, sobre todo porque en él Gideon Greenspan, el CEO de una startup de proyectos blockchain (Coin Sciences Ltd) se dedicaba en noviembre de 2015 a disuadir a potenciales clientes que en realidad no necesitan blockchain.

Evitando el proyecto blockchain sin sentido

Cómo determinar si has encontrado un caso de uso real de blockchain

Los blockchains reciben demasiada atención de los medios. Ya está, por fin lo he dicho. Desde Sibos hasta Money 20/20 pasando por las portadas de The Economist y Euromoney, parece que todo el mundo quiere subirse al carro del blockchain. Y sin duda como otros en ese espacio, estamos viendo un número rápidamente creciente de empresas construyendo pruebas de concepto sobre nuestra plataforma y/o pidiéndonos ayuda.

Como joven startup que somos, podrías pensar que se nos ha subido el éxito a la cabeza. Seguramente ahora es el momento de obtener un montón de dinero y construir esa plataforma de alto rendimiento de la siguiente generación de blockchain que ya hemos diseñado. ¿A qué estamos esperando?

Te diré una cosa. Estamos esperando alcanzar una comprensión más clara de dónde las blockchains aportan valor de verdad en las TI de las empresas. Verás, una amplia proporción de esos proyectos que nos llegan no tienen nada que ver con las blockchains. Así es como funciona. Gran empresa oye que las blockchains son el último grito. Gran empresa busca internamente a algunas personas a las que les interesa el asunto. Gran empresa les da un presupuesto y les dice que vayan a hacer algo “blockchainístico”. Justo después llaman a nuestra puerta, agitando billetes de dólar, pidiéndonos que les ayudemos a pensar en un caso de uso. ¿Y ahora qué?

Y para los que ya tienen un proyecto en mente, ¿cuál es el problema? En muchos casos, el proyecto puede implementarse perfectamente utilizando una base de datos relacional normal y corriente. Sabes, mastodontes metálicos como Oracle y SQL Server, o para los de mentalidad más abierta, MySQL y Postgres. Así que permitidme que empiece por poner un poco de orden:

Si tus requisitos se cumplen con las bases de datos relacionales de hoy, estarías loco si usaras una blockchain.

¿Por qué? Porque los productos como Oracle y MySQL tienen detrás décadas de desarrollo. Se han desplegado en millones de servidores que ejecutan trillones de consultas. Contienen algunos de los fragmentos de código más exhaustivamente verificados, limpiados de errores y optimizados del planeta, y procesan miles de transacciones por segundo sin tan siquiera empezar a sudar.

¿Y qué hay de las blockchains? Bueno, nuestro producto fue uno de los primeros en llegar al mercado, y ha estado disponible durante exactamente 5 meses, con unos pocos miles de descargas. En realidad es extremadamente estable, porque lo hemos construido fuera de Bitcoin Core, que es el software que mueve bitcoin. Pero aún así, esta categoría entera de productos está todavía en pañales.

¿Entonces estoy diciendo que las blockchains no sirven para nada? Nada de eso. Pero antes de embarcarte en un reluciente proyecto de blockchain, tienes que tener una idea muy clara de por qué estás usando una blockchain. Hay un puñado de condiciones que deben satisfacerse. Y si no, deberías volver al tablero de dibujo. Quizá puedas definir mejor el proyecto. O quizá puedas ahorrarle a todo el mundo un montón de tiempo y dinero, porque no necesites una blockchain para nada.

1. La base de datos

Aquí está la primera regla. Las blockchains son una tecnología para bases de datos compartidas. Así que debes empezar sabiendo por qué estás usando una base de datos, con lo cual me refiero a un depósito estructurado de información. Puede ser una base de datos relacional tradicional, que contenga una o más tablas del tipo de las de las hojas de cálculo. O puede ser de la variedad más en boga de NoSQL, que funciona más como un sistema de archivos o un diccionario. (Desde el punto de vista teórico, las bases de datos NoSQL son sólo un subconjunto de bases de datos relacionales, de todos modos).

Un libro mayor para activos financieros puede expresarse con naturalidad como una tabla de una base de datos en que cada fila representa un tipo de activo cuyo propietario es una entidad en particular. Cada fila tiene tres columnas que contienen: a) El identificador del propietario, como un número de cuento, b) un identificador del tipo de activo, como “USD” o “AAPL” y c) la cantidad de ese activo poseída por ese propietario.

Las bases de datos se modifican por medio de “transacciones” que representan un conjunto de cambios a la base de datos que deben ser aceptados o rechazados en su conjunto. Por ejemplo, en el caso de un libro mayor de activos, un pago de un usuario a otro se representa por una transacción que deduce una cantidad de una fila y la añade a otra.

2. Múltiples escritores

Esta es fácil. Las blockchains son una tecnología para bases de datos con múltiples escritores. En otras palabras, debe haber más de una entidad generando transacciones que modifiquen la base de datos. ¿Sabes quiénes son esos escritores?

En la mayoría de los casos los escritores también explotarán “nodos” que guardan una copia de la base de datos y pasan transacciones a otros nodos a modo de peer-to-peer. Sin embargo las transacciones también podrían crearlas usuarios que no tienen un nodo a su cargo. Piensa por ejemplo en un sistema de pagos que se mantiene colectivamente por un pequeño grupo de bancos pero que tiene millones de usuarios finales en terminales móviles, comunicándose sólo con los sistemas de sus propios bancos.

3. Ausencia de confianza

Y ahora la tercera regla. Si hay múltiples entidades escribiendo en la base de datos, también tiene que haber cierto grado de desconfianza entre esas entidades. En otras palabras, las blockchains son una tecnología para bases de datos con múltiples escritores que no confían en los demás.

Podrías pensar que la desconfianza sólo surge entre organizaciones separadas, como los bancos que negocian en un mercado o las empresas implicadas en una cadena de suministro, pero también puede existir en el seno de una sola gran organización, por ejemplo, entre departamentos o las operaciones entre distintos países.

¿A qué me refiero concretamente con desconfianza? Quiero decir que un usuario no está dispuesto a dejar a otro que modifique las entradas de la base de datos que “le pertenecen”. De modo similar, cuando se trata de leer los contenidos de la base de datos, un usuario no aceptará como evangelio de “la verdad” lo que diga otro usuario, porque cada uno tienen incentivos económicos o políticos diferentes.

4. Desintermediación

Así que el problema, tal y como lo hemos definido hasta ahora, es habilitar una base de datos con múltiples escritores que no se fían unos de otros. Y ya existe una solución conocida de sobra para este problema: el intermediario de confianza. Esto es, alguien de quien todos los escritores se fían, incluso si no se fían por completo unos de otros. Sin duda, el mundo está lleno de bases de datos de esta naturaleza, como el libro mayor de las cuentas de un banco. Tu banco controla la base de datos y se asegura de que cada transacción es válida y que está autorizada por el cliente cuyos fondos mueve. Da igual lo amablemente que preguntes, tu banco nunca te dejará que modifiques directamente su base de datos.

Las blockchains quitan la necesidad de intermediarios de confianza habilitando que las bases de datos con múltiples escritores que no se fían unos de otros se puedan modificar directamente. No se necesita un guardián centralizado para verificar las transacciones y autenticar su origen. En vez de esto, la definición de una transacción se extiende para incluir una prueba de autorización y una prueba de validez. Las transacciones pueden por lo tanto ser verificadas y procesadas de forma independiente por cada nodo que mantiene una copia de la base de datos.

Pero la pregunta que debes plantear es: ¿Queremos o necesitamos esta desintermediación? Según sea tu caso de uso, ¿hay algún problema con tener una parte central que mantiene una base de datos de autorizaciones y que actúa como el portero de las transacciones? Hay buenas razones para preferir una base de datos basada en blockchain a un intermediario de confianza como menores costes, transacciones más rápidas, reconciliación automática, nuevas normas o la simple incapacidad de encontrar un intermediario adecuado.

5. Interacción entre las transacciones

Así que las blockchains tiene sentido para bases de datos compartidas por múltiples escritores que no se fían por completo unos de otros y que modifican la base de datos directamente. Pero todavía no es suficiente. Las blockchains brillan de verdad donde haya alguna interacción entre las transacciones creadas por esos escritores.

¿A qué me refiero con interacción? En el sentido más amplio, esto significa que las transacciones creadas por diferentes escritores a menudo dependen unas de otras. Por ejemplo, digamos que Alice envía unos fondos a Bob y entonces Bob envía a su vez algunos a Charlie. En esto caso, la transacción de Bob depende de la de Alice, y no hay forma de verificar la transacción de Bob sin comprobar la de Alice antes. A causa de esta dependencia, las transacciones pertenecen las dos a una sola base de datos compartida.

Llevando esto más lejos, una buena funcionalidad de las blockchains es que las transacciones pueden crearse colaborativamente por múltiples escritores, sin que ninguna de las partes tenga que exponerse a un riesgo. Esto es lo que permite realizar los acuerdos de entrega contra pago con seguridad en una blockchain, sin requerir un intermediario de confianza.

Un buen caso puede hacerse también para situaciones donde las transacciones desde distintos escritores están relacionadas entre sí, incluso aunque permanezcan independientes. Un ejemplo podría ser una base de datos de identidades compartida en la que múltiples entidades validan distintos aspectos de las identidades de los consumidores. Aunque cada una de esas certificaciones es independiente, la blockchain proporciona una forma útil de reunirlo todo de forma unificada.

6. Establecer las reglas

En realidad esto no es una condición, sino más bien una consecuencia inevitable de los puntos anteriores. Si tenemos una base de datos modificada directamente por múltiples escritores, y esos escritores no se fían completamente unos de otros, entonces la base de datos debe contener reglas incrustadas que restrinjan las transacciones que se pueden hacer.

Estas reglas son fundamentalmente distintas de las restricciones que aparecen en las bases de datos tradicionales, porque se relacionan con la legitimidad de las transformaciones que con el estado de la base de datos en un instante concreto. Cada transacción se comprueba contra estas reglas por cada nodo de la red, y las que fracasan se rechazan y no se retransmiten.

Los libros mayores de activos contienen un ejemplo sencillo de este tipo de regla, para prevenir transacciones que creen activos de la nada. La regla establece que la cantidad total de cada activo en el libro mayor debe ser la misma antes y después de cada transacción.

7. Elige a tus validadores

Hasta ahora hemos descrito una base de datos distribuida en que las transacciones pueden originarse en múltiples lugares, propagarse entre nodos a modo peer-to-peer, y se comprueban por cada nodo de forma independiente. ¿Entonces dónde entra la “cadena de bloques”? Bueno, uno de los trabajos de la blockchain es ser el registro autorizado final de las transacciones, en cuyos contenidos todos los nodos están de acuerdo de forma demostrable.

¿Por qué necesitamos este registro? En primer lugar, permite que los nodos recientemente incorporados calculen los contenidos de la base de datos desde cero, sin necesidad de que se fíen de otro nodo. En segundo lugar, responde a la posibilidad de que algunos nodos se pierdan algunas transacciones, debido a una caída del sistema o un ruido de comunicaciones. Sin un registro de transacciones, esto causaría que la base de datos de uno de los nodos divergiese de la de los demás, socavando el objetivo de una base de datos compartida.

En tercer lugar, es posible que haya dos transacciones en conflicto, de forma que sólo una de ellas puede aceptarse. Un ejemplo clásico es un gasto doble en que el mismo activo se envía a dos receptores distintos. En una base de datos peer-to-peer sin una autoridad central, los nodos podrían tener opiniones diferentes acerca de qué transacción debería aceptarse, porque no hay una respuesta objetivamente correcta. Al requerir que las transacciones se “confirmen” en una blockchain, aseguramos que todos los nodos convergen en la misma decisión.

Por último, en las blockchains al estilo de Ethereum, el ordenamiento preciso de las transacciones juega un papel crucial, porque cada transacción puede afectar a lo que ocurre en cada una de las subsiguientes. En este caso, la blockchain actúa para definir la cronología oficial, sin la cual las transacciones no se podrían procesar en absoluto.

Una blockchain es literalmente una cadena de bloques, en la que cada bloque contiene un conjunto de transacciones que se confirman como un grupo. Pero ¿quién es responsable de elegir las transacciones que van en cada bloque? En el tipo de “blockchain privada” que es adecuada para las aplicaciones empresariales, la respuesta es un grupo cerrado de validadores (“mineros”) que firman digitalmente los bloques que crean. Esta lista de admitidos se combina con alguna forma de esquema de consenso para evitar que una minoría de validadores se haga con el control de la cadena. Por ejemplo, MultiChain utiliza un esquema llamado diversidad de minería, en que los mineros autorizados trabajan a modo de “round-robin“, con algún grado de libertad para tener en cuenta los nodos que no estén funcionando.

Independientemente del esquema de consenso que se utilice, los nodos validadores tienen mucho menos poder que el propietario de una base de datos centralizada tradicional. Los validadores no pueden falsificar transacciones o modificar la base de datos violando sus reglas. En un libro mayor de activos, esto quiere decir que no pueden gastar el dinero de otras personas, ni cambiar la cantidad total de activos representados. Sin embargo, aún quedan maneras en que los validadores pueden influenciar indebidamente los contenidos de una base de datos:

  • Censura de transacciones. Si se coaligan maliciosamente los suficientes validadores, pueden impedir la confirmación en la blockchain de una transacción en particular, dejándola permanentemente en el limbo.
  • Resolución sesgada de conflictos. Si dos transacciones entran en conflicto, el validador que cree el siguiente bloque decide qué transacción se confirma en la blockchain, causando que la otra sea rechazada. La elección justa sería que la primera transacción que se haya visto, pero los validadores pueden elegir basándose en otros factores sin revelarlo.

A causa de estos problemas, cuando se está implantando una base de datos basada en blockchain, debes tener una idea clara de quiénes son tus validadores y por qué confías en ellos, colectivamente si no uno a uno. En función del caso de uso, los validadores podrían elegirse como: (a) uno o más nodos controlados por una sola organización, (b) un grupo central de organizaciones que mantienen la cadena, o (c) cada nodo de la red.

8. Respalda tus activos

Si has llegado hasta aquí, te habrás dado cuenta de que tiendo a referirme a las blockchains como bases de datos compartidas, en vez de con la definición más común de “libros mayores compartidos”. ¿Por qué? Porque como tecnología, las blockchains pueden aplicarse a problemas que van mucho más allá del seguimiento de la propiedad de activos. Cualquier base de datos que tiene múltiples escritores que no se fían unos de otros puede implementarse sobre una blockchain, sin requerir un intermediario central. Los ejemplos incluyen calendarios compartidos, colaboración al estilo wiki y foros de discusión.

Dicho esto, por ahora parece que las blockchains son sobre todo de interés para quienes siguen el movimiento e intercambio de activos financieros. Puedo pensar en dos razones para esto: (a) el sector financiero está respondiendo a la (con lo que sabemos ahora, minúscula) amenaza de criptomonedas como bitcoin, y (b) un libro mayor de activos es el ejemplo más simple y natural de una base de datos compartida con transacciones interdependientes creadas por múltiples entidades que no se fían unas de otras.

Si quieres usar una blockchain como un libro mayor de activos, debes responder a una pregunta crucial adicional: ¿Cuál es la naturaleza de los activos que se están moviendo? Con esto no me refiero sólo a dinero o bonos o cartas de porte, aunque por supuesto eso también es importante. La pregunta es más bien: ¿Quién está detrás de los activos representados en la blockchain? Si la base de datos dice que poseo 10 unidades de algo, ¿quién me permitirá reclamar esas 10 unidades en el mundo real? ¿A quién demando si no puedo convertir lo que está escrito en la blockchain en activos físicos tradicionales? (Mira este acuerdo para ver un ejemplo).

La respuesta, por supuesto, variará en función del caso de uso. Para activos monetarios, uno puede imaginar bancos de custodia que acepten dinero en la forma tradicional, y después acreditando las cuentas de los depositarios en un libro mayor distribuido movido por una blockchain. En finanzas comerciales, las cartas de crédito y de porte se respaldarían por el banco del importador y la compañía de transportes respectivamente. Y más adelante en el futuro, podemos imaginar un tiempo en que la principal fuente de bonos corporativos tenga lugar directamente en una blockchain por parte de la empresa que busque captar fondos.

Conclusión

Como mencioné en la introducción, si tu proyecto no satisface todas y cada una de estas condiciones, no deberías estar usando una blockchain. En ausencia de cualquiera de las cinco primeras, deberías pensar en: (a) un almacenamiento convencional de archivos, (b) una base de datos centralizada, (c) una replicación maestro-esclavo de bases de datos, o (d) múltiples bases de datos a los que se puedan suscribir los usuarios.

Y si cumples las cinco primeras, todavía queda trabajo por hacer. Debes ser capaz de expresar las reglas de tu aplicación en términos de las transacciones que una base de datos permite. Debes estar seguro de en quiénes puedes confiar como validadores y cómo definirás el consenso distribuido. Y por último, si estás pensando en crear un libro mayor compartido, debes saber quién estará respaldando los activos representados en ese libro mayor.

¿Tienes todas las respuestas? Enhorabuena, tienes un caso de uso de blockchain real. Y nos encantaría saber de tí.

Traducción del escrito de Gideon Greenspan, CEO and Founder, Coin Sciences Ltd

 

Lo que querías saber sobre Industria 4.0, por Dani Cardelús

No os perdáis este post de Dani Cardelús sobre Industria 4.0, ameno y didáctico como es usual ya en él. Yo no me atrevo a hacer vídeos, se me hace raro oír mi voz fuera de mi cabeza, como supongo que a muchos nos ocurre. El caso es que en poquito tiempo entiendes las cuatro revoluciones industriales y cómo nos afectan en nuestra vida diaria y nuestro trabajo.

La necesaria transformación digital de las Utilities según Dani Cardelús

La semana pasada volví a tener la muy grata ocasión de compartir estrado con Dani Cardelús, esta vez para impartir una charla juntos con Pablo Peralta. Tuve ocasión de desvirtualizar a Guille Mas, que asistió al curso. Yo hablé de mi proyecto de lab digital de operaciones después de que Pablo transmitiese la visión estratégica de la transformación digital, y Dani dio una magnífica introducción a las metodologías ágiles de desarrollo de software.

Entonces me enteré de que él también tiene un blog y hoy he empezado a leer lo que nos cuenta en él. En este artículo he disfrutado de su visión del porvenir y de lo apremiante que resulta que de una vez en las empresas de aguas nos desprendamos del business as usual para cambiar drásticamente de rumbo.

¿Antiguo o nuevo? O eres Van Damme en el anuncio de Volvo o te tocará elegir. Fuente: autocosmos.com

¿Debemos abandonar nuestros estrambóticos planes de nadar entre dos aguas? Yo creo que ya va siendo hora, como Dani preconiza. Y también que voy a frecuentar su blog.