Desmaterialización de títulos valores

mediante Blockchain

Julián Andrés Bermúdez Valderrama – ja.bermudez10@uniandes.edu.co - 201519648

Manuel Francisco Vallejo Soacha – mf.vallejo@uniandes.edu.co - 201618093

Director:
Ing. Sistemas y Computación M. Sc. Ph. D., Darío Ernesto Correal

Línea investigativa:
Arquitectura Blockchain

Proyecto:
Títulos Valores

Universidad de los Andes

Departamento de Ingeniería de Sistemas y Computación
Ingeniería de Sistemas y Computación

Bogotá D.C., Colombia

Año 2021 – Semestre I
Tabla de contenido
0. Resumen ............................................................................................................................. 5
1. Introducción........................................................................................................................ 5
1.1 Motivación ............................................................................................................... 5
1.2 Como se vería una solución ..................................................................................... 5
1.3 Diseño e implementación ........................................................................................ 6
1.4 Resultados Obtenidos .............................................................................................. 6
1.5 Estructura del documento ............................................................................................ 6
1.6 Agradecimientos ........................................................................................................... 7
2. Descripción ......................................................................................................................... 7
2.1 Objetivos ....................................................................................................................... 7
General ........................................................................................................................... 7
Específicos ...................................................................................................................... 8
2.2 Marco Legal .................................................................................................................. 8
2.2.1 Titulo Valor ............................................................................................................ 8
2.2.2 Cheque ................................................................................................................... 8
2.2.3 Pagare .................................................................................................................... 9
2.2.4 Endoso ................................................................................................................... 9
2.2.5 Validación de los títulos valores virtuales ............................................................. 9
2.3 Marco Teórico............................................................................................................... 9
2.3.1 Blockchain .............................................................................................................. 9
2.3.2 Hyperledger Sawtooth......................................................................................... 10
2.3.3 MetaMask ............................................................................................................ 10
2.3.4 Ledger Sync .......................................................................................................... 10
2.4 Antecedentes .............................................................................................................. 10
2.4.1 Pagarés ................................................................................................................ 10
2.4.2 Cheques ............................................................................................................... 11
2.5 Identificación del problema........................................................................................ 13
3. Diseño y Especificaciones ................................................................................................. 13
3.1 Definición del problema ............................................................................................. 13
3.2 Especificaciones .......................................................................................................... 14
3.2.1 Requerimientos funcionales ................................................................................ 14
 3.2.2 Requerimientos de calidad .................................................................................. 15
3.3 Condiciones y/o Restricciones .................................................................................... 15
4. Desarrollo del Diseño ....................................................................................................... 16
4.1 Recolección de información ....................................................................................... 16
4.1.1 Interdisciplinaridad junto con la Facultad de Derecho ....................................... 17
4.2 Procesos de negocio ................................................................................................... 17
4.3 Proceso creativo de un título valor ............................................................................ 19
4.4 Diagrama de contexto ................................................................................................ 22
4.5 Diagrama de despliegue ............................................................................................. 22
5. Implementación................................................................................................................ 25
5.1 Descripción de la implementación ............................................................................. 25
5.1.1 Clientes Web ........................................................................................................ 25
5.1.2 API de Dominio .................................................................................................... 33
5.1.3 API/Fachada sobre Blockchain (Ledger Distributed API) .................................... 35
6. Validación ......................................................................................................................... 48
6.1 Pruebas de carga ........................................................................................................ 48
6.1.1 Resultados individuales (por iteración) ............................................................... 49
6.1.2 Resultados acumulados ....................................................................................... 55
7. Conclusiones ..................................................................................................................... 55
7.1 Resumen del trabajo................................................................................................... 56
7.2 Desempeño, tiempos de ejecución y limitaciones ..................................................... 56
7.3 Aportes, retos y trabajo futuro................................................................................... 57
8. Referencias ....................................................................................................................... 57
Apéndice ............................................................................................................................... 58
0. Resumen

Con este proyecto, se propone realizar una herramienta para crear y administrar títulos
valores desmaterializados de cualquier tipo sobre el Blockchain (inicialmente Hyperledger
Sawtooth). Esto con el fin de solucionar problemas que tienen los títulos valores físicos
actualmente. Para esto, se realizó una arquitectura de referencia. Esta solución debe tener
características para que los títulos valores sean legalmente vinculantes. Además, se creó
un MVP que muestra y valida la solución en los requisitos legales.

1. Introducción

1.1 Motivación

En Colombia, según la legislación colombiana, los títulos valores son definidos como,
“documentos necesarios para legitimar el ejercicio del derecho literal y autónomo que en
ellos se incorpora. Pueden ser de contenido crediticio, corporativos o de participación y de
tradición o representativos de mercancías”. De este modo, los documentos asociados a los
títulos valores, son esenciales al momento de hacer ejercicio del derecho textual expresado
en ellos.
Aun así, al ser documentos físicos, los títulos valores presentan algunas limitaciones ligadas
al deterioro y la garantía de seguridad; y, por ende, la posible invalidez de estos.

1.2 Como se vería una solución

Con el fin de resolver los problemas mencionados, la solución debe tener la capacidad de:

• Crear un título valor desmaterializado que sea legalmente vinculante.

• Endosar un título valor creado.
• Ver los títulos valores correspondientes a una persona, pueden ser beneficiarios o
librados por el mismo.
• Poder ver el historial de estados de un título valor.
Los títulos valores tienen los siguientes requerimientos legales:

• Fecha de creación
• Lugar de creación
• Nombre del deudor
 • Nombre del acreedor
• Firma del deudor

1.3 Diseño e implementación

Para resolver los anteriores requerimientos se propuso utilizar Blockchain. Esta se escoge
por su facilidad a la ahora de autenticar transacciones, además de que se asegura la
integridad de los datos almacenados. Se decidió utilizar Hyperledger Sawtooth ya que es
un software que ofrece una arquitectura modular y flexible que separa el dominio de la
aplicación con los Smart Contracts.

1.4 Resultados Obtenidos

Al finalizar el proyecto se pudo diseñar y desarrollar una solución para los diferentes títulos
valores desmaterializados haciendo uso de Blockchain. Además, se implementaron los
Smart Contracts necesarios para la verificación y consenso de lógica de administración de
información de estos y eliminar algunas de sus vulnerabilidades presentadas en títulos
valores físicos.

1.5 Estructura del documento

El documento presenta la siguiente estructura:

• Introducción: Contiene un breve repaso del proyecto para dar contexto de este.
• Descripción: Se compone de definición de objetivos de proyecto, marco legal y
teórico, antecedentes bajo la línea investigativa, e identificación del problema.
• Diseño y Especificaciones: Describe los pasos preliminares al desarrollo del diseño,
teniendo en cuenta la definición del problema, las especificaciones formales y las
restricciones y/o condiciones consideradas.
• Desarrollo del diseño: Concibe lo relacionado al proceso de propuesta y seguimiento
del diseño del proyecto.
• Implementación: Se relaciona a las especificaciones de implementación bajo los
diversos frentes de ejecución evidenciados.
 • Validación: Pruebas de validación sobre la implementación realizada.
• Conclusiones: Mención de retos, limitaciones y trabajo futuro.
• Referencias: Material bibliográfico e investigativo consultado.

1.6 Agradecimientos

Agradecemos profundamente a:

Darío Correal, quien cómo profesor, asesor y director de la línea investigativa sobre
Arquitecturas Blockchain, con su profesionalismo y paciencia nos orientó en el proceso de
desarrollo del proyecto en tiempos de bastante incertidumbre.

Lorena Flórez y Andrea Guzmán, quienes en función de co-asesoras, dispusieron todo su

tiempo y experticia referente a Derecho y Economía para establecer una base de
conocimiento sólida y confiable.

Luis Esteban Flórez, quien cómo estudiante doctoral a cargo del proyecto de títulos valores,
nos asistió de manera oportuna en todos los requerimientos teóricos, y prácticos a lo largo
del proyecto.

Andrés Rodríguez, quien cómo asistente graduado, asumió gran parte del reto de
implementación del proyecto; aportando muchísimo valor en la colección, consolidación,
interpretación y traducción del conocimiento legislativo, finalmente plasmado en su trabajo.

A nuestras familias y allegados, por apoyarnos en todos los aspectos en todo nuestro
proceso de formación profesional.

A todos ustedes, muchas gracias…

2. Descripción

2.1 Objetivos

General
Desarrollar una arquitectura soportada sobre Blockchain que modele el comportamiento y
ofrezca servicios de administración de títulos valores; integrando los proyectos realizados
previamente en el marco conceptual y legal en favor de la desmaterialización física como
un aporte al precedente de la incursión virtual de estos al mercado bancario.
Específicos

• Modelar el problema relacionado al marco legal y teórico de los títulos valores sobre
las condiciones, restricciones, y aplicaciones de estos en un contexto real.
• Diseñar e implementar una arquitectura integradora y genérica que soporte el flujo
de estados, y las funcionalidades de algunos de los títulos valores de manera virtual.
• Generar la documentación requerida que evidencie las decisiones relevantes
tomadas sobre la prueba de concepto, el diseño, la implementación, las
correcciones y las pruebas de la arquitectura propuesta.
• Generar la documentación requerida que sirva como punto de partida para el
trabajo futuro sobre el proyecto.

2.2 Marco Legal

2.2.1 Titulo Valor

Según el artículo 619 del Código del Comercio los títulos valores son documentos que
legitiman el ejercicio de derecho que en ellos se incorpora. Además, en el artículo 620 del
Código del Comercio un título valor solamente es válido si se cumplen todos los requisitos.
Los requisitos de un título valor se definen en el artículo 621 del Código del Comercio:

• La Firma de quien lo crea.

• La mención del derecho que en el titulo se incorpora
Esta firma puede sustituirse, por un signo o contraseña impuesto bajo la responsabilidad de
quien crea el título valor.

2.2.2 Cheque

Un cheque es un título valor que se encuentra estipulado en el artículo 712 del Código de
Comercio, en donde se define como un documento autorizado por un banco que le permite
a la persona que lo recibe cobrar una determinada suma de dinero. El cheque cuenta con
los siguientes requisitos:

• La orden incondicional de pagar una determinada suma de dinero.

• El nombre del banco librado
• La indicación de ser pagadero a la orden del portador.
2.2.3 Pagare

Un pagare es un título valor que se encuentra estipulado en el artículo 709 del Código de
Comercio, en el cual se denomina una persona como otorgante, que es alguien que promete
pagar una suma determinada de dinero a otra persona denominada beneficiario. El pagare
cuenta con los siguientes requisitos:

• La promesa incondicional de pagar una suma determinante de dinero.

• El nombre de la persona a quien deba hacerse el pago.
• La indicación de ser pagadero a la orden o al portador.
• La forma de vencimiento.

2.2.4 Endoso

El endoso es una figura Jurica en la cual se permite la transferencia de los derechos de

crédito de un título valor a un beneficiario que se denomina endosatario, quien se legitima
en virtud de dicho acto de ejercer tales derechos.

• Endosante: Quien transfiere el pagare de su propiedad a la del endosatario.

• Endosatario: Quien recibe la propiedad del pagare y por lo tanto se convierte en el
legítimo tenedor.

2.2.5 Validación de los títulos valores virtuales

La ley 527 de 1999 establece como un documento digital puede ser equivalente a un
documento físico, siempre y cuando se cumplan los requisitos de integridad, autenticidad,
no repudio y accesibilidad de la información. Uno de los requerimientos es el uso de una
firma digital o electrónica.

2.3 Marco Teórico

2.3.1 Blockchain

Blockchain, es una tecnología que combina estrategias de seguridad, administración de

información, y de mecanismos que soportan el almacenamiento, el chequeo, y la ejecución
de transacciones entre entidades o partes. Por lo general, estas tecnologías están basados
en sistemas de consenso que garantizan la validez y la veracidad de las transacciones y las
posibles interacciones entre estas.

A nivel funcional, la mayoría de las plataformas Blockchain ofrecen la persistencia de

transacciones agrupadas, conocidas cómo bloques; y la conexión con otros grupos de
transacciones relacionadas, conocidas cómo cadenas.

2.3.2 Hyperledger Sawtooth

Ofrece una arquitectura modular y flexible que separa el sistema central del dominio de la
aplicación, por lo que los Smart Contracts pueden especificar las reglas comerciales para las
aplicaciones sin necesidad de conocer el diseño subyacente del sistema central.

2.3.3 MetaMask

Es una extensión para varios de los exploradores que le permite al usuario crear, importar
y manejar billeteras de Ethereum directamente en su explorador. Esta se utiliza con el fin
de que los usuarios tengan una manera fácil de utilizar aplicaciones distribuidas por
blockchain y todo esto integrado en el navegador.

2.3.4 Ledger Sync

El componente Ledger Sync, ideado y adaptado por Luis Flórez, cumple la función de
sincronizar la información persistida satisfactoriamente a una base de datos; creando una
capa de administración de la información en Blockchain con el objetivo de simplificar la
consulta de información, y adicionalmente tener traza de la ocurrencia de las transacciones
con los entes involucrados en el ciclo de vida de la información.

2.4 Antecedentes

2.4.1 Pagarés

Para el semestre 2020-I, el proyecto de grado realizado por Luis Ernesto Viana
(le.viana@uniandes.edu.co) y Juan David Zambrano (jd.zambrano@uniandes.edu.co)
titulado “Pagarés virtuales utilizando Ethereum”, tuvo un enfoque sobre la
desmaterialización de títulos valores específicamente para pagarés. A nivel tecnológico, el
proyecto fue soportado principalmente mediante Ethereum, Infura y Metamask;
tecnologías que fueron condiciones importantes en el diseño de la solución. Dicho proyecto
fue el fundamento y la primera iteración enmarcada en la rama de investigación de
desmaterialización de títulos valores. Finalmente, este proyecto dejó varios aportes y retos
consigo, ya que al ser el primer proyecto se logró consolidar el alcance que toda la rama de
investigación podría explorar mediante diversos marcos de trabajo y tecnologías asociadas
a Blockchain.

Los aportes puntuales para destacar del proyecto fueron:

• La adquisición y el establecimiento de un dominio de conocimiento relacionado a

los marcos conceptuales y legislativos de los pagarés.
• Ideación y diseños iniciales sobre una arquitectura de referencia, con el fin de
satisfacer los requerimientos funcionales y no funcionales identificados.
• Experimentación inicial sobre arquitecturas y Ethereum cómo plataforma
Blockchain.
• Consolidación de conocimiento técnico sobre arquitecturas y plataformas
Blockchain.
• Retroalimentación y lecciones aprendidas sobre el proceso de aprendizaje, diseño,
e implementación de la arquitectura de referencia.

Los retos o trabajo futuro identificados en el proyecto fueron:

• Expandir funcionalidades enunciadas en la propuesta de solución tales como,

posibilidad de garantizar pagos parciales, reforzar y optimizar condiciones de
seguridad en la verificación de la firma, crear interfaces y servicios asociadas a
usuarios terceros.
• Reducción de costos por transacción mediante optimizaciones sobre los Smart
Contracts.
• Revisar los procesos asociados a la validez de un pagaré virtual soportado mediante
Blockchain de manera legal.

2.4.2 Cheques

Para el semestre 2020-II, el proyecto desarrollado por Mónica Bayona

(mp.bayona@uniandes.edu.co) bajo el título “Desmaterialización de títulos valores con
Blockchain aplicado a Cheques”, fue la segunda iteración de la rama investigativa
relacionada. Este proyecto se concentró en tomar cómo título valor de referencia al cheque,
título valor el cual presenta similitudes y particularidades respecto al pagaré. Este proyecto
se soportó mediante la plataforma Blockchain Hyperledger Sawtooth, plataforma
principalmente centrada en el desarrollo, que ofrece soporte mediante extensiones
opcionales de infraestructura tecnológica. El proyecto de desmaterialización de cheques,
tal como el proyecto de pagarés, contó con la valiosa ayuda del grupo de abogados (liderado
por la profesora Lorena Flórez) interesados en el proyecto de investigación quienes
ayudaron a trasmitir y consolidar la base de conocimiento para la definición del
funcionamiento legal del cheque cómo título valor.

Los aportes relevantes en esta iteración fueron:

• La adquisición y el establecimiento de un dominio de conocimiento relacionado a

los marcos conceptuales y legislativos de los pagarés.
• Refinamiento de la arquitectura de referencia en relación con la iteración pasada.
• Experimentación con la plataforma Blockchain Hyperledger Sawtooth (decisión
relevante puesto que el proyecto actual se desarrolló en esta plataforma también).
• Retroalimentación y lecciones aprendidas sobre el proceso de aprendizaje, diseño,
e implementación de la arquitectura de referencia.

Los retos o trabajo futuro identificados en el proyecto fueron:

• Permitir que haya varios bancos y haciendo uso de todas las funcionalidades de
Sawtooth, gestionar los permisos de la red de acuerdo con esto.
• Manejar pagos parciales del cheque al momento de ser presentado al banco.
• Haciendo uso de los eventos de Sawtooth se podrían manejar notificaciones a las
partes interesadas cuando haya un cambio en el estado del cheque.
• Diseñar una nueva familia específica para el caso en lugar de adaptar la familia de
en los proyectos base de ejemplo dados por Sawtooth.
• Por otro lado, es posible ampliar el alcance del proyecto para incluir otros tipos de
títulos valores más complejos.

Precisamente, este último punto es el enfoque para la iteración del semestre 2021-I.
Integrar aquellos títulos valores trabajados previamente en una única solución que
generalice algunos casos de uso comunes entre los diversos títulos valores.
2.5 Identificación del problema

La identificación del problema se describe de inconvenientes comunes que se presentan

relacionados al uso títulos valores tradicionales:

• Deterioro físico del soporte del título valor.

• Extravío del soporte del título valor.
• Falsificación y/o invalidez del soporte del título valor.
• Vencimiento de derechos sobre el título valor.

Este tipo de inconvenientes suelen presentarse con frecuencia al momento de poseer un

título valor soportado de manera física; lo cual genera una muy mala experiencia de uso,
pérdida de valor o justificación del ejercicio de los derechos soportados por el título valor,
e incluso repercusiones legales asociadas a los posibles problemas de reclamación.

3. Diseño y Especificaciones

3.1 Definición del problema

Los problemas que se buscan solucionar con la incursión de desmaterialización de títulos
valores son:

• Repudio de acciones relacionadas a transacciones sobre títulos valores.

• Falsificación y/o adulteración del derecho literal expresado y fundamentado sobre
un soporte físico.
• Deterioro y pérdida del soporte físico para ejercer el derecho de reclamación de un
título valor.
• Vencimiento o prescripción del ejercicio de derecho sobre un título valor.
• Desconfianza en los mecanismos tradicionales del ejercicio de derecho sobre un
título valor.

Este conjunto de problemas se asocia fuertemente al hecho de que los títulos valores
tradicionales son fundamentados en un soporte físico el cual puede presentar cualquiera
de las condiciones mencionadas anteriormente. Por ende, la intención de
desmaterialización de dichos documentos pretende tomar gran valor hacia el usuario final
y también hacia entes financieros; todo sobre un marco legislativo que avale el uso y
circulación de dichos documentos virtuales.

3.2 Especificaciones

Establecer requerimientos precisos para el proyecto. Clasificar requerimientos en

funcionales (entada / salida) y no funcionales (cualitativos, metodología esperada en la
construcción de una solución, desempeño esperado de una solución, …).
Discutir la posibilidad de aceptar soluciones aproximadas y niveles de aceptación (v.gr.,
deseable, aceptable) y justificar cuándo una solución inexacta o incompleta podría
desarrollarse.

3.2.1 Requerimientos funcionales

ID Nombre RF Quién Resultado Entrada

RF-1 Librar un Usuario Librar título valor a - Tipo de título valor.
título valor beneficiario -Datos asociados al
título valor.
- Soportes
necesarios asociados
al título valor.
RF-2 Adquirir un Usuario Recibir título valor de - Titulo valor
título valor entidad financiera
por parte de
ente
financiero
RF-3 Endosar un Usuario Endosar título valor a -Id título valor.
título valor de otra persona. -Cedulas de ambas
mi propiedad partes.
a otra -Firma de endoso.
persona.
RF-4 Ver lista de Usuario Lista de títulos valor
títulos valor como librador.
donde
aparezco
como
librador
RF-5 Ver lista de Usuario Lista de títulos valor
títulos valor como beneficiario.
donde
aparezco
como
 beneficiario
RF-6 Ver el detalle Usuario Ver el detalle de un -Id del título valor.
de un título título valor.
valor en el
que participo
RF-7 Ver el Usuario Historial de un título -Id del título valor.
historial de valor.
endosos de
un título
valor
RF-8 Asignar Usuario Dar chequera a usuario
chequera (Banco o el cual realice la
virtual a un entidad petición.
usuario financiera
responsable
)

3.2.2 Requerimientos de calidad

ID Nombre Expectativa
REQ-NF-1 Usabilidad La solución debe ser sencilla, fácil
e intuitiva de usar. Con el fin de
que personas que nunca utilizan
los medios virtuales o los títulos
valores puedan usarla.
REQ-NF-2 No repudio La solución debe garantizar la no
duda de la identidad de su
originador.
REQ-NF-3 Privacidad Se debe respetar la protección de
los datos acorde a la ley.
REQ-NF-4 Conformidad a las leyes La solución debe contemplar todos
los atributos necesarios de cada
título valor con el fin de acreditar
su validez en el ámbito legal y
judicial.

3.3 Condiciones y/o Restricciones

• Tecnológicas y de implementación
o Ceñirse en gran medida a la arquitectura de referencia
 o Los títulos valores deben contener todos los campos que se estableces según
la ley.
o Garantizar que la información de cada título valor no sea modificada.
o Validar la firma electrónica.

• Dominio de conocimiento
o Consideración y acato de las instrucciones y recomendaciones dadas por el
grupo de abogados.

4. Desarrollo del Diseño

El proceso de diseño de solución constó de un proceso iterativo sobre la definición de la

arquitectura establecida. El profesor asesor Darío Correal y el estudiante doctoral Luis
Esteban Flórez, cumpliendo los roles de arquitectos de software principales; generaron
gradualmente la arquitectura propuesta; en complemento a las consideraciones y
recomendaciones por parte de la profesora co-asesora María Lorena Flórez y Andrea
Guzmán.

4.1 Recolección de información

El proceso de recolección de información primordial se clasifica en los intereses

manifestados por los stakeholders:

• Ingenieros:

El grupo de ingeniería (en función de consultor), conformado por nuestro profesor asesor
Darío Correal, el estudiante Doctoral Luis Flórez, el asistente graduado Andrés Rodríguez, y
los estudiantes asociados al proyecto para la vigencia 2021-10 Manuel Vallejo y Julián
Bermúdez, manejó una metodología de reunión, contextualización, correcciones, y
definición de tareas cada semana con el fin de refinar el proyecto. Algunas de las actividades
más relevantes fueron los diálogos para la definición de una arquitectura de referencia con
el objetivo de cumplir con los requerimientos administrativos y transaccionales sobre la
solución y la retroalimentación continua de los avances.

• Abogados:

El grupo de abogados (en función de clientes), conformado por la profesora María Lorena
Flórez y la economista Andrea Guzmán, fueron de gran valor en cada una de las sesiones
semanales al compartir todo su conocimiento referente a los parámetros legales a
considerar en el proceso de desarrollo. Adicionalmente, sus aportes sobre temas
relacionados a Blockchain, contexto legislativo y de control sobre soluciones actuales, y
relacionados, fue relevante al momento de abstraer y direccionar una solución enfocada a
la realidad.
Adicionalmente, en las primeras semanas se dispusieron temas y espacios de investigación
y experimentación para aplicar los conocimientos adquiridos.

4.1.1 Interdisciplinaridad junto con la Facultad de Derecho

La rama investigativa tiene un fuerte vínculo interdisciplinar con la Facultad de Derecho de

la Universidad de los Andes. La profesora y doctora Lorena Flórez1, interesada y
patrocinadora principal del proyecto; quién en asociación con la universidad y la facultad,
se especializa e imparte cursos asociados a títulos valores y derecho comercial.
A lo largo de los distintos periodos de ejecución del proyecto la profesora Lorena ha
aportado su conocimiento, recomendaciones y retroalimentación sobre el trabajo
realizado; ella ha sido parte fundamental de la rama de investigación, a ella muchas gracias.
Adicionalmente, para esta versión del proyecto se contó con el consejo y los aportes de la
estudiante de Derecho y economista Andrea Guzmán, quien ofreció su conocimiento
mediante artefactos de gran valor. A nivel conceptual se resalta su contribución en
dinámicas económicas, estado del arte sobre ‘open banking’, comportamientos de los
títulos valores, consideraciones adicionales sobre las casuísticas de situaciones sobre títulos
valores, entre otros; a nivel de artefactos, agradecemos la colaboración y difusión de
diagramas de flujos y estados, mapas mentales, referencia a leyes y demás recursos
relacionados sobre títulos valores.

4.2 Procesos de negocio

Flujo de estados para la creación y endoso de un título valor:

• Pagaré

1
Perfil docente de la profesora María Lorena Flórez Rojas en
https://derecho.uniandes.edu.co/en/professors/profesores/maria-lorena-florez-rojas
 Imagen. Diagrama de estados título valor (pagare).

Imagen. Diagrama de estados título valor (Pagare).

• Cheque
 Imagen. Diagrama de estados título valor (Cheque).

4.3 Proceso creativo de un título valor

El proceso creativo de un título valor, requirió identificar las similitudes y diferencias entre
los diversos títulos valores. Esto fue posible gracias al aporte de la profesora Lorena Flórez
y la estudiante Andrea Guzmán, quienes socializaron los aspectos más relevantes acerca de
los títulos valores. La siguiente tabla muestra la comparativa entre títulos valores:

Pagarés Cheques Otros títulos

valores
Estados Sí Sí Sí
Son transferibles Sí Sí Sí
Necesitan librador Sí Sí Sí
Necesitan entidad No Sí Algunos
financiera

Ahora, las tres etapas identificadas para crear un título valor son:
 Imagen. Proceso creativo de un título valor

La descripción de cada etapa se describe seguidamente:

• Definición del flujo de sucesos de un título valor cómo máquina de estados.

Cómo se vio en la sección 4.2 Procesos de negocio, el paso inicial recomendado es identificar
el flujo de ocurrencias que se presentan en un título valor. A nivel conceptual, este flujo de
ocurrencias secuenciales es interpretado como una máquina de estados que ayuda a
comprender el comienzo, los pasos intermedios, y el final de todo lo que podría suceder
con sobre la casuística de dicho título valor. Así mismo, se definen las condiciones y/o
restricciones entre estados, y la precedencia entre estos.

• Estructuración de atributos de un título valor.

El reconocimiento de los atributos que conforman un título valor es de gran importancia

para definir el tipo de información que debería soportar el sistema de manera integral;
considerando puntos de ingreso, transporte y residencia de la información. La
implementación de dichos atributos se define de manera dinámica considerando la gran
variedad, variabilidad, y distinción de atributos entre los diversos títulos valores.

• Implementación programática de un título valor.

o Definición de interfaces visuales.

Una vez se tiene definida una máquina de estados que sea en lo posible fielmente
interpretable a los casos de uso de un título valor, se procede a definir programáticamente
estos estados a nivel comportamental y visual. A continuación, se muestra un breve ejemplo
de cómo se define el orden y las condiciones de transiciones sobre los diversos estados de
un título valor:

Imagen. Definición de máquina de estados para título valor (Interfaz)

La propiedad “states” se compone de un conjunto de estados que poseen nombre, color

(color el cuál se visualizará en las interfaces), y conjunto de estados predecesores a los
cuales se puede realizar una transición.

o Lógica de dominio del título valor.

 o Lógica de persistencia y consenso del título valor.

La lógica de persistencia y consenso se refiere a tolo

4.4 Diagrama de contexto

Para comprender el flujo de la información, los dominios y usuarios que interactúan en el

sistema, se expone el siguiente diagrama de contexto:

Imagen1. Diagrama de contexto títulos valores.

• Usuarios: Se consideran los usuarios finales o tipo persona natural, que son aquellos
usuarios que adquieren un conjunto de servicios financieros enfocados a títulos
valores; por otro lado, se considera el usuario entidad financiero o administrador
quien gestiona la creación y la asignación de títulos valores para cada usuario final.

4.5 Diagrama de despliegue

Para entender la estructura arquitectural del proyecto, el estudiante doctoral Luis Esteban
Flórez desarrolló el concepto evolutivo sobre la arquitectura de referencia, la cual fue
esencial para orientar el trabajo por cada uno de los frentes de desarrollo identificados
mediante dicha arquitectura.

La arquitectura de referencia se expone a continuación:

 Imagen2. Arquitectura de referencia V5. Autoría Luis Esteban Flórez Salamanca.

Cabe resaltar que sobre la visión general del diagrama de arquitectura a tres frentes que
valen la pena resaltar:

• Interfaz visual

Imagen3. Interfaz visual.

Frente relacionado a la interfaz visual exhibida tanto al usuario final (cliente) poseedor de
diversos servicios de títulos valores, cómo al usuario administrador que tiene potestad
sobre la creación y asignación de servicios de títulos valores.
Esta capa es responsable de administrar y validar las credenciales del usuario final y de
firmar las transacciones que se deseen ejecutar sobre el sistema; para ello, se hace uso de
mecanismos de criptografía asimétrica proveyendo al usuario de una llave privada, la cual
solamente debe conocer cada usuario de manera personal y no debería compartirse; y una
llave pública, a la cual podrían tener acceso cualquier entidad o usuario en el sistema
(inclusive, dicha llave publica podría funcionar como mecanismo de identificación de
entidades o usuarios).

• API Dominio

Imagen4. API Dominio Especifico.

El API de dominio se preocupa y garantiza la administración de información estrechamente

ligada al dominio de conocimiento o dominio de conocimiento, esto es el dominio de títulos
valores. Esta API ofrece puntos de consumo para la administración de los diversos títulos
valores bajo una lógica de alto nivel. Es decir, los casos de uso dados por esta API se
relacionan con la creación, actualización, obtención, y eliminación de los títulos valores para
cada perfil de usuario (usuario final o cliente, y administrador o entidad financiera).
La conexión a la base de datos del dominio del negocio es directa, en este caso el API de
dominio se conecta al Ledger Sync (base de datos en MongoDB) para obtener información
de manera sencilla y rápida.

• API Blockchain
 Imagen5. API Blockchain.

El API Blockchain debe garantizar que se persista información transaccional de cualquier

tipo. De esta manera, la lógica del negocio debe afectar mínimamente sobre los casos de
uso relacionados a la manipulación de información sobre Blockchain.
La intención del aporte principal ofrecido por esta API se pensó como una capa de
generalización de administración de transacciones para Blockchain, teniendo inclusive en
cuenta el uso de múltiples plataformas Blockchain según la conveniencia de uso (como se
observa en el gráfico, integrar plataformas cómo Sawtooth, Fabric, Ethereum, entre otras)
y adicionalmente conectar adaptadores que se encargaran de la información no
perteneciente propiamente a Blockchain, es decir información que debería residir de modo
“off-chain”.
Adicionalmente, los protocolos de comunicación con esta capa se visionaron cómo
protocolos síncronos (HTTP REST) y asíncronos (cola de mensajes); con el fin de explorar
varios escenarios de uso. Debido a limitaciones de ejecución y tecnológicas, actualmente se
garantiza la comunicación síncrona mediante el protocolo HTTP REST.

5. Implementación

5.1 Descripción de la implementación

La descripción de la implementación se divide en tres capas, que representa los dominios

de ejecución a cargo de cada desarrollador:

5.1.1 Clientes Web

La implementación del cliente web se fundamentó en ofrecer una interfaz visual funcional
que integrara los distintos títulos valores, y que permitiera interactuar con los casos de uso
relacionados a cada título valor.
Del cliente web para el usuario final, se resalta la labor realizada para:
 • Permitir visualizar e interactuar con las acciones y/o transacciones realizadas para
cierto título valor.
• Permitir visualizar el resumen financiero de la cuenta.
• Permitir la solicitud y adquisición de títulos valores.
• Definir un título valor mediante la descripción de sus atributos.
• Definir el flujo de información de los estados de un título valor.

5.1.1.1 Casos de uso de cliente web - usuario final

• Registro de cuenta

Imagen6. Registro cliente web.

Esta es la vista de registro, la cual se compone de un formulario de registro de información

relacionada al perfil del usuario.
 Imagen7. Firma registro a través de Metamask

Se debe firmar el payload de solicitud de registro para proceder con la solicitud de

transacción hacia el sistema Blockchain, esto permite auditar quién ingresa al sistema como
medida de seguridad básica.

• Ingreso a cuenta

Imagen8. Pantalla inicio.

La vista de inicio de sesión solicita el documento de identificación, el tipo de documento,

el correo electrónico y la contraseña para poder ingresar a la cuenta del usuario.
 Imagen9. Firma ingreso a cuenta a través de Metamask.

De igual manera, se debe firmar el payload de solicitud de ingreso para proceder con la
solicitud de transacción hacia el sistema Blockchain.

• Librar un título valor

Imagen10. Creación de un título valor (Cheque).

A continuación, se muestra la vista de “girar un cheque” un tipo de instancia para librar un
cheque cómo título valor. Los datos necesarios para realizar girar el cheque son: número de
identificación del beneficiario, tipo de identificación del beneficiario, suma a girar en
números, suma a girar en letras, tipo de cheque, fecha de vencimiento o prescripción, y la
cedula de la persona que gira el cheque (buscando verificar el giro y evitar el posible repudio
de la transacción).

La acción de girar un cheque requiere de la firma del usuario que realiza el giro, mediante
Metamask.

• Adquisición de un título valor mediante entidad financiera

Imagen11. Adquisición de un título valor.

Imagen12. Información del usuario y servicios.

El proceso de adquisición de un cheque mediante entidad financiera inicia desde la vista
general o el resumen del producto “Cheques”; en esta vista es posible seleccionar la opción
“comprar”, esta acción direcciona a la vista de adquisición de servicios en la cual es posible
adquirir el título valor deseado. Una vez finalizada la transacción, los títulos valores
adquiridos son asociados a la cuenta del usuario en el estado de “En Posesión”, lo cual
dispone la cantidad de títulos valores adquirida para su uso.

• Endosar un título valor

Imagen 13. Información de cheque y cadena de endosos.

Imagen 14. Endosar cheque.

El proceso de endoso de un título valor se compone de la vista de detalle de un título valor,
una vez se selecciona la opción de endosar; se expone una nueva vista que solicita el
número de identificación y el tipo de identificación del usuario a quien se le endosará el
título valor.

• Ver títulos valores girados

Imagen 15. Títulos valores en tu cuenta.

La gráfica muestra la vista en donde se tienen los títulos valores librados. En el caso puntual
de un cheque, se tiene el listado de los cheques girados.

• Ver títulos valores recibidos

Imagen 16. Títulos valores recibidos.

La gráfica muestra la vista en donde se tienen los títulos valores recibidos.

• Ver detalle de título valor y ver cadena de endosos

Imagen 17. Información título valor (Cheque).

La vista de detalle de un título valor se compone de la información asociada tanto al librador

como al beneficiario del título valor. Además, también muestra la cadena de endosos
asociada a dicho título valor y la posible opción de ver un documento digital en forma de
PDF.

5.1.1.2 Casos de uso de cliente web - administrador

• Creación de un título valor cómo servicio/producto

Imagen18. Creación servicio.

Cómo administrador, la entidad financiera tiene la posibilidad de crear un nuevo título
valor. Para ello, se requiere la especificación de sus meta-atributos (esencialmente tipo de
título valor, tipos de valores, tipos de usuarios relacionados, fechas, firmas, entre otros),
definición de sus estados, visualización en el dashboard general, visualización en el resumen
del título valor, y visualización en el detalle del título valor.

• Detalle de estados de transacciones sobre un título valor

Imagen19. Historial de estados título valor.

El usuario administrador tiene la opción de revisar el historial de estado asociado a un

título valor. La vista anterior evidencia tal funcionalidad.

5.1.2 API de Dominio

El proyecto tuvo la necesidad de exponer una API de dominio específico sobre las
funcionales necesarias para el manejo de los diferentes títulos valores. Esto incluye a los
cheques y a los pagarés; en general, se pretende considerar la administración de títulos
valores de manera general del lado del usuario final.

Este api se desarrolló en JavaScript, utilizando nodejs como REST framework. Se utilizo para
hacer las consultas más eficientes una base de datos en mongoDB. Por otro lado, en el
proceso de autenticación se utilizó JWT para manejar la autenticación y autorización. Por
último, se utilizó un ledger al cual se le realizan las peticiones con el fin de almacenar la
información de la transacción en la respectiva Blockchain.
• Generalización

Imagen20. API REST en Swagger

o Post título valor

En este método se define la TRANSACTION_FAMILY la cual es importante para
definir en el Blockchain. Además, se define la dirección dependiendo de la
transacción y el id. Por último, el payload el cual es la transacción en los
argumentos y el tipo de transacción que es.

Imagen21. Método creación título valor.

 o GET título valor
En este método lo que se realizaba era una búsqueda en la colección de la
base de datos desplegada en mongdb. Esto con el fin de hacer las consultas
de manera más eficiente.

Imagen22. Método visualización de un título valor.

5.1.3 API/Fachada sobre Blockchain (Ledger Distributed API)

5.1.3.1 Propósito y generalidades del API Blockchain

El Proyecto contemplo la necesidad de exponer una API tipo fachada sobre las
funcionalidades de persistencia y administración sobre plataformas Blockchain, esto con los
objetivos de:

• Generalizar las funciones sobre Blockchain.

• Diversificar los protocolos de comunicación (REST API / Cola de mensajes).
• Permitir integrar futuras plataformas Blockchain (buscando disminuir el tiempo de
desarrollo asociado).

En esta ocasión, el foco es brindar una API de administración sobre Blockchain soportado
mediante Hyperledger Sawtooth, pero cómo trabajo futuro se desea proveer facilidad de
integración con diversas plataformas Blockchain.

A continuación, se exponen los criterios de desarrollo relevantes:

• Generalización:

Acorde a la investigación de APIs sobre plataformas Blockchain pertenecientes a

Hyperledger (Sawtooth y Fabric), se evidenció que las acciones más relevantes para la
administración de información en Blockchain son: Crear una transacción, Obtener todos los
estados persistidos, y Obtener un estado persistido en específico. De este modo se definió
una API básica que consta de:

Imagen23. API REST en Swagger Blockchain.

o Sobre POST de Transacción

Para persistir una transacción, se consideró importante establecer una modelo de

información que permitiera parametrizar la entrada necesaria para crear una transacción
sobre Hyperledger Sawtooth.
El modelo de información para el POST de una transacción tiene un trasfondo en el modelo
de web semántica RDF. En el cual se exhiben relaciones entre sujetos y/o objetos que
ejecutan cierta acción (o predicado). De este modo, se pretende relacionar a lo máximo 2
entidades implicadas en una acción.

- Iteración 1:
A continuación, se exhibe la Iteración 1 de inputs para el POST de una transacción:

Imagen 24. Iteracion1 POST.

También, se provee una explicación del esquema:

/**
* @Schema:
*
* - context: Indicates the context of the app/project.
*
* - subject: Major entity who performs the predicate.
* - signature: Signature that identifies the major subject performing a
predicate.
*
* - predicates: Set of objects that describe actions performed over
objects and possibly related to
* subjects.
* - action: Description of the action to be performed over the object.
* - object: Entity over which the predicate is going to be performed.
* - _id_: Client-side defined object ID (optional).
* - domain: Object domain (alias 'name').
* - properties: Multi-value data dependent to the context domain.
*
* - _subject_: Possible subject who is related to the predicate
performed. (optional).
* - signature: Signature that identifies the minor subject related to
a performed predicate.
*/
La primera iteración del modelo de creación de una transacción tuvo el objetivo de
representar los actores (sujetos) y las acciones (predicados) realizadas sobre los objetos.
Puntualmente, para el caso de títulos valores, los actores serían los usuarios finales, las
entidades financieras, e incluso las entidades artificiales (máquinas); las acciones son las
transacciones relacionadas a transiciones de estados del título valor; y los objetos son los
diversos títulos valores que pueda soportar la aplicación.

- Iteración 2
A continuación, se exhibe la Iteración 2 de inputs para el POST de una transacción:

Imagen 25. Iteracion 2 POST.

La iteración 2 se centró en diferenciar cada actor relacionado en una acción. Es así cómo
se evidencia un actor principal (major), quién emite o ejecuta cierta acción; y un actor
secundario (minor), quien recibe o es afectado por dicha acción.

- Iteración 3

A continuación, se exhibe la Iteración 2 de inputs para el POST de una transacción:

 Imagen26. Iteracion 3 POST.

La tercera iteración, buscó brindar la posibilidad de realizar distintas acciones de manera

secuencial y transaccional. De esta forma,

- Iteración 4 (y final)

Imagen27. Iteracion 4 POST.

En esta última versión para crear una transacción (y posteriormente un estado sobre
Blockchain) hay un énfasis en la transacción puntualmente; y se omiten explícitamente las
relaciones entre actores, acciones y objetos. Estas relaciones ahora se manejan mediante
una traza que indica la historia de la transacción y a quien ha pertenecido de manera
secuencial.

Cómo reflexión final, es oportuno resaltar que si bien las primeras 3 versiones del modelo
de creación de transacciones y estados sobre Blockchain tuvo una evolución escalonada
basada en la forma en cómo se concibió persistir la información en Blockchain inicialmente,
la administración de la información mediante este modelo de persistencia se complicó de
manera significativa.
Ahora bien, con una implementación más liviana fundamentada en la información de la
transacción; y no en las posibles relaciones entre los diversos actores, acciones y objetos
mejoró la forma en cómo se manipulan las transacciones (y consecuentemente los estados)
sobre el sistema Blockchain.

o Sobre GET estado y GET estado específico:

Para aquellos casos de uso relacionados a la obtención de información, se hizo uso del
componente definido como Ledger Sync por Luis Esteban Flórez. Este componente se
definirá posteriormente.
La incursión del componente Ledger Sync fue de gran importancia puesto que consultar de
manera nativa los estados de información sobre Blockchain, puntualmente Hyperledger
Sawtooth, es una tarea dispendiosa y propensa a fallos; dada la manera de persistir y
referenciar un estado sobre el sistema Blockchain.
No obstante, con el uso del Ledger Sync, las consultas son soportadas por una base de datos
(MongoDB) que se sincroniza cada vez que un estado es confirmado cómo persistido en
Blockchain.

• Protocolos de comunicación

La arquitectura de referencia tiene en cuenta dos protocolos de comunicación: HTTP REST

API y Cola de mensajes. Teniendo en cuenta el esfuerzo requerido por cada uno de los
protocolos, se decidió enfatizar la implementación para el protocolo HTTP REST API, dado
que es un protocolo bastante común y de carga de desarrollo liviana. Por otro lado, la
implementación de comunicación asíncrona mediante colas de mensajes se vio
interrumpida por limitaciones técnicas que aumentaron la complejidad de dicha
implementación; este protocolo se enuncia como posible mejora en un trabajo futuro.

• Integración de múltiples plataformas Blockchain

El criterio de manejo de múltiples plataformas Blockchain sobre el proyecto fue un aspecto
que también se consideró en el ciclo de vida del proyecto. De esta forma, una gama diversa
de plataformas Blockchain eventualmente podrían ser integradas para hacer una
comparativa de desempeños y casos de uso alcanzables con cada tipo de tecnología. En esta
ocasión, la plataforma seleccionada fue Hyperledger Sawtooth, bajo el concepto de los
buenos resultados presentados en iteraciones y trabajos previos.

5.1.3.2 Hyperledger Sawtooth en relación con la arquitectura de referencia

Retomando el diagrama de despliegue, se evidencia que el componente Ledger Distributed

API es un componente generalizador e integrador de una gama variada de plataformas
Blockchain; este componente debe contar con submódulos o adaptadores especializados
que garanticen las funcionalidades de administración de información en Blockchain de
forma independiente para cada plataforma. Adicionalmente, la aplicación se debe
desplegar para cada entidad financiera de manera individual; por ende, se requiere de un
grupo de escalamiento que administre las instancias distribuidas de la aplicación. Se
muestra el diagrama a continuación:

Imagen28. Especificación de despliegue Ledger Distributed API

A continuación, se explicará cómo Hyperledger Sawtooth está involucrado en la

arquitectura de referencia. Las siguientes gráficas pretenden mostrar las responsabilidades
y relaciones entre los componentes de la zona Blockchain.
 Imagen29. Flujo de comunicación componente API Blockchain

Realizando un enfoque sobre el diagrama de contexto, la zona Blockchain se conforma por:

• API Blockchain: La exposición de los servicios en forma de fachada se realiza en este

módulo, se brinda acceso a funciones de manipulación de información de manera
general sobre sobre Blockchain.
• SmartContracts: La definición de los smartcontracts se realiza de manera
independiente, y va ligado a la infraestructura Blockchain. En el caso de Sawtooth,
la conexión se realiza hacia los componentes denominados cómo validadores. La
responsabilidad de los smartcontracts es el manejo de la lógica adicional que se
desee integrar para persistir la información en Blockchain.
• Infraestructura Blockchain: La infraestructura Blockchain es provista mayormente
por las plataformas Blockchain (Sawtooth, Fabric, Ethereum, por ejemplo) las cuales
brindan una arquitectura lista para ser desplegada. Para Sawtooth, la arquitectura
 es desplegada mediante contenedores soportados por Docker los cuales disponen
diversos servicios. Posteriormente, se describirá la arquitectura provisionada por
Sawtooth.
• Ledger Sync: El componente Ledger Sync se encarga de sincronizar la información
sobre Blockchain mediante la suscripción de eventos que confirmen la persistencia
satisfactoria de la información en Blockchain. Para ello, se usa una base de datos
que acomode el modelo de datos desde Blockchain y lo represente de manera
entendible y que favorezca la consulta de la información.

5.1.3.3 Revisión sobre la infraestructura de Sawtooth

En el apartado 5.1.3.2 en el punto “Infraestructura Blockchain” se dio una descripción

acerca de los servicios que se deben disponer para soportar los sistemas de acceso y/o
comunicación, administración, consenso, validación y auditoría sobre Blockchain.
En este apartado se profundizarán algunos de los conceptos que tuvieron mayor prelación
con el proyecto.

Imagen 30. Arquitectura Sawtooth.

Para el caso de Hyperledger Sawtooth, la arquitectura e infraestructura provista se
compone de:

• Clientes: Los clientes, son aquellos componentes que establecen conexión con el
ambiente de Sawtooth mediante la API REST. Desde este tipo de componentes se
realiza la serialización de los datos para enviar la solicitud de transacción al API REST.
En el caso de la implementación del proyecto, el cliente es el Distributed Ledger API.
• API REST: Este componente expone servicios de administración de las transacciones,
estados, bloques y recursos sobre Sawtooth.
• Procesadores de transacciones: Los procesadores de transacciones son la instancia
de SmartContracts de Sawtooth. Estos son definidos por el desarrollador,
conteniendo toda la lógica de validación previa a la persistencia sobre Blockchain.
• Validadores: Componente principal encargado de orquestar la recepción de
transacciones, la persistencia de estados, la administración de los bloques, y el
consenso.
 Imagen31. Grupo de contenedores de infraestructura / arquitectura Sawtooth

En la gráfica anterior, se evidencian los servicios desplegados sobre Docker. Este es un

despliegue simple con un solo nodo, lo cual facilita la etapa de implementación en etapas
tempranas de desarrollo.

5.1.3.4 Definición de SmartContracts

En este apartado se centra en la especificación de la definición de algunos Smart Contracts

implementados en el marco del proyecto.
El paradigma de implementación se basó en extender las capacidades del SDK de Sawtooth,
ya que las funciones por defecto ofrecidas por el SDK se consideraron algo rudimentarias y
limitadas; por ende, surgió la necesidad de extender dichas funcionalidades; este módulo
se denominó “Sawtooth-TP-Wrapper”. Por otra parte, se implementó también la lógica de
validación y persistencia relacionada puntualmente sobre la información que recaería sobre
Blockchain como tal; este módulo se denominó “TP-Handler”. Se muestran fragmentos de
código para profundizar en los conceptos a continuación:
 • Sawtooth TP Wrapper

Imagen32. Sawtooth TP Wrapper

El fragmento de código muestra la extensión sobre las funciones básicas del SDK de
Sawtooth para administrar la información sobre Blockchain. Las funciones más relevantes
son getState, putState, deleteState; las cuales son funcionales que redefinen parcialmente
la lógica de acceso y persistencia sobre Blockchain. Adicionalmente, se añadieron otras
funciones y valores contextuales que sirven para soportar funcionalidades específicas
(context, transactionProcessRequest, publicKey).

• TP Handler
Imagen33. TP Handler
El módulo “TP-Handler” contiene la lógica de validación de información de entrada y se
encarga de invocar los servicios de administración de información definidos en

5.1.3.5 Ledger Sync

