Poco a poco se va despejando el humo de la exuberancia irracional de la tecnología blockchain, y las empresas empiezan a ver su utilidad real. Después de muchas pruebas de concepto, y algún piloto, parece que entre todos empezamos a comprender dónde utilizar, y dónde no, este tipo de plataformas. Desafortunadamente, todavía hay una gran barrera a la que nos enfrentamos las empresas a la hora de hacer realidad los casos de uso que hemos demostrado funcionales en pruebas, y es el salto al mundo de los sistemas en producción. Este es un mundo nuevo para las plataformas blockchain corporativas, y aquí nos enfrentamos a equipos de seguridad, requisitos de alta disponibilidad, privacidad, y un carga en el sistema al que las plataformas no están acostumbradas.

Y toda nuestra experiencia sobre como hemos llevado una plataforma corporativa de blockchain, como es Hyperledger Fabric, desde un entorno de desarrollo, o pruebas, a producción, es de lo que os vengo a hablar hoy. Concretamente, hoy os quiero hablar sobre rendimiento, y sobre como, tras una primera toma de contacto con el mundo productivo, nos vimos en la obligación de hacer un análisis pormenorizado del rendimiento en Hyperledger Fabric para entender sus potenciales cuellos de botella, y el coste asociado de una infraestructura productiva de estas características.

Como mucho ya sabréis, desde Telefónica estamos desarrollando TrustOS, un capa de abstracción que permita a las empresas lanzar sus casos de uso sobre tecnología blockchain sin demasiado esfuerzo ni conocimientos previos. Uno de los motores de este producto es una red de Hyperledger Fabric de propósito general, sobre la que cualquiera pueda desplegar su caso de uso descentralizado e interactuar con él.

Tras varios meses de desarrollo tocaba lanzar la primera versión de TrustOS en producción, y las primeras pruebas de carga sobre nuestra infraestructura nos confirmaron algo que preveíamos: no podíamos lanzar nuestro entorno de pruebas directamente a producción por que no soportaría la carga que esperábamos tener; y para solucionar esto debíamos entender mejor que afecta al rendimiento en Hyperledger Fabric. Fue entonces cuando decidimos embarcarnos en la realización de un análisis exhaustivo de la plataforma de Fabric para entender que debíamos afinar de cara a llevar a TrustOS a producción, y su modelo de costes una vez desplegado (algo que pocos se habían preguntado hasta el momento).

De cara a simplificar el análisis, lo primero que hicimos es dividir toda la estructura de una plataforma de Hyperledger Fabric en distintas capas, y ver que podíamos hacer en cada capa para mejorar el máximo el rendimiento de nuestro sistema. Así, redujimos la arquitectura de Fabric a estas cinco capas:

  • La infraestructura: El conjunto de máquinas y recursos físicos sobre los que se despliega la red de Fabric.
  • La arquitectura de la red Fabric, es decir, el número y tipo de peers, orderers, y demás elementos que conforman la red.
  • El protocolo de Fabric. El núcleo del funcionamiento de una red de Fabric.
  • Los chaincodes donde se implementa la lógica de negocio distribuida en Fabric.
  • Y finalmente, el SDK, la pasarela de interacción con una red de Fabric desde el mundo exterior.

Cada una de estas capas afecta en distinta medida al rendimiento de un sistema basado en Hyperledger Fabric, y necesitábamos entender cómo.

Tras un gran número de pruebas, unos cuantos meses de trabajo, y bastante sufrimiento (no os voy a engañar), conseguimos definir un conjunto de buenas prácticas en cada capa para asegurar el mejor rendimiento posible en un despliegue de Hyperledger Fabric, y el coste asociado de cada una de ellas. Un trabajo que nos permitió llevar a TrustOS al estado productivo en el que se encuentra ahora mismo.

Y os estaréis preguntando, ¿a qué tipo conclusiones llegasteis como resultado del análisis? Permitidme compartir con vosotros algunas de las más importantes en cada capa:

  • Infraestructura: Una cosa de la que nos dimos cuenta temprano en nuestro análisis, es que lo fundamental a la hora de asignar recursos una red de Fabric es la CPU. Para que una red de Fabric funcione a su máximo rendimiento tiene que disponer en todo momento de suficientes CPUs para acomodar la red.
  • Arquitectura: Lamentablemente, para aumentar el número de transacciones por segundo que puede soportar una red de Fabric, no basta con incluir CPUs de manera indefinida, también hay que escalar la arquitectura de la red. Y en este sentido, para escalar el rendimiento de una red de Fabric se pueden seguir dos enfoques: escalar en el número de “endorser peers” o en el número de canales. Esto, claro está, siempre y cuando se asignen suficientes CPUs a la infraestructura sobre la que se despliega la red. No tiene sentido escalar en número de peers o canales si no se escala en paralelo en número de CPUs, porque el resultado, en términos de rendimiento, será contraproducente.
  • Protocolo: De cara a no entrar en conflicto con el roadmap de desarrollo del equipo core de Fabric, en esta capa nos limitamos a probar “configuraciones óptimas” del protocolo que asegurasen un rendimiento óptimo, y no propusimos ningún cambio sustancial. Aquí llegamos a conclusiones interesantes sobre cosas como el tamaño y el tiempo de bloque ideal en función de la carga esperada en la red para asegurar el mejor rendimiento posible.
  • Chaincodes: Los chaincodes resultaron ser una pieza fundamental en el rendimiento de la red. Un chaincode con un modelo de datos mal diseñado puede lastrar a todo el sistema. Aquí nuestra sugerencia es la siguiente: diseña tu chaincode evitando MVCC conflicts. Estos “conflictos” son un conjunto de errores que aparecen cuando la red tiene que soportar una gran carga, y dos transacciones tratan de modificar la misma información en el ledger al mismo tiempo. Si tienes interés sobre como diseñar chaincodes sin MVCC conflicts, te invito a revisar los artículos al final de esta publicación.
  • SDK: Finalmente, el SDK como pasarela de interacción con la red puede no parecer importante para el rendimiento, pero lo cierto es que al ser el encargado de gestionar todo el ciclo de vida de las transacciones que llegan a la red (enviarlas a los peers, devolvérselas al orderer, etc.), si no está bien diseñado puede provocar que muchas transacciones se pierdan, o su resultado no se devuelva de manera satisfactoria a los usuarios, por lo que es fundamental entender y diseñar correctamente el SDK. Una vez más, me reservo una descripción pormenorizada de los distintos enfoques de diseño del SDK para futuras publicaciones en aras de la brevedad.

Como veis, pasar de una prueba de concepto a un sistema productivo no es tarea sencilla en el mundo del blockchain, y es necesario tener un conocimiento profundo de la tecnología para hacer este salto de manera satisfactoria, y sin sobre costes innecesarios. Afortunadamente, la aspiración de productos como TrustOS es abstraer completamente de todas estas complejidades, y allanar lo más posible el salto productivo de cualquier caso de uso basado en blockchain.

Si tenéis interés en conocer en detalle todo nuestro trabajo en relación con el rendimiento de Hyperledger Fabric, os invito a leer esta serie de artículos en los que profundizamos en todo nuestro trabajo: