Proyecto IberBlockTrack: estructura blockchain de las materias primas, los productos ibéricos y los operadores

Descripción del backend

En esta tercera entrada del proyecto IberBlockTrack: tecnología blockchain aplicada a la trazabilidad del producto ibérico detallaremos la estructura del backend sobre el que sustenta nuestra aplicación. El backend que vamos a presentar es una versión funcional que puede estar sujeta a cambios futuros, según necesidades de las entidades del sector ibérico.

Como comentamos en anteriores entradas, las DAPPS (o Aplicaciones Descentralizadas) constituyen su backend por uno o varios contratos inteligentes (smart contracts) que pueden interaccionar entre si y que gestionan la interacción con la cadena de bloques.

Para constituir la lógica de nuestra aplicación nos hemos apoyado en la Norma de Calidad Ibérica (RD 4/2014) y sus últimas revisiones, por las cuales, se define las características de la calidad y marcado de los productos ibéricos presentes en el mercado español, así como, la información necesaria que debe figurar, por cada una de las partes involucradas en el proceso, en el RT (Registro de Trazabilidad). En la figura 1, podemos observar un flujo simplificado de trazabilidad de un producto ibérico tras analizar la legislación mencionada.

Figura 1: Flujo simplificado de trazabilidad de un producto ibérico

Tras revisar el flujo anterior, podemos destacar la existencia de tres tipos de entidades necesarias para llevar acabo nuestra aplicación: las materias primas, los productos ibéricos y los operadores ibéricos.

Las materias primas hacen referencia al ganado del que se derivarán los diferentes productos ibéricos. Estás pertenecerán a una explotación donde se irá sometiendo a inspecciones (para controlar que evoluciona correctamente) hasta el momento de ir al matadero. Después del sacrificio, este es despiezado generando los diferentes productos correspondientes al lote perteneciente. Para la correcta trazabilidad de esta entidad necesitaremos almacenar en la blockchain para cada materia:

Identificador del propietario (explotación de donde proviene la materia prima).
Raza
Alimentación
Edad
Peso
Listado de inspecciones (Estas inspecciones serán realizada por algún operador habilitado. Cada inspección debe almacenar la fecha, el texto del informe y el responsable de la inspección).
Información referente al sacrificio en matadero (fecha en la que llego al matadero, fecha del sacrificio, lote de sacrificio y matadero encargado de la misma).
Información referente al despiece en sala de despiece (fecha en la que llego, fecha de despiece y responsable del despiece).

En la figura 2, podemos observar como se almacenaría todo esta información en un smart contract en Solidity.

Figura 2: Estructura de información para cada materia prima

Por otro lado, los productos ibéricos son derivados de las materias primas durante el periodo de despiece. Posteriormente, estos son llevados a diferentes industrias donde terminan su proceso de elaboración y se comercializan con los comercios minoristas (una vez se ha acreditado la calidad del producto, es decir que no existe ningún dato abrupto en el proceso de trazabilidad) donde, finalmente, son vendidos a los usuarios finales. Para la correcta trazabilidad de cada producto necesitaremos almacenar en la blockchain:

Identificador de la materia prima que proviene (de modo que podamos generar el registro completo de trazabilidad a través de un producto, desde la granja hasta la mesa).
Lote de producto.
Denominación para la venta (Nombre que va a tener cuando lo comercializamos).
Peso.
Estado en el que se encuentra el producto (Procesando, Listo, En venta o Vendido).
Si se a escaneado su código QR o no (necesario para emitir el NFT para el dueño final del producto, de modo que el usuario siempre disponga de una activo digital mediante el que pueda consultar la información de su producto. Este NFT solo se emitirá la primera vez que se escanea el código QR de cada producto).
Etiquetado de colores (Negro-Jamón de Bellota 100% Ibérico, Verde-Jamón de Cebo de Campo Ibérico, Rojo-Jamón de Bellota Ibérico, Blanco-Jamón de Cebo Ibérico, Amarillo-Por asignar).
Listado de operaciones llevadas acabo por cada operador sobre el producto hasta su comercialización (Para cada operación debemos saber que operador la ha realizado, el tipo de operación, la fecha y opcionalmente algún mensaje informativo de la misma).

En la figura 3, podemos observar como se almacenaría toda esta información en un smart contract en Solidity.

Figura 3: Estructura de información para cada producto

Finalmente, la última entidad, son los operadores ibéricos. Este entidad representa a los diferentes agentes que interaccionan con los productos y las materias primas hasta su comercialización. La información principal que debemos almacenar sera:

