En los dos ejemplos siguientes, vamos a situarnos en el futuro para seguir hablando de ARDOR. Supondremos que ya ha sido liberado y que está utilizándose. Describiremos dos casos de uso que ilustrarán las posibles utilidades de las Child Chains y su consumo como servicio.
Fecha: 24 Noviembre de 2017. ARDOR se liberó el 1 de Julio del mismo año.
Bernard, Lenina y John son tres socios de una empresa llamada Fruit Inc. dedicada a hacer películas de Animación 3D y a desarrollo de software. Están con el desarrollo de un proyecto un tanto sensible y quieren minimizar las fugas de información para sorprender lo máximo posible en la campaña de marketing y en el estreno. Para conseguir esto se les ha ocurrido crear un cliente de correo electrónico interno para los correos entre empleados de su empresa, que garantice lo máximo posible que los mensajes que envían sean totalmente privados, asegurando que solo los ven el remitente y el destinatario, y que nadie más pueda verlos. Logrando así que cada uno solamente sepa detalles de la parte en la que está involucrado en el proyecto, sin que haya nadie que tenga acceso a toda la información. Además quieren que los empleados puedan contar con la posibilidad de demostrar, en caso de requerirlo, la fecha y hora en la que enviaron una determinada información de forma fehaciente, por si se produjese algún conflicto o fuga de información. Han estudiado ARDOR y han visto que la plataforma puede ser perfecta para lo que necesitan. Ya se han puesto a programar la versión Beta del cliente de correo apoyado en ARDOR.
En el cliente de correo deben configurar lo que serían sus servidores de correo. Como van a usar la plataforma ARDOR, lo que ponen son varios nodos cualesquiera (privados o públicos) de ARDOR como servidores de correo.
Por otro lado han creado una Cadena Hija (Child Chain), donde la moneda o token la han llamado FRUIT. Han comprado inicialmente 100.000 ARDR de la Cadena Principal y han puesto una orden de compra de 1.000.000 de FRUIT a 0,1 ARDR cada uno. Ésto es necesario para dotar del liquidez al cambio ARDR/FRUIT y que se puedan comenzar a efectuar transacciones.
Los responsables de la empresa envían una circular a todos los empleados en la que les solicitan que creen una frase intransferible, y que guarden bien, que sera su Clave Privada. Una vez la tengan deben entrar en el Wallet de FRUIT para generar su Dirección pública de FRUIT y enviársela a la empresa. Conforme van enviando los empleados sus Direcciones de FRUIT, la empresa les entrega 1.000 FRUIT a cada empleado, solicitándoles que compren un alias igual a su nombre de usuario en la Child Chain de FRUIT, y que vinculen ese Alias a su Dirección de FRUIT.
Cada empleado abre el cliente de correo desarrollado por la empresa y en el configura:
Nombre de Usuario: <Nombre y Apellidos>
Cuenta de Usuario: <Alias comprado en FRUIT>
Contraseña: <Clave Privada>
El cliente de correo que se parece mucho a Outlook, cuenta con una libreta de direcciones que obtiene a partir de todos los alias en la cadena FRUIT.
Los empleados ya pueden enviarse mensajes a los diferentes Alias. La interfaz podría ser como la siguiente:
El software de correo desarrollado por debajo llama a la API de ARDOR, y realiza las operaciones necesarias para traducir los Alias en Direcciones de ARDOR y leer y enviar mensajes Encriptados a las mismas. Además guarda una copia local encriptada de los mensajes, etc… Vamos, todo lo que habitualmente hace un cliente de correo electrónico. Salvo que nadie puede ver el correo de los demás. Tampoco usa protocolo SMTP, que por otra parte se podría construir un proxy que lo haga compatible con SMTP, y usar ARDOR internamente y STMP para el correo externo, pero esto ya no nos ocupa…
Este sencillo ejemplo muestra un posible caso de uso de ARDOR en una Child Chain. No he pretendido profundizar demasiado, porque la idea solo es ilustrar las posibilidades, no entrar en detalles técnicos…
Para mantener el sistema los dueños de la empresa deberán periodicamente transferir FRUIT a las Direcciones de sus empleados, comprar ARDR y poner ordenes de compra de FRUIT por ARDR, para que haya liquidez. Todo esto es necesario porque cada vez que un empleado realiza el envío de un mensaje, se han de pagar los costes de esa transacción en FRUIT, y estos a su vez deben convertirse a ARDR porque a los forjadores no se les paga en FRUIT, se les paga siempre en ARDR.
El coste de la compra de ARDR periódicamente sería el coste que tendría para la empresa el uso de este correo interno. Es un concepto parecido a si una empresa explota una tecnología en Cloud, se le repercuten unos costes por el servicio consumido. En este caso el servicio lo dan los nodos de ARDOR y lo cobran los forjadores.
¡Ojo! Que este simple sistema de correo electrónico interno basado en ARDOR, no es complicado extenderlo a un Sistema de Mensajería Global que prescinda del protocolo SMTP, y que el uso del correo se lleve a cabo con la máxima privacidad… Discutiremos sobre esto en proximos ejemplos…
Fuentes:
http://nxt.org/roadmap/
http://nxter.org/es
http://ardorplatform.org/es
http://nxter.org/es/nxt-anuncia-ardor/
Deja un comentario