Original contribution

Atendiendo a lo anteriormente expuesto, en función de lo que se esté dispuesto a externalizar la cantidad de trabajo caben tres posibles alternativas:

1. Inclusión de las subastas como código Smart Contract en alguna de las cadenas de bloques públicas conocidas de segunda generación (Ethereum): En este primer caso, se haría uso de la gran cantidad de nodos de redes como Ethereum para incrementar la confianza y seguridad. Los contratos se redactarían en dichas redes y sería necesario pagar una cantidad de gas necesaria para ejecutarlos.

1.1 Ventajas: la dedicación de equipos al proyecto sería baja, ya que todo queda relegado a los recursos que posea la cadena de bloques en sí. En segundo lugar, como ya se ha comentado, la confianza aumentaría debido al alto número de usuarios de la cadena de bloques que la emplean diariamente. Por último, la simplificación del despliegue se reduciría en gran medida, ya que únicamente es necesario programar y diseñar los contratos, puesto que la Blockchain ya se encontraría probada y funcionando.

1.2 Inconvenientes:Ethereum cuenta con un tiempo de generación de bloques de entre 10 y 20 segundos. Esto no quiere decir, que cada una de las pujas de una

subasta concebida sobre Ethereum vaya a ser capaz de producirse, al menos cada 10 ó 20 segundos (recuérdese además, que no toda transacción es introducida a la primera en un bloque, es necesario esperar varios bloques hasta que los validadores la incluyen en los mismos). Deberá competir con el resto de transacciones de la red. Si este tiempo se incrementa mucho, hasta por ejemplo un tiempo medio de una hora entre que el proveedor declara su puja hasta que ésta se afianza en la red de Ethereum, desaparecería por completo el carácter de subasta, ya que sería imposible competir con semejantes diferencias de tiempo. Este hecho no debería suceder, puesto que nunca se presentan tiempos de inclusión en bloques tan altos, y siempre cabe la posibilidad de incrementar el precio de la comisión para que las pujas sean incluidas con prontitud en los bloques. En esta situación, las pujas sucederían cada pocos minutos. Adicionalmente, como Ethereum es una red basada en Proof of Stake, las transacciones que consuman más gas, o por las cuales se pague un precio más elevados se premiarán a la hora de entrar en los bloques en detrimento de las más pequeñas, por lo que puede darse la situación de que pujas más interesantes para la UME no encuentren su lugar porque existen otras por las que se ha pagado un mayor precio para que entren en los bloques.

Por otro lado, si se implementa una solución sobre Ethereum, sería necesario desarrollar una capa de aplicación sobre ésta, la cual permitiera mostrar el orden de transacciones, desglosando las de la subasta del resto de operaciones de la red. Este hecho complicaría la programación y además se perdería la continuidad y la linealidad de los bloques, ya que al haber otras aplicaciones en la cadena no se vería a priori dicha linealidad continua sin una aplicación que lo desglose. Sin embargo, para garantizar la integridad del resultado en una cadena de bloques, es bien sabido que es necesario descargarse la totalidad de la cadena, por lo que si algún proveedor deseara corroborar la veracidad de la subasta, se vería obligado a descargar toda la Blockchain de Ethereum, o bien confiar en la aplicación desarrollada por la UME. Si hace esto segundo,

Blockchain deja de tener sentido, ya que ya se está centralizando la confianza y se puede volver a un sistema de subastas tradicional. No obstante, aun incluyendo todos estos contratiempos en programación, esta alternativa sigue siendo mucho más sencilla que desarrollar una Blockchain privada.

Por último, es necesario señalar como inconveniente la dependencia de la criptomoneda Ether. Dado que será necesario pagar una cantidad de gas para fijar las transacciones, se tendría que obligar a aquellos proveedores participantes en la subasta a contar con algún tipo de monedero con el que interactuar con la red Ethereum, y tanto a la UME como a ellos mismos a depender del precio del gas. Esto puede ser un problema a largo plazo si se presentan fluctuaciones de mercado o se producen episodios de especulación con la criptomoneda.

2 Desarrollo de una Blockchain privada apoyándose en herramientas de software como