El componente Ledger Sync fue adaptado y rediseñado por Luis Esteban Flórez, quién
formalizó el concepto y lo aplico sobre el proyecto de títulos valores propiamente.
Cómo se mencionó anteriormente, el Ledger Sync es precisamente un componente que
sincroniza la información persistida de forma efectiva y confirmada sobre Blockchain. Dicha
confirmación se verifica mediante la suscripción a eventos relacionados a cambios recientes
sobre la información2; una vez se valida que la transacción o solicitud de persistencia y/o
modificación de información fue satisfactoria, se procede a tomar esa información y se
mapea a un dominio de datos definido y fácil de interpretar; puntualmente, un modelo de
datos soportado mediante una base de datos (para el proyecto se usó MongoDB como
tecnología de bases de datos).
Enviar de manera periódica y reactiva la información de Blockchain al Ledger Sync es una
tarea clave dado que aliviana procesos de consulta de información directamente sobre
Blockchain, lo cual no es fácilmente intuitivo debido a su paradigma de referenciación y
persistencia de información. 3 Por ende, el componente como tal es de suma importancia.
Hyperledger provee una definición base de lo que es el Ledger Sync, esta puede ser
encontrada en el repositorio de caso de ejemplo “Marketplace”
(https://github.com/hyperledger/sawtooth-marketplace/tree/main/ledger_sync).

6. Validación

Para la etapa de validación se tuvieron en cuenta aspectos técnicos y experiencia de uso

relacionados a la capacidad

Respecto a la carga de trabajo, se realizaron sesiones de pruebas que fueron orientadas a

medir el umbral de la tasa de carga máxima que puede soportar la aplicación actualmente.
Se probaron los servicios de autenticación (ingreso y registro de un usuario) dado que
dichos servicios son fundamentales y relativamente livianos a nivel de esfuerzo
computacional.

6.1 Pruebas de carga

2
Suscripción a eventos en Sawtooth: https://sawtooth.hyperledger.org/docs/core/nightly/1-
2/app_developers_guide/about_event_subscriptions.html#
3
Sistema de referenciación y persistencia de información “Global state”:
https://sawtooth.hyperledger.org/docs/core/nightly/1-2/architecture/global_state.html
6.1.1 Resultados individuales (por iteración)

I. Resultados individuales
a. Carga con 10 usuarios y 50 solicitudes HTTP REST

Imagen34. Resultados de carga con 10 usuarios

b. Carga con 20 usuarios y 82 solicitudes HTTP REST

Imagen35. Resultados de carga con 20 usuarios

c. Carga con 40 usuarios y 128 solicitudes HTTP REST

 Imagen36. Resultados de carga con 40 usuarios.

d. Carga con 60 usuarios y 185 solicitudes HTTP REST

Imagen37. Resultados de carga con 60 usuarios.

e. Carga con 80 usuarios y 238 solicitudes HTTP REST

 Imagen38. Resultado de carga con 80 usuarios.

f. Carga con 100 usuarios y 256 solicitudes HTTP REST

Imagen39. Resultado de carga con 100 usuarios.

g. Carga con 120 usuarios y 247 solicitudes HTTP REST

 Imagen40. Resultado de carga con 120 usuarios.

h. Carga con 140 usuarios y 276 solicitudes HTTP REST

Imagen41. Resultado de carga con 140 usuarios.

i. Carga con 160 usuarios y 317 solicitudes HTTP REST

 Imagen 42. Resultado de carga con 160 usuarios.

j. Carga con 180 usuarios y 296 solicitudes HTTP REST

Imagen43. Resultado de carga con 180 usuarios.

k. Carga con 200 usuarios y 362 solicitudes HTTP REST

 Imagen44. Resultado de carga con 200 usuarios.

A continuación, se muestra de forma tabular el consolidado de los resultados obtenidos

para cada prueba de carga.

Iteración Solicitudes Usuarios Tasa de carga Tasa de éxito Duración

virtuales (solicitud/seg) (%) (seg)
(VUs)
1 50 8 a 10 4.47 100 (50/50) 11.2
2 82 2 a 20 6.48 100 (82/82) 11.7
3 128 5 a 40 10.50 100 (128/128) 12.2
4 185 24 a 60 14.68 100 (185/185) 12.6
5 238 31 a 80 17.70 100 (238/238) 13.4
6 256 9 a 100 19.62 100 (256/256) 13.0
7 247 22 a 120 17.11 100 (247/247) 14.4
8 276 34 a 140 17.09 100 (276/276) 16.1
9 317 3 a 160 7.91 100 (317/317) 40.0
10 296 2 a 180 17.88 100 (296/296) 16.5
11 362 40 a 200 17.94 83.97 (304/362) 20.2

El comportamiento óptimo se presentó en la iteración 6, con una tasa de carga de 19.62

solicitudes/seg, hasta 100 usuarios virtuales simultáneos y 256 solicitudes realizadas, con
una duración total de 13.0 segundos.

El comportamiento de falla se presentó en la iteración 9, con una tasa de carga de 7.91

solicitudes/seg, hasta 160 usuarios virtuales simultáneos y 317 solicitudes realizadas, con
una duración total de 40.0 segundos.

6.1.2 Resultados acumulados

Los resultados acumulados, muestran la evolución agrupada de las pruebas de carga

realizadas:

Imagen45. Resultados acumulados.

En el gráfico se puede observar el aumento de usuarios virtuales y solicitudes realizadas

paulatinamente por cada iteración; también se puede evidenciar distintas métricas de
tendencia relacionadas a la duración de la solicitud.

7. Conclusiones

La desmaterialización de títulos valores soportada mediante Blockchain es un proyecto

interesante que genera tanto aportes como retos relacionados a factores legislativos, de
innovación y tecnológicos.
A lo largo del proceso de elicitación y entendimiento del conocimiento, diseño, desarrollo,
retroalimentación e iteración sobre una propuesta de solución, se presentaron espacios
para reflexionar sobre todo lo aprendido y evidenciar que a futuro la desmaterialización de
valores ofrece grandes beneficios tanto para usuarios finales cómo para entidades
financieras y entes regulatorios.
La interdisciplinaridad del proyecto enriqueció en gran manera la experiencia de trabajar
en esta rama investigativa y entender que aparte de un ambiente netamente académico e
investigativo; el proyecto tiene bastante potencial para ser aplicado e incorporado sobre la
cotidianidad de las personas y la industria financiera en Colombia.

7.1 Resumen del trabajo

A partir de la primera reunión estipulada para el trabajo se realizó un plan de trabajo los
temas a tratar y como se iba a desarrollar cada uno de los desafíos propuestos. Las primeras
semanas se trabajó en el aprendizaje conceptual sobre un Blockchain y títulos valores, con
el fin de identificar la posible solución y arquitectura para dicho tema. Por otro lado, la
constante retroalimentación llevada contribuyo a que el desarrollo del proyecto fuera
exitoso y que el prototipo cumpliera los requerimientos legales definidos. Por último, cabe
mencionar que no se implementaron todas las funcionalidades planteadas, pero fue posible
implementar y validar la arquitectura y los requerimientos.

7.2 Desempeño, tiempos de ejecución y limitaciones

En un panorama global, se dio cumplimiento de las funcionalidades más relevantes,

teniendo en cuenta la presencia de algunas situaciones las cuales se enuncian a
continuación.

En la ejecución del proyecto se presentaron dificultades tales cómo, el hecho de realizar

diferentes investigaciones y consultas en el área de derecho con el fin de identificar los
diferentes estados que tiene un título valor. Esto genero demoras en la implementación de
un API de dominio el cual fuera suficientemente amplio, pero a su vez fuera de un solo título
valor para cada uno de los servicios prestados por el prototipo.

Otro factor importante para tener en cuenta que tomo tiempo fue la comunicación entre el
API de dominio y el API del Blockchain ya que se plantearon diferentes esquemas y solo
hasta las últimas iteraciones se tuvo un concepto claro de cómo debíamos comunicarnos
entre los diferentes API utilizados.

Por último, otro factor importante en los tiempos de desempeño fue el cambio realizado
de utilizar TypeScrypt y directamente el framework (NestJS) a utilizar JavaScript con el
framework (NodeJS). Este cambio se realizó con el fin de adaptarnos de una manera más
fácil a la arquitectura propuesta.
7.3 Aportes, retos y trabajo futuro

Cómo aportes se identifican:

• Mitigar de riesgos y problemas asociados a títulos valores soportados físicamente.

• Inspirar confianza de manera natural sobre los títulos valores virtuales, soportados
mediante mecanismos de consenso distribuido y transparente para todas las
entidades y/o partes.

Como retos principales se reconocen:

• Acercamiento a la introducción de nuevas tecnologías para las personas.

• Validez de un título valor digital en aspectos legales e incursión de nuevos procesos
regulatorios y legislativos sobre estas tecnologías.

Actualmente el prototipo cumple los requerimientos, pero este podría ampliarse con las
siguientes funcionalidades:

• Pagos parciales del título valor.

• Gestión de la entidad banco con el fin de realizar los pagos y los descuentos de
dinero.
• Respecto a desarrollo Blockchain
o Implementar protocolos de comunicación asíncrona (colas de mensajes).
o Implementar capa de administración sobre recursos off-chain (capa de
administración de fotos, documentos, y artefactos relacionados a un título
valor)
o Implementación de módulos reactivos a eventos para ofrecer
funcionalidades tales cómo notificaciones, y ejecución de tareas no
dependientes de un ente (usuario final, entidad financiera, etc).

8. Referencias
Leyes desde 1992—Vigencia expresa y control de constitucionalidad
[CODIGO_COMERCIO]. (s. f.). Recuperado de
http://www.secretariasenado.gov.co/senado/basedoc/codigo_comercio.html

Leyes desde 1992—Vigencia expresa y control de constitucionalidad [LEY_0527_1999].

(s. f.). Recuperado de
http://www.secretariasenado.gov.co/senado/basedoc/ley_0527_1999.html

Hyperledger Sawtooth | Hyperledger Sawtooth. (s. f.). Recuperado de

https://sawtooth.hyperledger.org/

Abogados, D. J. C. (s. f.). ¿Por qué es legal endosar pagarés electrónicos utilizando
Blockchain? Recuperado de https://www.colombiafintech.co/post/por-que-es-legal-
endosar-pagares-electronicos-utilizando-blockchain

Documentation | NestJS - A progressive Node.js framework. (s. f.). Documentation |

NestJS - A Progressive Node.Js Framework. Recuperado de https://docs.nestjs.com
Node.js. (s. f.). Documentación. Node.js. Recuperado de https://nodejs.org/es/docs/

Marroquín Velandia, S. (n.d.). CAPÍTULO II SISTEMA GENERAL DE TÍTULOS VALORES EN LA

REPUBLICA DE COLOMBIA.

Realidad, U., Molano, V. M., & Castro, Y. L. (n.d.). LOS TITULOS VALORES ELECTRÓNICOS.

Hyperledger Fabric. (n.d.). Retrieved July 11, 2021, from

https://openblockchain.readthedocs.io/en/latest/

A Blockchain Platform for the Enterprise — hyperledger-fabricdocs master documentation.

(n.d.). Retrieved July 11, 2021, from https://hyperledger-fabric.readthedocs.io/en/release-
2.2/index.html

Títulos valores [Facultad de Derecho]. (n.d.). Retrieved July 11, 2021, from
https://hipertexto-obligaciones.uniandes.edu.co/doku.php?id=titulos_valores

Apéndice

• Repositorio en GitHub: andes-blockchain-lab/security-tittles-2021-10 (github.com)

• Demo casos de uso de aplicación:
https://www.youtube.com/watch?v=_paZKX7JWbU