Transacciones - Prescrypto/RexChain GitHub Wiki

Transacciones

• Motivación.

  Nos inspiramos en el funcionamiento de Bitcoin y sus conceptos, es este caso se busca adaptar el concepto de Transacción en el flujo de data que para nuestro interes son recetas médicas prescriptas en Prescrypto y guardadas en la blockchain RexChain.

• Definición.

  Para comenzar supongamos que yo quiero guardar mis datos en RexChain para después transferirlos, al hacer esto se define una transacción inicial en RexChain, que es un elemento que contiene un output, validate, hash id y hash before, pero no contiene un input.

  • Output
    Es compuesto en el front-end por los campos data, public key de quien recibe la data, una signature con la private key de quien envía la data. Además se completa en el back-end con el campo readable igual a True.

  • Validate
    Este campo es de tipo booleano, y comprueba si la signature del Output es True o False, es decir verificamos que la data llego sin modificaciones desde el front-end.

  • Hash id
    Este campo aplica un hash con el método sha-256 a toda la información del Output, ademas de ser un id para dichos datos.

  • Previous hash
    Este campo es igual a cero, por ser un transacción inicial.

    

    Composición de una transacción inicial

  Observación.
  El campo readable es el indicador para saber si el usuario puede o no transferir los datos.

  Ahora que ya tengo una transacción inicial, me gustaría transferir mis datos, entonces se define una transacción como un elemento que contiene un input, output, validate, hash id y previous hash.

  Como podemos notar solo agregamos el concepto de input a la definición de transacción inicial, expliquemos que hace el concepto nuevo y como cambian los existentes.

  • Input
    Esta compuesto por un hash que apunta a los datos que forman parte del output de la transacción anterior, mediante su hash id y cambia el valor de readable a False.

  • Output
    Es compuesto en el front-end por los campos data, public key de quien recibe los datos, una signature con la private key de quien envía los datos. Además se completa en el back-end con el campo readable igual a True.

  • Validate
    Es una función que valida la transacción y lo hace de la siguien te forma:

    • Con el hash del input buscamos si coincide con algún hash id de una transacción;
    • Se obtiene la public key del output de esa transacción;
    • Se hace la verificación de la signature con dicha llave pública.
      • True:
        Quiere decir que el usuario si es el último dueño de los datos, la transferencia es válida.
      • False:
        Quiere decir que el usuario no es el último dueño de los datos, la transferencia no es válida.

  • Hash id
    Este campo aplica un hash con el método sha-256 a toda la información del Input y Output, además de ser un id para dichos datos.

  • Previous hash
    Este campo toma el valor del hash id de la transacción anterior.

    

    Comportamiento de una transacción inicial con una transacción en Back-End

  Al contener recetas una transacción, entonces se tiene que la relación que existe entre ellos es de muchos a muchos, es decir, una receta puede tener más de una transacción y una transacción puede tener más de una receta.

  Por último en la tabla siguiente se comparan los conceptos utilizados en RexChain y en Bitcoin, a manera de que si el lector conoce bitcoin pueda asociarlos.

  Bitcoin	RexChain
  Script input	Input
  Script output	Output
  Spent	Readable

• Comportamiento de las transacciones en Back-End.

  Se tiene que las transacciones están contenidas en bloques y la relación que existen entre ellos es de uno a muchos, es decir, un bloque puede tener muchas transacciones, pero una transacción no puede tener dos bloques.

  Ahora describimos lo que ocurre en RexChain cuando se genera una transacción:

  • Se comprueba que la firma del payload encriptado sea el correcto, con la llave pública de quien realiza la transaación. En caso de ser válida la firma, es valida la transacción, de caso contrario no.
  • Se realiza una proof of work mediante el algoritmo Hashcash¹
  • Si el hashcash:
    • Es válido, se crea un bloque con todas las transacciones anteriores válidas o no válidas
    • Es invalido, se queda en espera de una nueva transaccion para volver a intentar el proof of work

  Diagrama de flujo de una transacción (TX) en RexChain.

  ¹ En nuestro blog explicamos como funciona el Proof of Work en Prescrypto.

• Funcionamiento.

  Explicaremos en funcionamiento de las transacciones, contando las siguientes historias de usuario, haciendo referencia a una transacción inicial y una transacción respectivamente, para esto tenga presente el diagrama siguiente;

  

  Historial de transacciones de un receta

  1. Mariano tiene datos que quiere guardar en RexChain, al hacerlo él esta creando una transacción inicial, entonces ocurre:

     • En Front-End.
       • Mariano ingresa a una Wallet con sus llave pública y privada;
       • Encripta los datos con su llave pública;
       • Firma el payload² encriptado con su llave privada.
     • En Back-End.
       • Se comprueba la firma del payload encriptado, en el campo validate;
       • Se agrega el valor del campo readable en el output;
       • Se calcula el hash id de la transacción;
       • Se asigna el valor de cero al previous hash;
       • Se realiza la proof of work;
       • Se crea o no un block en RexChain.

     Observación
     En la imagen del "Comportamiento de una transacción inicial con una transacción en Back-End", se tiene que en este caso la llave privada de Mariano le corresponde la public key_rx0.

  2. Ahora que Mariano tiene sus datos en RexChain, quiere compartirlos con César, pues él esta esa interesado en sus datos; Mariano acepta transferir sus datos (a cambio puede recibe un pago con una criptomoneda); en este caso se tiene que se hace una transacción, entonces ocurre:

     • En Front-End
       • Mariano ingresa a una Wallet con sus llaves públicas y privadas;
       • Mariano recibe un lista de todas las transacciones a las que ha participado;
       • Mariano consulta sus transacciones tiene con readable true y la selecciona;
       • Se decriptan los datos con la llave privada de Mariano:
       • Se encriptan los datos con la llave pública de César;
       • Se firma el payload encriptado con la llave privada de Mariano.
     • En Back-End
       • Se comprueba la firma del payload encriptado, descripto en la definición de transacción;
       • Se agrega el valor del campo readable en el output;
       • Se calcula el hash id de la transacción;
       • Se asigna el valor correspondiente al previous hash, es decir, el valor del hash id de la Tx₀;
       • Se realiza la proof of work;
       • Se crea o no un block en RexChain.

     Observación
     En la imagen del "Comportamiento de una transacción inicial con una transacción en Back-End", se tiene que en este caso la llave privada de Mariano le corresponde la public key_rx0 y a César le corresponde la public key_rx1.

     Además Notemos que los datos para Mariano ahora tiene readable igual a False, por lo tanto Mariano no puede volverla a transferir y tampoco puede acceder a ellos; ya que ahora César es el dueño de los datos por que los datos estan encriptados con su llave pública.

     ² Diremos que el payload son los componentes del output generados en el back-end