Azure, Amazon AWS o Hyperledger Burrow o Fabric: en este supuesto, la cadena de bloques sería privada, y el control de los nodos dependería de la UME y los proveedores.

Se podría considerar a los proveedores como agentes participantes en el proceso. En caso de emplear un algoritmo de consenso de tipo PBFT, los proveedores estarían interesados en introducir sus propios nodos en la red, en pos de garantizar la fiabilidad y veracidad del proceso. Esto obligaría a los proveedores a dedicar recursos permanentemente a la cadena. Si se emplea un algoritmo de la familia Proof of Authority, se puede contratar el servicio de unos agentes validadores, presumiblemente notarios identificados en algún registro estatal de notarios, tal como se hace en PoA Network o en Auctionity. Si esto se lleva a cabo, los proveedores no necesitan dedicar recursos permanentemente en la Blockchain, ya que van a ser los validadores los que estén permanentemente conectados. Si en algún momento desconfían de alguno de dichos validadores, sí podrán conectarse y participar en el proceso de votación de los validadores.

Sin embargo, como ya se apunta en el apartado 3.5 Algoritmia de consenso de bloques, es conveniente elaborar una solución mixta, en la que participen todas las organizaciones aportando sus propios nodos al conjunto, además de incluir a autoridades como notarios, empleando pues PoA y PBFT simultáneamente.

2.1 Ventajas: Si se posee el poder de diseño de la creación de la Blockchain, es posible configurar los tiempos de generación de bloques y adecuarlos a los tiempos que se considere razonables para una subasta. Además, permite la adopción del algoritmo de consenso que se considere necesario. Hyperledger

facilita herramientas para generar nodos que consensuen mediante PBFT, pero el código es de carácter open source y sería posible editarlo para conseguir un

PoA, si así se considera oportuno. Azure también permite alto margen de diseño. Se considera una ventaja contar con dichas herramientas de pago para agilizar el proceso de diseño, frente a las opciones de software libre.

En comparación con la opción anterior, al aportar los recursos de cómputo ya no se depende del pago de gas o de criptomoneda para incluir las transacciones en los bloques. Si se opta por un algoritmo diferente a PoW, el peso computacional será presumiblemente pequeño, y la dedicación de recursos será perfectamente asumible por la UME.

2.2 Inconvenientes: Al encontrarse fuera de redes Blockchain conocidas, puede generarse desconfianza a participar en el proceso de subasta, especialmente en los inicios. Esto se puede suplir si los proveedores participan del proceso de creación de la cadena, en cuyo caso deberá elegirse un algoritmo PBFT

combinado con PoA.

3 Empleo de aplicaciones web para subastas basadas en Blockchain: Cabría la opción de recurrir a los servicios de empresas como Auctionity que ya permiten la creación de subastas en redes privadas basadas en Ethereum.

3.1 Ventajas: Al delegar completamente el trabajo, no sería necesario disponer ni de los recursos ni del diseño y aprendizaje de lenguajes de programación que permitan crear Smart Contracts de tipo subasta. Bastaría con acomodarse a la

plantilla que proporciona Auctionity para acometer el proyecto. El grado de simplicidad desciende notablemente.

3.2 Inconvenientes: Dado que el formato de las subastas ya viene dado por el servicio, el grado de personalización es escaso. Puede que los tiempos de generación de bloque no se adapten a los requeridos por este caso de uso. Es posible que la plantilla tampoco se adapte al tipo de subasta, que evoluciona dinámicamente conforme se van agotando los productos requeridos por la UME. No se trata de una subasta casual, en la que existe un único producto y se puja por él, sino que son productos con una serie de unidades requeridas, los cuales se van agotando, y es posible que se desee cambiar las condiciones de adquisición conforme las existencias se van completando (por ejemplo, es posible que si se necesitan 200 camas y ya se ha conseguido adquirir 190, el precio que se pague por las 10 restantes se desee inferior dado que no se considera tan urgente. Esto se podría programar fácilmente en caso de una Blockchain privada con posibilidad de programar enteramente los contratos inteligentes) En la misma línea, puede que el consumo económico requerido por el servicio tampoco se adapte al coste real de la necesidad.