cheques con blockchain
TRANSCRIPT
Universidad de Los Andes Departamento de Sistemas y Computación
Desmaterialización de títulos valores con Blockchain
aplicado a Cheques
Mónica Paola Bayona Latorre – [email protected] – 202629599
Asesor: Darío Ernesto Correal
Coasesora: Maria Lorena Flórez
Diciembre, 2020
0.Resumen
En este proyecto se propone desmaterializar los cheques inmaterializados usando Hyperledger
Sawtooth, con el fin de que muchos de los problemas relacionados con los cheques en la
actualidad. Por esto se propuso una arquitectura y se implementó en una aplicación que
cumple los requisitos legales de los cheques. También se creó un MVP que muestra y valida la
solución además de cumplir con los requisitos legales.
1. Introducción
1.1 Motivación y problemas identificados
En la actualidad los cheques son muy usados en Colombia, pero este documento es muy
propenso a ser usado en estafas y fraudes. Esto es debido a que al ser un documento físico no
se puede validar sino cuando se llega a al banco para ser cobrado. Por otra parte, al ser un
documento físico se puede perder, extraviar o ser robado y caer en manos de personas que van
a realizar actividades ilegales con el cheque.
1.2 Como sería una solución
Con el fin de resolver los problemas anteriormente presentados, se propone una solución que
permita:
1. Crear un cheque virtual e inmaterializado que sea legalmente vinculante.
2. Poder crear el cheque en favor de un beneficiario con cierto monto de dinero.
3. Si un usuario es beneficiario de un cheque poder endosarlo en favor de otro
beneficiario, o hacer cambios en su estado.
4. Ver la cadena de endosos con su fecha de manera clara.
5. Poder ver el historial de estados de un cheque.
1.3 Diseño e implementación
Con el fin de cumplir los anteriores requerimientos se propone usar la tecnología de Blockchain,
ya que esta se caracteriza por permitir autenticar las transacciones que ocurran en ella, tener
una historia de todas las transacciones ocurridas y asegurar que los datos no van a ser
modificados sin el consentimiento de todas las partes involucradas. La tecnología de Blockchain
usada para el proyecto fue Hyperledger Sawtooth, esta se caracteriza también por su facilidad
de implementar Smart Contracts.
Teniendo en cuenta la tecnología elegida se procedió a diseñar una arquitectura de solución
con el fin de cumplir los objetivos expuestos. Sobre esta arquitectura se creó un prototipo que
incluyo un cliente web, servidor, base de datos, listener de eventos y el desarrollo del
procesador de transacciones de Sawtooth para así poder implementar un Smart Contract
personalizado para el ámbito de cheques.
1.4 Resultados Obtenidos
Después de realizar el proyecto se concluyó que era posible desarrollar e implementar una
solución donde los cheques son desmaterializados haciendo uso de tecnologías de Blockchain.
También se logró implementar un Smart Contract específico para el caso con él se disminuyen
muchas de las vulnerabilidades de los cheques en mundo real.
1.5 Estructura del Documento
El documento se organizó de manera que primero se tiene el marco teórico y legal además de
una explicación de la problemática y los objetivos, después se procede a presentar la solución
desarrollada y sus resultados.
1.6 Agradecimientos
Quiero agradecer al asesor de mi proyecto de grado, el profesor Darío Correal, quien en todo
momento me estuvo guiando en el desarrollo de este proyecto. A la profesora Lorena Flórez,
quienme introdujo a todo el tema de chques y me guio en todos los temas legales. A Luis
Esteban Flórez, asistente doctoral y líder del laboratorio Blockchain de la universidad quien me
brindo una ayuda invaluable en los temas de infraestructura y despliegue del proyecto.
2. Descripción General
2.1 Objetivos
El primer objetivo es diseñar una arquitectura de referencia utilizando tecnologías Blockchain
para desmaterializar cheques. El segundo objetivo es, basándose en la arquitectura de
referencia, implementar una arquitectura de solución la cual responda a los requerimientos. El
tercer objetivo es implementar un prototipo usando la arquitectura de solución y el cuarto y
último es asegurarse que las características del prototipo cumplen todos los términos técnicos y
legales.
2.2 Marco Legal
Cheque
Según el artículo 621 del Código de comercio, el cheque es un título valor que legitima el
ejercicio de un derecho descrito en el titulo valor. El cheque nace jurídicamente con la firma de
quien lo crea y debe contener la mención del derecho que en el titulo incorpora, la firma de
quien lo crea, el nombre del banco librado, la orden incondicional de pagar una determinada
suma de dinero y la indicación de ser pagadero a la orden o al portador. En este proyecto se
omitirá la parte del nombre del banco ya que no aplica en este caso.
Validez de los cheques virtuales
Primero, en la Ley 527 de 1999 se establece que un documento digital es equivalente a un
documento físico, si se cumplen requisitos de integridad, autenticidad, no repudio y
accesibilidad de la información. (Congreso de Colombia, 1999) Uno de los requerimientos
descritos es el uso de una firma digital o electrónica en el documento digital. Según el artículo 3
del decreto 2364 de 2012, el requerimiento se puede cumplir con una firma electrónica.
Además, en el artículo 1, se muestra que esta firma puede ser: “Métodos tales como, códigos,
contraseñas, datos biométricos, o claves criptográficas privadas, que permite identificar a una
persona, en relación con un mensaje de datos, siempre y cuando el mismo sea confiable y
apropiado respecto de los fines para los que se utiliza la firma, atendidas todas las
circunstancias del caso, así como cualquier acuerdo pertinente.” (Decreto 2364 de 2012) La
diferencia con una firma digital es “[…] que [las firmas digitales] pueden existir solamente
cuando una Entidad Certificadora de firmas emite un certificado de firma digital para acreditar
la identidad de la persona.” (Chaparro, 2019).
2.3 Marco Teórico
Blockchain
Es una base de datos de datos compartida mediante bloques, que como su nombre lo indica,
forman una cadena. Estos bloques se cierran con un hash y el siguiente bloque se abre con esa
misma firma criptográfica para de esta manera asegurar que la información encriptada no ha
sido manipulada.
Hyperledger Sawtooth
Es una solución pensada para construir, implementar y ejecutar blockchains, es una plataforma
flexible que permite implementar actualizaciones en un estado compartido usando algoritmos
de consenso en diferentes partes que desconfían entre sí. Sawtooth permite separar el sistema
central de la lógica de la aplicación, de manera que resulta fácil implementar Smart Contracts
con reglas específicas sin necesidad de conocer a profundidad el diseño y arquitectura de
Sawtooth.
Arquitectura de Sawtooth
Imagen 1: Diagrama de despliegue de la arquitectura de Sawtooth (Hyperledger Sawtooth)
Sawtooth está compuesto por los siguientes componentes principales:
El cliente que se encarga de generar las transacciones, mostrar los datos y manejar los
diferentes eventos. Este puede ser una aplicación móvil, web o un servidor. Este se comunica
con el validador de forma directo o través de un API REST o incluso a raves de un servidor
personalizado por el usuario.
El procesador de transacciones contiene la lógica de la aplicación es decir los Smart Contracts
que pueden ser muy sencillos y definir una acción hasta ser muy complejos con muchos tipos
de datos, reglas y relaciones. Actualmente Sawtooth soporta una gran variedad de lenguajes
para la implementación de estos.
Por otra parte, está el validador Sawtooth que es el componente central, este valida los lotes
que llegan con transacciones, agrupa los lotes en bloques, y mantiene el consenso con toda la
red Sawtooth al comunicarse con otros nodos validadores. Cada nodo posee su propia instancia
de blockchain y se comunica con los otros nodos validadores por una red peer-to-peer usando
gossip protocol. Una red de Sawtooth es un grupo de nodos validadores que pueden ser
maquinas físicas, virtuales o contenedores diferentes.
Familia de transacciones
Una transaction family o familia de transacciones es el conjunto de transacciones y datos
posibles de una aplicación de Sawtooth. Para implementarla en necesario desarrollar un
modelo de datos para definir las operaciones válidas y las acciones que irán en cada
transacción, también es necesario implementar la lógica del procesador de transacciones para
definir los Smart Contracts y manejar los datos que llegan en cada transacción.
Transacción
Imagen 2: Diagrama de dominio de la transaccion (Hyperledger Sawtooth)
Una transacción es un solo cambio en el estado del blockchain. Es un objeto protobuf que
contiene un encabezado, una firma y una carga útil (payload). La carga contiene las acciones
que deben ser hechas en el estado durante la ejecución de la transacción. La carga útil o
payload es, hasta que sea decodificada, solo una secuencia de bytes. El usuario que firma la
transacción genera la firma digital cuando firma el encabezado con la llave privada. El campo
header es una versión codificada del TransactionHeader, esto ocurre para que se puedan
verificar los bytes exactos con la firma.
El TransactionHeader está compuesto por los siguientes campos:
- batcher_pubkey: es la misma llave publica que se usa para firmar el lote o batch, y
deben coincidir.
- family_name: es el nombre de la familia de transacciones.
- family_version: es la versión de la familia de transacciones.
- dependencias: se usa para especificar que transacciones deben ser aplicadas antes que
esta.
- inputs y outputs: son direcciones de estado para facilitar operaciones en paralelo.
- nonce: es una cadena aleatoria generada por el cliente con el fin de que si dos
transacciones tienen los mismos campos se generen diferentes firmas del encabezado.
- payload_encoding: es la carga útil que envuelve las acciones que se deben aplicar al
estado.
- payload_512: es un hash SHA-512 de los bytes del payload o la carga útil, al ser parte
del encabezado se firma también y sirve para comparar si el payload o carga útil
coincide con el encabezado.
- signer_pubkey: es la clave pública que se utilizó para firmas los bytes del encabezado y
que dio como resultado el header_signature.
Lote
O Batch es la unidad atómica del cambio de estado y envuelve una o más transacciones.
Contiene una lista de transacciones y un encabezado con la firma de que creo el lote. AL
momento de aplicar las transacciones de un lote al estado, se hacen en el mismo orden que se
encuentran en el lote y si alguna no es válida, no se aplica ninguna de las otras. Para que las
transacciones no se reutilicen en otro lote distinto, la transacción contiene la llave publica del
creador en el campo batcher_public_key.
Imagen 3: Diagrama de dominio del lote (Hyperledger Sawtooth) Al igual que con la transacción, en el lote o Batch el encabezado o header es una versión
serializada de BatchHeader y está firmada por la lleve privada del creador, esta firma resultante
se guarda como el header_signature.
Block
Es un conjunto de lotes, cada bloque tiene un encabezado con una marca de tiempo, un hash y
un firmante. Este encabezado también se usa para identificar el bloque anterior.
State
Sawtooth representa el estado con una instancia de un árbol Radix Merkle en cada validador. El
proceso de validación se asegura que los árboles de todos los nodos sean iguales siempre. Este
árbol es una estructura de datos que tiene sucesivos hashes de los nodos hojas a raíz frente a
cualquier cambio y para un bloque de transacciones de estado se genera un hash raíz único que
apunta a esa versión del árbol. Cuadro se coloca este hash de raíz en el encabezado de un
bloque se llega a un consenso sobre la versión del estado y la cadena de bloques. Pero si las
transacciones dan un hash diferente, el bloque no es válido.
Imagen 4: Diagrama del estado de Sawtooth (Hyperledger Sawtooth) Direccionamiento
Imagen 5: Diagrama que explica como funciona las direcciones en Sawtooth (Hyperledger Sawtooth)
El estado se divide en espacios de nombres que le dan flexibilidad a las familias para definir y
reutilizar datos del estado global entre procesadores de transacciones. Se usa un árbol Radix
direccionable donde las direcciones identifican las rutas a los nodos donde están guardados los
datos. Cada dirección es una cadena de 70 caracteres que representa 35 bytes. Cada byte es un
segmento de ruta de Radix que identifica el siguiente nodo en la ruta a la hoja. El formato de la
dirección usa un prefijo de espacio de 3 bytes que proporciona 224 posibles espacios de
diferentes nombres, los 32 bytes restantes se pueden usar según las indicaciones de la familia
para mapear otros identificadores, distinguir tipos de objetos, etc.
Imagen 6: Diagrama que explica como las direcciones del estado de Sawtooth cuando se añade una nueva
dirección (Hyperledger Sawtooth).
El procesador de transacciones realiza llamadas getState(dirección) en javaScript para obtener
la matriz de bytes que se encuentra en esa dirección y setState(dirección, datos) en javaScript
se utiliza para establecer una matriz de datos en esa dirección especifica. Esta matriz de bytes
solo tienen un significado cuando el procesador de transacciones la decodifica basándose en el
modelo de datos definido para la familia.
3. Diseño y Especificaciones
3.1 Definición del Problema
Los problemas que se buscan solucionar con el proyecto, son primero: Los cheques en la
actualidad son muy susceptibles a ser falsificados, ya que no es fácil asegurar que un cheque es
real sino hasta el momento de cobrarlo en un banco, además de que la trazabilidad de la
cadena de endosos no es fácil de comprobar. Otro problema de los cheques son su fragilidad ya
que, al ser un papel físico, son susceptibles a ser dañados, hurtados o perdidos y esos cheques
perdidos pueden ser usados para fraudes.
Después de realizar un análisis de los cheques se identificaron los siguientes cambios de
estados del cheque desde su creación hasta que es cobrado o queda en estado materializado.
Imagen 7: Diagrama que explica como los diferentes estados del cheque y el flujo entre ellos.
El primer estado ocurre cuando el cheque nace juridicamente con la firma, esto ocurre cuando
es librado por primera vez y entra al estado ACTIVO. Despues de esto el cheque puede pasar a
estado de ENDOSO si el beneficiario actual del cheque lo transfiere en favor de otro
beneficiario, esto puede ocurrir todas las veces que se pueda mientras el cheque no entre a
otro estado.
Los siguientes estados a los que puede pasar el cheque son: CADUCADO, PROTESTADO o
PRESENTADO PARA CANJE O COBRO. El cheque puede pasar al estado CADUCADO si han
pasado mas de 6 meses desde la fecha en que nacio juridicamente. Los estados de
PRESENTADO PARA COBRO O CANJE ocurren al momento en que el cheque se presenta para
ser cobrado en un banco. Si al momento de presentar el cheque se encuentra que el librador no
tiene fondos suficientes el cheque entonces pasa a estado de PROTESTADO con el fin de que no
caduque la accion cambiaria y el cheque pueda ser pagado posteriormente cuando el librador
tenga fondos. Si se toma un accion juridica debido al incumplimiento del compromiso de pago
el estado del cheque pasara entonces a MATERIALIZADO. Si por el contrario, el cheque es
presentado y pagado entonces su estado pasara a PAGADO y el ciclo de vida del cheque
terminara.
3.2 Especificaciones
En base de los estados del cheque se definieron los siguientes requerimientos funcionales:
Historia de
usuario
Quien Que Entradas Salidas
HU_1 Usuario Hacer uso de
uno de mis
cheques de mi
chequera virtual
y librar el
cheque en favor
de otro usuario
especifico.
Nombre del
beneficiario,
llave publica del
beneficiario,
valor del
cheque, tipo de
cheque, fecha
de creación y
llave publica y
privada del
librador.
Un cheque
librado en favor
del beneficiario
firmado por el
librador.
HU_2 Usuario Endosar un
cheque del que
Id del cheque,
llave pública y
Se crea un
endoso con la
soy el
beneficiario
actual en favor
de un usuario
especifico.
privada del
usuario y llave
publica del
beneficiario.
fecha específica
en el cheque y
se actualiza el
beneficiario
actual del
cheque y el
estado del
cheque.
HU_3 Usuario Realizar un
cambio de
estado de un
cheque del que
soy el
beneficiario
actual.
Id del cheque,
llave pública y
privada del
usuario, nuevo
valor del estado
Se realiza un
cambio en el
estado con la
fecha actual, y
se añade el
cambio a la lista
de los cambios
de estado.
HU_4 Usuario Ver la lista de
cheques de mi
chequera que he
usado y del que
soy librador.
Lista de los
cheques de los
que el usuario es
el librador.
HU_5 Usuario Ver la lista de
cheques del que
soy o he sido
beneficiario
Lista de los
cheques de los
que el usuario
actual es o ha
sido
beneficiario.
HU_6 Usuario Ver el detalle de
un cheque del
que he sido
beneficiario o
librador.
Id del cheque Todos los
atributos del
cheque
incluyendo los
cambios de
estado y la
cadena de
endosos Tabla 1: Historias de usuario de los requerimientos funcionales
Requerimientos no funcionales
ID Nombre Explicación
Req_NF_1 No repudio Es importante que toda
transacción realizada sea
rastreable y que no haya
duda de la identidad del que
la origino.
Req_NF_2 Conformidad a las leyes Al ser el cheque un
documento legal y con un
marco legal, es importante
que la solución se
completamente conforme a
estos y que en todo
momento sea válido en
cualquier ámbito legal y
judicial.
Req_NF_3 Usabilidad La solución debe darles a los
usuarios una buena
experiencia, ser fácil, sencilla
e intuitiva de usar.
Req_NF_1 Privacidad La solución debe estar
conforme a la ley con
respecto a la protección de
los datos. Tabla 1: Historias de usuario de los requerimientos funcionales
3.3 Restricciones
Se identificaron las siguientes restricciones que debe cumplir el proyecto debido a aspectos
legales.
1. Los cheques deben contener todos los campos que establece el Artículo 712-751 del
Código de Comercio con respecto al cheque.
2. Garantizar que la información del cheque tales como el estado, librador, cadena de
endosos no ha sido alterada desde que nació jurídicamente.
3. Que la firma electrónica sea válida.
4. Que haya una completa transparencia en la información que permita la ley para todas
las partes involucradas.
5. Que sea posible trazar cada uno de los endosos junto a sus respectivos cambios de
estado del cheque desde su nacimiento hasta que fue pagado o materializado según sea
el caso.
4. Desarrollo del Diseño
4.1 Recolección de información
El proceso de recolección de información se comenzó con la definió de la problemática por
parte de los expertos en el campo, en este caso la profesora Lorena Florez y el asesor Darío
Correal, luego se comenzó a desarrollar la arquitectura y el prototipo en paralelo, y se hicieron
reuniones semanales con la profesora Lorena con el fin de obtener retroalimentación y mejorar
la solución inicial durante todo el semestre en términos técnicos y legales.
4.2 Diseño de la solución
El flujo de trabajo de la solución es el siguiente:
1. Primero el usuario realiza una acción desde la aplicación del cliente, como crear un
cheque o hacer un endoso. Para esto el cliente codifica la acción como una carga útil,
después esta carga se envuelve en una transacción firmada con su llave publica y luego
las transacciones se envuelven en lotes firmados también, finalmente se envía este lote
o batch al validador usando el servidor como intermediario haciendo una petición REST
con los bytes de la transacción.
2. El servidor transmite el lote al validador.
3. El validador revisa el lote y las transacciones que contiene para verificar su validez.
4. El procesador de transacciones recibe las transacciones y verifica la identidad del que la
firma, después desenvuelve la transacción y decodifica la carga útil para así obtener la
acción, por ultimo verifica que la acción sea válida.
5. El procesador modifica el estado de manera que esté de acuerdo a la acción ingresada.
Para tener un registro de lo que ocurre en el estado del blockchain se implementa un ledger-
sync o un listener de eventos y una base de datos en otro nodo diferente al del validador y
procesador de transacciones. Este listener se suscribe a los eventos que genera Sawtooth
cuando hay un cambio en la cadena de bloques. Estos eventos se generan solo cuando un
bloque es confirmado. Los eventos a los que se suscribe el listener son:
- sawtooth/commit-block: Este evento contiene información sobre el bloque ademas del ID del
bloque, el número, el hash raíz del estado y el ID del bloque anterior
- sawtooth/state-delta: Este evento tiene todos los cambios de estado que ocurrieron para un
bloque en una dirección específica.
El listener usa los datos generados en estos eventos para mantener una copia del estado de
Sawtooth en una base de datos RethinkDB, lo que facilita la consulta de las transacciones
realizadas. Con este modelo obtener datos se hace fácilmente con llamados REST al servidor,
pero para el envio de cambios y de transacciones es necesario tener en cuenta que estas deben
ir firmadas. Se tienen dos modelos de firma:
1. Client signin model: En este modelo el cliente crea las transacciones y lotes, los firma
con su llave privada, después procede a serializarlos y los envía al servidor a través de
una ruta POST. El servidor no procesa los datos, sino que los envía al validador. Este
modelo tiene como ventajas que la identidad del usuario es completamente verificable
ya que las transacciones son firmadas desde un inicio por el cliente y también que si el
servidor se ve comprometido no es posible falsificar las transacciones ya que el servidor
solo es un intermediario. Las desventajas de este modelo es que no es posible
implementar rutas REST especificas en el servidor y la implementación del cliente se
hace más compleja ya que debe realizar la firma, creación y serialización de las
transacciones.
2. Server signin model: En este modelo el cliente envía los datos de la transacción al
servidor a través de objetos JSON y rutas POST tradicionales. Luego el servidor procede
a crear, firmar y serializar la transacción en base del JSON recibido y lo envía al
validador. Este modelo tiene como ventajas es posible implementar rutas REST
especificas en el servidor para las distintas acciones y el cliente no debe manejar
ninguna firma y método para crear transacciones. Como desventajas este modelo no
garantiza completamente la verificación de identidad del blockchain ya que si el servidor
tiene una falla de seguridad todas sus transacciones se verían vulneradas además de
que debe poder manejar las llaves privadas de todos los usuarios del blockchain.
Después de analizar las opciones anteriores se decidió por el primero ya que la verificación de
identidad es un requerimiento importante del proyecto. Teniendo en cuenta los aspectos
anteriores se diseñó la siguiente arquitectura.
Imagen 8: Diagrama de despliegue de la arquitectura de solución.
4.3 Diagrama de Dominio
Para el modelo de datos se investigó el modelo usado en la familia de Sawtooth de Supply
Chain [supply-chain] y se adaptó al proyecto el siguiente modelo de datos
Imagen 8: Diagrama de entidades del proyecto
5. Implementación
5.1 Implementación del Smart Contract
Para la implementación del Smart Contract de los cheques primero se adaptó la familia de
Supply Chain (hyperledger-archives/sawtooth-supply-chain) al caso específico y se usaron las
siguientes entidades para ser guardadas en el estado usando protobufs.
Agent:
Es la entidad que identifica a un usuario de la aplicación de cheques, el usuario está identificado
con un nombre, una llave publica y una fecha donde fue creado el usuario.
Imagen 9: Codigo con la definicion de la entidad Agent (sawtooth-supply-chain).
Cuando una misma dirección es computada por diferentes espacios de nombres ocurre una
colisión, por lo tanto, todas las direcciones repetidas se almacenan en un contenedor.
Imagen 10: Codigo con la definicion de la entidad AgentContainer (sawtooth-supply-chain).
Record
Esta entidad se usó para identificar al cheque, en este caso el cheque tiene un identificador
único, una lista con los owners que en este caso al momento de crear el contrato se adaptó
para albergar solo al librador del cheque, una lista de custodians que representa a todos los
beneficiaros del cheque, un booleano que se refiere a si el cheque puede ser editado o no, y
por último la referencia a otra entidad record_type que tiene las distintas propiedades que
puede tener el cheque.
Imagen 11: Codigo con la definicion de la entidad Record (sawtooth-supply-chain).
RecordType
Esta entidad se refiere a las distintas propiedades que puede tener un cheque y tiene un
nombre que sirve como un identificador único.
Imagen 12: Codigo con la definicion de la entidad RecordType (hyperledger-archives/sawtooth-supply-chain).
Para el caso del proyecto se creó un RecordType con las propiedades de estado, tipo y valor.
Imagen 13: Ejemplo de la instancia de RecordType usada para el proyecto
Las acciones que se usaron de la familia para ser guardadas en la carga útil al momento de crear
una transacción fueron las siguientes:
CreateRecordAction
Esta acción crea un cheque de un tipo específico y con las propiedades ingresadas.
Imagen 14: Codigo con la definicion. De los datos usados para la accion de crear un record o cheque (hyperledger-
archives/sawtooth-supply-chain).
A continuación, se puede ver un ejemplo de los datos que son ingresados en la acción:
Imagen 15: Ejemplo de la instancia de createRecordAction usada en el proyecto.
Esta acción se procesa en el Smart Contract usando el siguiente código de JavaScript:
Imagen 16: Codigo con el metodo del Smart Contract que procesa la accion CreateRecordAction
Primero se valida que los datos sean correctos, no exista un cheque con el mismo nombre y
exista el usuario que está firmando la transacción.
Imagen 17: Parte del codigo donde se validan los datos del metodo del Smart Contract que procesa la accion
CreateRecordAction.
Imagen 18: Parte del codigo donde se validan los datos en el metodo del Smart Contract que procesa la accion
CreateRecordAction.
A continuación, se guardan crea el cheque nuevo usando los datos de la acción y se asocia al
usuario que firmo la acción como el owner que en el contexto del proyecto es el librador del
cheque:
Imagen 19: Parte del codigo donde se crean una instancia del objeto Record en el metodo del Smart Contract que
procesa la accion CreateRecordAction.
Finalmente se guarda el nuevo cheque en el estado del blockchain.
Imagen 20: Parte del codigo donde se crea la matriz de datos para la nueva instancia de record en el metodo del
Smart Contract que procesa la accion CreateRecordAction.
Después las propiedades asociadas al cheque se crean y se guardan en el blockchain:
Imagen 21: Parte del codigo donde se crea la matriz de datos para las propiedades del record en el metodo del
Smart Contract que procesa la accion CreateRecordAction.
CreateAgentAction
Esta acción se usa para agregar un usuario nuevo al blockchain, el único atributo que se ingresa
con la acción es el nombre del usuario,
Imagen 22: Codigo con la definicion de los datos usados para la accion de crear un usuario (hyperledger-
archives/sawtooth-supply-chain).
Esta acción se procesa con el siguiente código, donde primero se validan los datos y se genera
una nueva dirección para el usuario:
Imagen 23: Parte del codigo donde se crea la nueva direccion del nuevo usuario que se añadira en el estado en el
metodo del Smart Contract que procesa la accion CreateAgentAction
Se valida que no exista un usuario con la misma llave publica que firmo la acción:
Imagen 23: Parte del codigo donde se valida que no exista el usuario en el metodo del Smart Contract que procesa
la accion CreateAgentAction
Por último se crea el nuevo usuario y se actualiza el estado:
Imagen 24: Parte del codigo donde se anade al estado la amtriz de datos que contiene el nuevo usuario en el
metodo del Smart Contract que procesa la accion CreateAgentAction
CreateProposalAction
Esta acción se usa para añadir un beneficiario al cheque ya sea por endoso o porque el cheque
fue librado por el dueño de la chequera.
Imagen 25: Codigo con la definicion de los datos usados para la accion de crear un endoso (hyperledger-
archives/sawtooth-supply-chain).
El código que procesa esta acción en el Smart Contract es el siguiente:
Primeramente, se verifica que exista la llave publica del usuario que va a recibir el cheque y el
que lo va a librar.
Imagen 26: Parte del codigo donde se verifica la identidad del librador y beneficiario en el metodo del Smart
Contract que procesa la accion CreateProposalAction
Después se verifica que el cheque pueda ser endosado, y se añade la llave publica del
beneficiario, además de la fecha en que se realizó la transacción, a la lista de custodians, que en
el contexto del proyecto se refiere a la lista de usuarios que han sido beneficiarios del cheque.
Imagen 27: Parte del codigo donde se añade el nuevo beneficiario a la lista de endosos en el metodo del Smart
Contract que procesa la accion CreateProposalAction
Por último, se actualiza el estado con el cambio:
Imagen 28: Parte del codigo donde se añade la nueva matriz de datos al blockchain con el nuevo endoso en el
metodo del Smart Contract que procesa la accion CreateProposalAction
UpdatePropertiesAction
Esta acción se usa para actualizar las propiedades de un cheque:
Imagen 29: Codigo con la definicion de los datos usados para la accion de actualizar una propiedad (hyperledger-
archives/sawtooth-supply-chain).
El código del Smart Contract relacionado con esta acción es el siguiente:
Imagen 30: Parte del codigo donde se define el metodo del Smart Contract que procesa la accion
UpdatePropertiesAction
Primero se verifica que la propiedad pueda ser actualizada:
Imagen 31: Parte del codigo donde se verifica si la propiedad puede ser actualizada en el metodo del Smart
Contract que procesa la accion UpdatePropertiesAction
Después se añade el cambio como una nueva página en las propiedades del cheque para así
llevar una lista de los diferentes cambios en las propiedades en el tiempo.
Imagen 32: Parte del codigo donde se añade el cambio de la propiedad a un record o cheque en el metodo del
Smart Contract que procesa la accion UpdatePropertiesAction
Se crea el cambio dependiendo del tipo de dato de la propiedad.
Imagen 33: Parte del codigo donde se muestra otro metodo para crear el cambio en la propiedad que se llama en
el metodo del Smart Contract que procesa la accion UpdatePropertiesAction
Finalmente se actualiza el estado con la actualización del campo:
Imagen 34: Parte del codigo donde añade la matriz de datos al estado del blockchain con la nueva actualizacion de
los datos en el metodo del Smart Contract que procesa la accion UpdatePropertiesAction
Estos Smart Contracts fueron desarrollados usando JavaScript y la librería de Sawtooth SDK
para este lenguaje.
5.2 Implementación del Cliente-Servidor
Se implementó una aplicación web con el propósito de mostrar una interfaz al usuario con una
buena usabilidad y experiencia de usuario. La aplicación de usuarios se desarrolló usando
Angular. También se implementó un servidor en NodeJS que funciona como API principalmente
para leer el estado del blockchain de una base de datos RethinkDB, por otro lado, también se
implementó un ledger-sync en NodeJS que se suscribe a los eventos del validador y sincroniza
los datos del estado con la base de datos.
Registro e inicio de sesión
Se implementó un inicio de sesión sencillo donde solo se pide la cedula y la clave
Imagen 35: Imagen que muestra el inicio de sesión de la aplicación del cliente
Tambien se implemento el registro que es muy similar al inicio de sesion con la diferencia que se le pide
el nombre al usuario:
Imagen 36: Imagen que muestra el registro de la aplicación del cliente
Visualización de los cheques usados y recibidos
A continuación, el usuario podrá ver la lista de cheques que ha usado de su chequera virtual:
Imagen 37: Imagen que muestra los cheques usados por el usuario en la aplicación del cliente
También podrá visualizar la lista de cheques del que ha sido beneficiario en algún momento en
el tiempo.
Imagen 38: Imagen que muestra los cheques recibidos por el usuario en la aplicación del cliente
En el detalle de cada cheque es posible ver la lista de endosos y los cambios de estado en el
tiempo.
Imagen 39: Imagen que muestra la cadena de endosos y el historial de estados de un cheque en la aplicación del
cliente
También es posible ver información importante como el nombre del primer librador, el valor,
tipo, estado y el token de la transacción en que fue creado en el blockchain.
Imagen 40: Imagen que muestra el detalle los cheques usados por el usuario en la aplicación del cliente
También si es necesario, es posible exportar un PDF con toda la información del cheque.
Imagen 41: Imagen que muestra como se exporta un cheque en pdf en la aplicación del cliente
Creación de un cheque, endoso y cambio de estado
Al momento de crear un cheque se muestra un formulario sencillo con los datos del
beneficiario, el valor y el tipo de cheque del que se quiere hacer uso, además del id del cheque
que se va usar. Se hizo una interfaz sencilla y atractiva para mejorar la experiencia de usuario.
Imagen 42: Imagen que muestra como se crea un cheque en la aplicación del cliente
Por otro lado, es posible realizar un endoso o un cambio de estado de un cheque del que el
usuario es beneficiario, si esa condición no se cumple estas opciones no se habilitan.
El endoso solo se permite si el estado del cheque es ACTIVO o ENDOSO y el tipo de cheque
permite realizar endosos. En este caso se utilizó una interfaz muy sencilla donde solo se pide el
nombre del beneficiario del endoso.
Imagen 43: Imagen que muestra como se endosa un cheque en la aplicación del cliente
Para realizar un cambio de estado se muestra un formulario con las opciones posibles del estado al que
puede pasar el cheque.
Imagen 44: Imagen que muestra como se cambia el estado de un cheque en la aplicación del cliente
6. Conclusiones
6.1 Resumen del trabajo
Desde un inicio se hizo un plan de trabajo, en general se cumplieron los tiempos estipulados,
aunque durante el desarrollo del proyecto se tuvo que iterar en diversas ocasiones en el
rediseño de componentes y arquitectura esto con el fin de aplicar la retroalimentación recibida
e implementar mejoras. Esta retroalimentación constante ayudo a que el desarrollo del
proyecto fuera exitoso y que el prototipo final fuera conforme al marco legal que se definió en
un inicio.
Desde el principio se tuvo una idea clara del proposito del proyecto y se realizo un prototipo
que fue validado con los expertos, posterior a eso se comenzo el desarrollo de la aplicación web
al mismo tiempo que los componentes del servidor. Afortunadamente la documentacion de
Sawtooth es muy amplia, lo cual facilito cumplir el objetivo de diseñar e implementar una
arquitectura de solucion. Un contratiempo importante fue durante el despliegue de la
arquitectura ya que se necesito simplificar la definicion de los contenedores de los
componentes, e incluso rehacer algunos. El siguiente objetivo de implementar un prototipo
funcional se logro desarrollar al maximo ya que el prototipo se implemento con todas las
funcionalidades previstas desde un inicio. Finalmente el proyecto, gracias a la estrecha
colaboracion con la profesora Lorena Florez, pudo ser adaptado para cumplir con todo el marco
legal relacionado a a los cheques. Se concluye que el proyecto logro cumplir con los objetivos
decididos desde un inicio y aunque todavia se podrian implementar mejoras y mas
funcionalidades, el prototipo actual es una buena base para seguir avanzando en este tema.
6.2 Trabajo Futuro
Actualmente el prototipo implementado cubre las caracteristicas mas importantes del cheque
se podría ampliar introduciendo las siguientes funcionalidades:
- Permitir que haya varios bancos y haciendo uso de todas las funcionalidades de Sawtooth,
gestionar los permisos de la red de acuerdo a esto.
- Manejar pagos parciales del cheque al momento de ser presentado al banco.
- Haciendo uso de los eventos de Sawtooth se podrian manejar notificaciones a las partes
interesadas cuando haya un cambio en el estado del cheque.
- Diseñar una nueva familia especifica para el caso en lugar de adaptar la de sawtooth supply-
chain.
Por otro lado es posible ampliar el alcance del proyecto para incluir otros tipos de titulos
valores mas complejos.
7. Bibliografía
Hyperledger Sawtooth | Hyperledger Sawtooth. (s. f.). Hyperledger. Recuperado 20 de septiembre de
2020, de https://sawtooth.hyperledger.org/
hyperledger-archives/sawtooth-supply-chain. GitHub. Recuperado 20 de septiembre de 2020, de
https://github.com/hyperledger-archives/sawtooth-supply-chain
Código de Comercio de Colombia [Código]. (2019). Obtenido de
http://www.secretariasenado.gov.co/senado/basedoc/codigo_comercio.html
Congreso de Colombia. (21 de Agosto de 1999). Ley 527 de 1999. Obtenido de
http://www.secretariasenado.gov.co/senado/basedoc/ley_0527_1999.html
Chaparro, J. F. (20 de 10 de 2019). ¿Por qué es legal endosar pagarés electrónicos utilizando Blockchain?
Obtenido de Colombia Fintech: https://www.colombiafintech.co/novedades/por-que-es-legalendosar-
pagares-electronicos-utilizando-blockchain
Apéndice
El Proyecto completo se encuentra en este repositorio de GitHub:
https://github.com/mpbayonal/chequesBlockchain