Blockchain
Blockchain » Capítulo 4. Modelos alternativos de blockchain: otros esquemas de consenso y autorización en blockchain » Principales propuestas de blockchain permisionadas
Página 9 de 13
Capítulo 4
Modelos alternativos de blockchain: otros esquemas de consenso y autorización en blockchain
En los capítulos 2 y 3 hemos analizado las bases de las plataformas Bitcoin y Ethereum. La primera plataforma surgió con el objetivo de crear un nuevo tipo de moneda sin necesidad de contar con bancos centrales. Como efecto paralelo de la creación de la criptomoneda bitcoin, la propuesta de Satoshi Nakamoto propició todo un conjunto de proyectos orientados a aprovechar las características de la estructura de datos en la que se apoya la plataforma Bitcoin. Así, la inmutabilidad de la blockchain de Bitcoin ha venido siendo interpretada como un recurso de gran potencial para entornos en los que se necesita registrar el estado de mercancías, de artículos y de todo tipo de productos. Con Ethereum, esas virtudes de la blockchain se ensanchan mediante la introducción de mecanismos para automatizar la ejecución de acciones en función del estado registrado en la blockchain. Ahora bien, tanto en el caso de Bitcoin como en el de Ethereum el registro de información en sus blockchains es un proceso con un coste computacional muy elevado. En efecto, en esas plataformas se asume que los agentes encargados de escribir la información no son confiables y, por ello, la inclusión de nuevos datos se realiza tras alcanzar un acuerdo explícito entre todos esos agentes. La PoW o prueba de trabajo es el procedimiento escogido en Bitcoin y Ethereum para hacer explícito dicho acuerdo y, tal y como hemos indicado en el capítulo 2, requiere un consumo energético muy elevado por parte de los agentes de escritura.
En este capítulo vamos a analizar modelos de blockchain en los que existe cierta confianza respecto a la actividad de los agentes de registro, lo que habilita el despliegue de esquemas de consenso menos exigentes que la PoW en términos computacionales. El desarrollo de estos esquemas ha dado origen a propuestas como Hyperledger, Corda y Ripple que son de alto interés en el ámbito empresarial a la hora de optimizar la consolidación y transferencia de información en consorcios y organismos. A diferencia de lo que ocurre en las blockchains públicas de Bitcoin y Ethereum, en estos modelos alternativos de blockchain se privilegia la eficiencia a costa de admitir el papel de los agentes de escritura como intermediarios de confianza. En las siguientes secciones se introducirán alternativas a las blockchains públicas. Las diversas variantes conservan la estructura de datos de las blockchains de Bitcoin y Ethereum, pero plantean modificaciones en el algoritmo de consenso y/o en la gestión de permisos de lectura y escritura en la blockchain.
El problema de los generales bizantinos y las dificultades del consenso en sistemas asíncronos
En los capítulos previos hemos visto que los ecosistemas blockchain están construidos sobre un sistema distribuido de almacenamiento y una red de comunicación descentralizada. Tanto en Bitcoin como en Ethereum, la escritura de información puede realizarla cualquier usuario que instale el software correspondiente y ponga su ordenador o nodo a trabajar en el minado de nuevos bloques. Este proceso de minado lleva asociada una competencia entre los nodos mineros que se resuelve de modo no determinístico, lo que impide que se sepa de antemano qué nodo será el encargado de escribir el siguiente bloque de la cadena. Por este motivo se dice que el minado en blockchain se asemeja a una lotería entre los mineros (Narayanan et al., 2016), característica que constituye la principal defensa frente a nodos que actúen de modo malicioso.
Desde un punto de vista general, la inclusión de transacciones en los bloques por parte de los mineros responde a la replicación de estado en sistemas distribuidos. Dado que no existe un nodo central que ordene los bloques de datos, ha de existir una coordinación entre los nodos de forma que la transición de estados se realice de forma consistente. Si estamos hablando de criptomoneda, la transición de estado se refiere a la actualización del balance financiero tras nuevas transacciones. Paxos es uno de los primeros sistemas en los que se considera la replicación de estado (Lamport, 1998) en una red con canales de comunicación no confiables y con una minoría de nodos que envían mensajes desactualizados tras perder la conexión con la red temporal o definitivamente. Como extensión de Paxos, aparecieron modelos de consenso en sistemas distribuidos cuyos nodos pueden comportarse de modo errático, debido a un fallo natural o intencionado. Este tipo de comportamiento se conoce como bizantino, de acuerdo con el modelado que Lamport propuso del consenso en sistemas distribuidos usando como analogía el problema de los generales bizantinos (Lamport et al., 1982).
En el “problema de los generales bizantinos” tres o más generales están sitiando una ciudad enemiga y deben consensuar si atacan o se retiran, teniendo en cuenta que si no llegan a un acuerdo serán derrotados. Los generales se comunican a través de mensajeros, siendo conscientes de que los mensajes pueden ser interceptados por el enemigo, manipulados por los mensajeros o incluir información falsa introducida intencionadamente por generales traidores. Lamport y sus colaboradores demuestran que se puede alcanzar consenso siempre que no haya más de un tercio de generales traidores.
Los sistemas de consenso basados en el modelo introducido por Lamport y colaboradores se conocen como “sistemas bizantinos tolerantes a fallos” o sistemas BFT (Byzantine Fault Tolerance). En 1999, Miguel Castro y Barbara Liskov (Castro y Liskov, 1999) extendieron el esquema BFT adecuándolo a contextos con redes de comunicación no confiables y creando los modelos PBFT (Practical Byzantine Fault Tolerance). Paxos, BFT y PBFT han dado lugar a un gran número de estudios teóricos en los últimos años y, de hecho, constituyen la base formal más sólida del problema del consenso en sistemas blockchain. Ahora bien, la implementación de estos esquemas requiere un mayor control sobre la identidad de los nodos de la red habilitados para realizar inserciones y validaciones de bloques.
En el caso del algoritmo de consenso utilizado en Bitcoin, no existe un enfoque tan sólido como el anterior. Así, el consenso de Nakamoto se ha mostrado efectivo en la práctica, si bien no han podido demostrarse de forma teórica las condiciones específicas en las que el sistema es resiliente frente a un volumen considerable de mineros maliciosos. Ataques como los destacados al final del capítulo son indicios sobre el marco de restricciones en las que es aplicable la PoW, pero todavía queda mucho trabajo por realizar. En cualquier caso, frente a BFT y PBFT, la PoW sí que consigue dar cabida a validadores anónimos de bloque, es decir, sí proporciona una respuesta efectiva al despliegue de un sistema totalmente descentralizado para la gestión del consenso.
En el capítulo 2 hemos subrayado que la PoW erosiona la sostenibilidad energética del ecosistema Bitcoin, algo que también es aplicable al modelo actual de consenso de Ethereum23, además de implicar problemas de gran calado en lo concerniente a la gobernanza de la blockchain. Como reacción a estos dos inconvenientes, ha surgido una pléyade de modelos de consenso distribuido. Dada la limitación de espacio de la presente obra, a continuación resumimos algunas de las principales propuestas e implementaciones en este campo:
PoS (Proof of Stake). En este caso, en el proceso de aceptación de bloque, se da preferencia a aquellos nodos que tienen en su posesión un mayor número de criptomonedas. Así, en lugar de solicitar a los validadores que son capaces de realizar una operación de alto coste computacional, lo que se les exige es que muestren que tienen en su poder un volumen suficiente de criptomonedas. Este esquema asume que los nodos que tienen una mayor cantidad de criptomonedas tienen especial interés en que la plataforma blockchain siga operativa y, por ello, acceden a resolver el desafío matemático asociado a la aceptación de nuevos bloques. PeerCoin es un ejemplo de implementación de PoS. Dentro de las propuestas más prometedoras de PoS cabe destacar el caso de Ouroboros (Kiayias et al., 2017).
DPoS (Delegated Proof of Stake). La PoS plantea ciertas dudas desde el punto de vista ético, así como desde el punto de vista de la gobernanza, dado el papel privilegiado de aquellos nodos que hacen acopio de criptomoneda. Para superar este tipo de limitaciones y como una iniciativa de descentralización de PoS, surge DPoS. En este nuevo modelo de consenso los usuarios de la plataforma eligen delegados y testigos encargados de escribir y verificar nuevos bloques. El sistema de elección de estos intermediarios se realiza por voto electrónico o a través de reuniones en las que los diversos candidatos a delegados y testigos presentan su historial como aval de su actividad. Algunas de las iniciativas blockchain que emplean DPoS son Bitshares, Steem y EOS.
PoA (Proof of Activity). Este modelo combina la PoW y la PoS. En la PoA el proceso de minado comienza con una PoW con varios mineros compitiendo por conseguir que su bloque sea el que finalmente quede consolidado en la blockchain. Cuando se encuentra un nuevo bloque, el sistema comienza a utilizar PoS y el nuevo bloque solo incluirá una cabecera y la dirección del minero que obtendrá la recompensa. Esa cabecera será posteriormente utilizada para seleccionar de forma aleatoria un nuevo grupo de validadores de entre los diversos nodos mineros de la red blockchain. Esta selección no es puramente aleatoria, ya que existe un sesgo en la selección, de forma que la probabilidad de ser seleccionado como validador aumenta con la cantidad de criptomoneda que se posea. Un ejemplo de plataforma que hace uso de PoA es Decred.
Modelos de control de acceso para la blockchain: blockchain públicas, permisionadas y privadas
Wüst y Gervais (2017) señalan que a la hora de emprender un proyecto blockchain la primera pregunta que hemos de plantearnos es si la estructura y características que ofrece blockchain son mejores que las que nos proporcionan las bases de datos tradicionales. Tal y como se puede observar en la figura 10, la respuesta a esta pregunta está fundamentalmente condicionada por el modelo de control de acceso que queremos para nuestros datos. El modelo requiere la concreción del tipo de agentes de escritura que van a tener capacidad de insertar información en el sistema de persistencia de información, así como la disponibilidad que debe tener el mecanismo de consolidación de información.
El análisis anterior lleva a identificar contextos en los que las blockchains no proporcionan una ventaja competitiva respecto a las bases de datos. Tal es el caso de aquellas situaciones en las que están claramente identificados los agentes que realizan la escritura de información que, además, son a todos los efectos interpretados por los usuarios como terceras partes confiables. En otros casos, el volumen de agentes de escritura existente, así como la necesidad de tener siempre disponible el medio de consolidación de información, lleva a considerar como conveniente la adopción de alguna suerte de blockchain. En este supuesto, la selección del modelo de blockchain va a depender de la naturaleza de los agentes de escritura y de la capacidad para acceder a la información que han de tener los usuarios del sistema blockchain. Si los agentes de escritura, que en este contexto no son confiables, no son conocidos, entonces habremos de optar por una blockchain pública como Bitcoin o Ethereum. Por el contrario, si los agentes de escritura son conocidos, entonces utilizaremos una blockchain permisionada o autorizada (como es el caso de Ripple o Hyperledger Fabric) si se desea que la verificación de la información se pueda realizar públicamente, o una blockchain privada (por ejemplo, Corda) si no se precisa verificabilidad pública.
Figura 10
Metodología para la elección del modelo de blockchain.
Fuente: Adaptada de la figura 1 de Wüst y Gervais (2017).
Blockchain privadas: Corda
Como ejemplo de blockchain privada vamos a considerar Corda. En 2014 se creaba R324, compañía que posteriormente lideraría un consorcio internacional de empresas —muchas de ellas financieras— para fomentar el uso de tecnología blockchain en este ecosistema. Como resultado se diseñó Corda (Brown et al., 2016), un sistema que, pese a las reticencias de un grueso importante de la comunidad blockchain, es muy similar en su naturaleza a todos los sistemas que hemos visto. De hecho, de este esfuerzo de R3 por distanciar Corda de los sistemas blockchain tradicionales surgió el término DLT que, como mencionamos en la introducción, puede ser interpretada como una generalización de los sistemas blockchain.
Para justificar que Corda no es un sistema blockchain estrictamente hablando, bastaría con considerar que no existe el concepto de bloque. De hecho, en Corda, las actualizaciones sobre el estado global se hacen directamente al nivel de transacciones.
Corda se define como un sistema DLT semiprivado (Hearn, 2016), en el sentido de que solo pueden unirse a la red y operar en ella quienes cuenten con una identidad validada. Además, es permisionado ya que, como veremos, hay nodos que tienen roles especiales, no pudiendo ser asumidos por todos. El foco principal de Corda son las aplicaciones financieras. Por ello, aunque permiten contratos inteligentes, en principio se limitan a funcionalidades financieras.
Corda ha sido también un sistema bastante pionero en muchos aspectos. Por ejemplo, en Corda no se comparten todas las transacciones con todos los nodos. En concreto, al crear un contrato inteligente, se establece quiénes van a ser los validadores de dicho contrato, es decir, quiénes se van a encargar de votar a favor o en contra de la aceptación de transacciones realizadas dentro de este contrato. Esto aumenta la agilidad en la validación de transacciones, ya que el resto de nodos son totalmente indiferentes al contrato en cuestión. Esto se asemeja bastante a los productos financieros: solamente las partes implicadas toman parte en la validez o no de un producto. De hecho, esto facilita la gestión de conflictos: en caso de que haya un contrato con un histórico conflictivo, las partes afectadas pueden ponerse de acuerdo en eliminar este histórico, lo cual es mucho más sencillo que tener que poner de acuerdo a toda la red.
Por otro lado, sí existe un conjunto de nodos que deben encargarse de vigilar que no se utiliza una misma transacción más de una vez. Este es el conocido como “servicio de unicidad” (uniqueness service). Los nodos que forman parte de este servicio se conocen como “notarios”, que además componen un servicio común a toda la red. El mínimo requisito que se impone a estos notarios es comprobar que una transacción no se ha utilizado anteriormente, sin necesidad de comprobar sus valores internos. De hecho, en este caso, es suficiente con enviar a estos notarios algo que les permita comprobar que la transacción es única. En concreto, se les envía la raíz del árbol de Merkle que se obtiene al agrupar los campos que forman la transacción de acuerdo con este tipo de árbol. De esta manera, los notarios pueden verificar que no se ha generado y utilizado previamente una transacción igual. Además, también aportan propiedades de privacidad, ya que no hay necesidad de que exista un único subconjunto de nodos que tenga acceso a toda la información de la red. Este tipo de notarios se conoce como “notarios no validadores”. No obstante, el hecho de que no validen los datos internos de cada transacción podría llegar a utilizarse en algún ataque. Por ello, existe lo que se conoce como “notarios validadores” que, además, deben tener acceso a los campos de la transacción y validarlos. La ventaja de los notarios validadores es que evitan determinados ataques, aunque la desventaja es que tales notarios sí tienen acceso a todos los datos de todas las transacciones de la red, degradando la privacidad total del sistema.
En cualquier caso, los notarios se ponen de acuerdo entre sí sobre la unicidad de una transacción utilizando algoritmos de consenso. Corda no obliga a utilizar uno concreto, aunque los más utilizados son los sistemas de consenso bizantino. En cuanto al modelo transaccional, Corda sigue el modelo UTXO de Bitcoin, que ya estudiamos en el capítulo 2. Es decir, cada transacción debe recibir una o más entradas y producir una o más salidas. Posteriormente, tales salidas podrán ser utilizadas como entradas para otras transacciones. En cuanto a la implementación de los contratos inteligentes, Corda se basa en la máquina virtual de Java, que restringe la posibilidad de conseguir un entorno determinista.
Otro aspecto diferenciador de Corda, derivado también de su foco en el ecosistema financiero, es el hecho de que cada contrato lleva asociado el código fuente que especifica las operaciones y condiciones que se deben cumplir y ejecutar. No obstante, también, incluye un texto en forma de prosa legal que especifica lo que se espera de dicho contrato. Aunque no es un campo obligatorio, sí se hace énfasis en que se espera que tal campo exista siempre, ya que en caso de disputa entre los participantes del contrato, toma precedencia el texto legal sobre el código del contrato.
Corda también introduce de forma nativa un componente que en otros sistemas tardó más en tenerse en cuenta. Nos referimos a los “oráculos”. Este componente, que veremos con más calma en el siguiente capítulo, permite introducir información del mundo exterior dentro del sistema blockchain (en este caso, DLT). Por ejemplo, el valor de una acción en un instante temporal concreto. Para ello, en Corda es posible adjuntar esta información, proveniente de un oráculo confiable, junto con una firma digital de la información, firmada por el oráculo. De esta forma, cualquier transacción que dependa de un valor que requiera información del exterior puede hacer referencia a esta información adjunta.
En resumidas cuentas, Corda, sin ser un sistema blockchain en sentido estricto, está fuertemente inspirado por estos sistemas. De hecho, combina aspectos de varios de ellos, reduciendo su caso de uso al contexto financiero y, de este modo, enfocando sus principios de diseño para ser más eficiente en este entorno.
Principales propuestas de blockchain permisionadas
Las blockchains permisionadas han recibido especial atención por parte de empresas y asociaciones de empresas. Estas posibilitan introducir ciertos controles adicionales que hacen que sea más fácil compatibilizar las propiedades de resiliencia y trazabilidad que proporcionan las blockchains públicas, con los casos de uso más restrictivos del mundo corporativo.
Estos sistemas se sitúan, pues, en un punto intermedio entre el extremo de los sistemas descentralizados sin un único punto de fallo, y el opuesto de los sistemas centralizados tradicionales donde una única autoridad lo decide todo. Consecuentemente, no están exentos de crítica por parte de ambos mundos, con frecuencia con matices éticos y con eco en cuestiones de gobernanza corporativa. Al margen de posibles prejuicios y reservas, parece oportuno reconocer el mérito de estos sistemas en su intento de incorporar nuevas arquitecturas tecnológicas en entornos adscritos a regulaciones estrictas, y con las que los sistemas de difícil regulación (como son las blockchains públicas) son directamente incompatibles.
A continuación se comentarán con más detalle las dos blockchains permisionadas más extendidas: Hyperledger y Ripple.
Hyperledger
Más que un sistema blockchain concreto, Hyperledger es un consorcio de organizaciones que se han unido para fomentar el desarrollo de la tecnología blockchain para entornos corporativos a través de código abierto25. A marzo de 2019, cuentan con diez proyectos, enfocados en distintos aspectos o aportando aspectos diferenciales con respecto al resto. Por ejemplo, cuentan con un conjunto de herramientas para facilitar el despliegue y gestión de sistemas blockchain (el proyecto Cello), o un explorador de cadenas de bloques (el proyecto Explorer).
No obstante, el proyecto bandera de Hyperledger, iniciado por IBM con el nombre de Openblockchain, y posteriormente cedido al consorcio, es Fabric: un sistema blockchain privado y permisionado que pretende ser altamente configurable, de manera que se puedan utilizar diferentes algoritmos de consenso, diferentes modos de gestión de identidad, etc., con el fin de poder adaptarse a la mayor cantidad de escenarios posibles.
En efecto, Hyperledger Fabric o, simplemente, Fabric, está basada en un diseño modular que permite diferenciar las fases de replicación de estado. Para ello, Fabric abandona la arquitectura “ordenación-ejecución” de otras blockchains permisionadas como Tendermint26, Chain27 o Quorum28, de modo que estará basada en un esquema “ejecución-ordenación-validación” (Androulakis et al., 2018a). De acuerdo con sus diseñadores, este cambio de arquitectura permite mejorar el rendimiento de la blockchain al mismo tiempo que habilita una mayor protección frente a ataques por denegación de servicio y una gestión más eficiente de la confidencialidad.
La incorporación de una nueva capa de abstracción en Fabric está asociada a la identificación de distintos nodos de acuerdo con funcionalidades específicas en las etapas de consenso y de replicación de estado de una blockchain. En concreto, en Fabric se distinguen cuatro tipos de nodos:
Clientes que se encargan de enviar propuestas de transacciones, y que también colaboran en las tareas de ejecución de transacciones y de envío por difusión (broadcast) de transacciones para su ordenamiento.
Nodos ejecutivos (peers) que se encargan de ejecutar y validar transacciones, además de almacenar el registro completo de transacciones. Esto es, existirá una réplica del registro de transacciones en cada uno de los nodos ejecutivos.
Nodos verificadores (endorsers) que son un subconjunto de los nodos ejecutivos que tienen por misión ejecutar las propuestas de transacciones. El conjunto de nodos verificadores de una transacción está dictaminado por el contrato inteligente correspondiente, que en el caso de Fabric se denomina chaincode.
Nodos de ordenación (orderers) que tienen por objetivo establecer el orden correcto de transacciones en Fabric, lo cual involucra la identificación de las transacciones que implican un cambio de estado, de las dependencias que han sido procesadas durante la fase de ejecución y de las firmas digitales de los nodos verificadores.
La asignación de roles en Fabric depende de una entidad central que actúa como autoridad de certificación de acuerdo con lo establecido en el estándar X.509 (Cooper et al., 2008). Esta entidad se denomina MSP (Membership Service Provider) y es la piedra central de la infraestructura de clave pública asociada a una blockchain de tipo Fabric. Asimismo, las versiones actuales de Fabric incorporan la funcionalidad necesaria para que la MSP pueda generar y administrar identidades seudoanónimas29, lo que supone una contribución relevante en términos de protección de la privacidad de los usuarios y entidades gestionadas por la correspondiente blockchain.
Tal y como se ha reseñado anteriormente, la asignación de roles en Fabric está asociada a la realización de las diversas tareas de las tres capas lógicas del protocolo de consenso y de replicación de estado de la blockchain. Así, durante la fase de ejecución, los clientes firman sus propuestas de transacción y, en virtud del chaincode correspondiente, las envían a uno o más nodos verificadores. Cada nodo verificador ejecuta la transacción en un entorno virtual que está aislado del entorno normal de ejecución del resto de la red. Es importante tener en cuenta que la ejecución de la transacción depende del flujo de operación definido en el chaincode y del estado del registro de transacciones, y que el resultado de la ejecución no modificará el estado del registro de transacciones. En la medida que el resultado de la ejecución tiene que modificar el estado de la blockchain en algún momento, dicho resultado ha de almacenarse de modo temporal. Esto lo lleva a cabo una nueva entidad, la PTM (Peer Transaction Manager), que crea una estructura llamada writeset con la actualización de estados, y una segunda estructura denominada readset que contiene las dependencias de la transacción que ha sido ejecutada en el entorno de simulación. Tras la simulación, el nodo verificador devuelve al cliente este par de estructuras y un conjunto de metadatos, todo ello como parte de un paquete de respuesta que está firmado digitalmente.
Para que se inicie la siguiente fase es necesario que el cliente tenga un número mínimo (que está definido en el chaincode) de respuestas firmadas y congruentes entre sí (esto es, con el mismo conjunto de valores en writeset y readset). Una vez se ha satisfecho esta condición, el cliente crea una nueva transacción y la envía por difusión a los nodos de ordenación. Estos nodos se encargan de recibir transacciones y agruparlas en bloques, de forma que la consolidación de un bloque requerirá alcanzar un consenso de forma distribuida. En Fabric, el protocolo de consenso del servicio de ordenación no está definido de modo cerrado, sino que se deja abierta la posibilidad de incorporar nuevas implementaciones de acuerdo con la interfaz de programación definida en la especificación de Fabric.
No obstante, por defecto, Fabric trabaja con la implementación de ZooKeeper de Kafka30. Aquí conviene tener en cuenta que los nodos de Fabric son nodos autenticados, lo que abre el camino para utilizar variantes de BFT como base del servicio de ordenación de transacciones31.
Una vez se ha construido un bloque en la fase de ordenación, los nodos ejecutivos inician la verificación de cada una de las transacciones. Este proceso de verificación se realiza de modo paralelo para cada una de las transacciones del bloque, y comprende la comparación de los datos de tipo readset con el estado en el registro de la blockchain, así como la actualización del estado de dicho registro en función de los valores incluidos en los datos de tipo writeset. En este punto es importante destacar que Fabric almacena todas las transacciones, incluidas aquellas que fueran rechazadas durante el proceso de verificación. Esto es de vital importancia para el proceso de auditoría, ya que Fabric permite identificar de modo biunívoco el nodo que ha originado una cierta transacción.
Sin duda, una de las aportaciones más relevantes de Fabric a la tecnología blockchain viene dada por su capacidad para efectuar trazabilidad de operaciones y atribución de responsabilidad. Ahora bien, también hemos de recalcar las ventajas que Fabric ofrece en lo concerniente a la escalabilidad y la protección de la confidencialidad gracias a la inclusión de una nueva capa de abstracción de su modelo de datos, los denominados canales (channels). En una red de tipo Fabric, es posible tener múltiples blockchains conectadas a un único servicio de ordenamiento, pero permitiendo que el conjunto de nodos ejecutivos de cada blockhain sea distinto. La ordenación de transacciones en un canal es independiente del resto y, en consecuencia, el consenso y replicación de estado también lo son. Por ello, podemos interpretar los canales de Fabric como un procedimiento de autorización adicional a la autenticación gestionada por la MSP. Es más, la funcionalidad de estos canales se puede extender para construir protocolos avanzados de comunicación entre canales y para la implementación de oráculos mediante canales constituidos por nodos ejecutivos seleccionados a tal efecto (Androulakis et al., 2018b).
Ripple
Hacia 2007, antes de la publicación de Bitcoin, Ghosh y sus colaboradores publicaban un estudio de redes de confianza en el contexto de pagos (Ghosh et al., 2007) que daría lugar a RipplePay, antecesor directo de Ripple. Tanto el sistema original como su sucesor se centran en el problema de permitir pagos en una red en la que no hay una confianza directa entre el pagador y el receptor. En concreto, se describe el proceso de pago como la transferencia de “obligaciones” en el sentido de “pagaré” (IOU, abreviación de I Owe You), de modo que los pagos en sistemas monetarios equivalen a la confianza que tiene el receptor del pago en que el “mecanismo” que utiliza el pagador está respaldado por algo fiable, garantizado de algún modo por un emisor de dicho “mecanismo” de pago.
No obstante, en RipplePay no se parte de la existencia de una autoridad al estilo de un Banco Central en el que confían todos los usuarios del sistema. Al contrario, el problema que se pretende resolver se basa en un contexto más descentralizado en el que puede que la autoridad que respalda las obligaciones del pagador no sea considerada, de forma directa, como una autoridad válida por el receptor del pago. Es decir, RipplePay se centra en encontrar un “camino de confianza”. Por ejemplo, puede que el receptor A no confíe en los IOU del pagador C pero sí confíe en los de un tercero, B, que a su vez confía en los de C. De este modo, el camino de confianza sería A-B-C, y C cambiaría sus IOU por el equivalente de B, para darle a A estos últimos. Cada uno de estos saltos se puede ver como líneas de confianza entre los dos extremos.
En Ripple, esta filosofía se mantiene en cierto modo, aunque poniendo más énfasis en el cambio de divisa. En concreto, dentro de la red de Ripple existen unas entidades especiales conocidas como pasarelas o gateways. Por un lado, una pasarela en Ripple permite establecer líneas de confianza con el mundo exterior. Es decir, un usuario A puede hacer un depósito de 1.000 euros a una pasarela P y, a partir de ese momento, A tendrá un crédito de 1.000 euros con P, que podrá utilizar para hacer pagos dentro de Ripple. Es decir, A confía en que P vaya a mantenerle su dinero. Por otro lado, las pasarelas pueden permitir también intercambios de divisas internamente. Si la pasarela P soporta tanto euros como dólares, el usuario A puede pedir a P cambiar parte de los 1.000 euros a dólares. Sin embargo, para que esta funcionalidad de intercambio de divisas no dependa únicamente de las pasarelas, cualquier usuario de Ripple puede hacer ofertas de compraventa de divisas de un tipo por divisas del otro. En este sentido, este proceso funciona como un mercado tradicional: la oferta de compra a un precio más bajo será más atractiva para el comprador, y viceversa. Las pasarelas también son responsables de mantener procesos para prevención de blanqueo de dinero o AML (Anti Money Laundering) o de recabar la información legal necesaria sobre sus usuarios del tipo “conoce a tu cliente” o KYC (Know Your Customer), que serán ampliadas en el capítulo 5. Hasta aquí todo se parece bastante al sistema bancario tradicional, incluyendo la confianza que el usuario deposita en la pasarela y los mecanismos de control y liquidez.
La primera diferencia aparece con la existencia de una moneda interna de Ripple, conocida como XRP. Una opción típica de una pasarela es aceptar pagos en dinero fiat tradicional (euros, dólares, etc.) a cambio de crédito interno en XRP. Una vez dentro de Ripple, estos XRP pueden enviarse a cualquier otra pasarela. Es decir, el XRP actúa como moneda universal dentro de Ripple.
Otra diferencia, también fundamental, es que cada transacción en Ripple, implique las divisas que implique, “destruye” una cantidad variable de XRP. Esta variación depende de forma directa de lo sobrecargada que esté la red. Es decir, si hay mucha actividad, las tasas serán más altas; si hay poca, serán más bajas. Este es un mecanismo nativo de protección ante ataques de denegación de servicio, ya que un atacante que quiera bloquear la red emitiendo muchas transacciones (por ejemplo, de un valor muy bajo), acabará provocando que las tasas en XRP aumenten y, por lo tanto, tendrá que gastar más dinero en enviar sus transacciones, quedándose cada vez más rápido sin los XRP necesarios para seguir emitiendo transferencias y mantener su ataque de denegación.
El mecanismo de consenso utilizado se conoce como Ripple Protocol Consensus Algorithm o RPCA (Schwartz et al., 2014). Este algoritmo, ejecutado por los nodos validadores de la red, procede de forma iterativa y por fases. En cada iteración, durante la primera fase, cada validador almacena las transacciones nuevas que haya recibido y las distribuye como su conjunto candidato. En la segunda fase, cada validador vota cuáles son las transacciones que considera válidas de entre todas las que ha recibido de sus validadores de confianza. En una tercera fase, cada validador descarta las transacciones que no hayan recibido un respaldo de un determinado porcentaje de sus validadores de confianza. Este proceso se repite, incrementando el porcentaje de “corte”, hasta que al menos el 80% de los validadores de confianza vote favorablemente. Normalmente, el porcentaje inicial es del 50%. El conjunto de “validadores de confianza” que hemos mencionado se conoce como la UNL (Unified Node List) de cada nodo. Es, básicamente, el conjunto de nodos validadores en los que cada nodo deposita su confianza para decidir la evolución del sistema. Cada nodo es libre de elegir sus validadores de confianza (e incluso el porcentaje de respaldo exigido). De esta manera, Ripple “esquiva” la limitación tradicional de escalabilidad en protocolos de consenso distribuido tradicionales, ya que en lugar de que cada nodo espere a que todos los demás nodos se pongan de acuerdo, simplemente tiene que esperar a que se pongan de acuerdo los nodos de su UNL. Esto no implica que cada nodo vaya a ver un estado distinto del sistema: siempre y cuando haya una mínima intersección entre las UNL de cada nodo y no haya más de un determinado porcentaje de validadores maliciosos, el consenso global está garantizado. En concreto, según Schwartz et al. (2014), RPCA soporta un 20% de nodos maliciosos y requiere al menos un 20% de intersección entre las UNL de los nodos de la red. En la práctica, existe un listado de nodos validadores fiables32, entre los cuales todos los nodos de la red suelen elegir a sus validadores de confianza. Esto ayuda a garantizar la intersección mínima entre todas las UNL, pero también supone un riesgo de recentralización.
Como podemos apreciar, Ripple tiene muchos aspectos en común con el sistema bancario al que estamos acostumbrados: el establecimiento de líneas de confianza por medio de IOU, la orientación al cambio de divisa, el concepto de pasarelas, quienes además tienen como requisito soportar procedimientos de KYC y AML, etc. En la práctica, también se favorece que haya ciertos validadores confiables dado que cualquiera puede crear un validador. En todo caso, si alguien incluye en su UNL validadores que no son comúnmente aceptados por la mayoría de la red, corre el riesgo de ver una versión distinta del histórico de transacciones y, por lo tanto, ser vulnerable a ataques. Este tipo de consideraciones hacen que, de facto, Ripple funcione como un sistema permisionado ya que, aunque cualquiera podría actuar como pasarela o como validador, solo unos pocos acaban siéndolo.