Denominación del operador(Nombre de la empresa o entidad).
Código del Registro General Sanitario de Empresas Alimentarias (RGSEAA).
Dirección publica Wallet.
Otra información opcional (Logo, Dirección, Teléfono, Código Postal, etc..).

Cada operador tendrá asociada una o varias wallet. De este modo, cuando el operador quiera interaccionar con el sistema tendrá que conectar su wallet. Al conectar su wallet, asociaremos todas las operaciones a ese operador. De este modo aseguramos tanto el acceso seguro (solo las wallet permitidas tendrán acceso a operaciones especiales) como la trazabilidad de las operaciones.

En la figura 4, podemos observar como se almacenaría toda esta información en un smart contract en Solidity.

Figura 4: Estructura de información para cada operador

Para trabajar y manipular las estructuras de información anteriores de una manera mucho más flexible y escalable en el futuro, hemos decidido diseñar un contrato inteligente para cada entidad, de modo que cada contrato gestione las interacciones con la blockchain sobre su entidad. Este enfoque ofrece numerosas ventajas frente a tener un único contrato inteligente que gestione todo:

Mayor escalabilidad y flexibilidad, de modo, que incorporan nuevas entidades al sistema o funcionalidades sea más sencillo.
Reducción de complejidad de los contratos inteligentes al disgregar las funcionalidades.
Los errores están más localizados
Controlamos mejor la información que se almacena.

Sin embargo, no está exenta de inconvenientes:

Mayor coste en el despliegue de la aplicación (en vez de desplegar un solo contrato tenemos que desplegar varios, no obstante, es asumible puesto que solo se despliega una vez).
Lógica de gestión mayor (debemos tener interaccionar con varios contratos para realizar algunas operaciones).
Puede no cumplir con ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) como los sistemas de bases de datos tradicionales (CRÍTICO).

Para solventar el problema de la lógica de gestión y ACID, hemos diseñado otro contrato inteligente que actuá como controlador entre el resto (“IberBlockTrackManager”). De este modo, la aplicación solo deberá interactuar con este contrato, quien gestionará las operaciones con el resto de contratos inteligentes y garantiza que se ejecuten en una única transacción. En la figura 5, podemos observar un esquema de los componentes que forman el backend de nuestra aplicación.

Otra cuestión a tener en cuenta es que tenemos diferentes tipos de operadores y cada uno puede realizar una serie de operaciones concretas (por ejemplo, un operador de tipo explotación podrá dar de alta nuevas materias primas en el sistema, mientras, que un operador de tipo matadero no podrá). Los principales tipos de operadores son:

Explotación: Encargado de la criá de las materias primas hasta su envío al matadero. Dar de alta nuevas materias, actualizar su información, consultar las inspecciones y enviar al matadero.
Matadero: Encargado del sacrificio de las materias primas asignadas y posterior envío a las salas de despiece. Crear lote de sacrificio, sacrificar y enviar a despiece.
Despiece: Encargado de despiezar las materias primas sacrificadas, realizar el despiece y establecer lote de productos.
Industria: Encargado de procesar los productos generados en el despiece. Finalmente comercializan los productos con los comercios.
Comercio: Gestionan la venta de productos al público.
Inspector: Realizar inspecciones periódicas sobre el estado de materias primas.
Acreditador: Acreditar la calidad de los productos, revisando el registro de trazabilidad y observando que no exista ningún valor atípico.

Para cubrir esta funcionalidad, se ha implementado un acceso por roles gestionado por el contrato IberBlockTrack Manager. Cada funcionalidad del contrato solo puede ser usada por usuarios con un rol o roles específicos y los roles son asignados a las direcciones públicas de cada wallet. De este modo, cuando un usuario conecta su wallet en la aplicación, se identifica si pertenece a algún operador y sus roles, detonando, en consecuencia, las operaciones que puede realizar en el sistema.

Al mismo tiempo este acceso por roles también garantiza que el contrato Manager sea el único que pueda interactuar con los contratos de las entidades mediante la asignación de rol de administrador a la dirección pública del contrato desplegado. En la figura 6, podemos observar un esquema del acceso por roles.

Figura 6: Acceso a las funcionalidades del sistema basado en roles

Con todo esto, nuestro backend esta listo para ser utilizado por el fronted. En la próxima entrega, mostraremos como hemos conectado nuestro backend con el fronted, las principales funcionalidades del sistema para cada usuario y un ejemplo completo de trazabilidad del sistema.

Consulta también las demás publicaciones sobre este proyecto:

Deja un comentario Cancelar respuesta