L3 - Sistema Remoto Una Solución Telemática para La Banca Electronica

UNIVERSIDAD ANDRÉS BELLO
Facultad de Ingeniería
Magíster en Gestión de Tecnologías de Información y Telecomunicaciones
ANÁLISIS DE TECNOLOGÍA BLOCKCHAIN PARA SERVICIO DE

TRANSFERENCIAS ELECTRÓNICAS DE FONDOS (TEF) Y SU APLICACIÓN
EN LA BANCA CHILENA
Trabajo de título para optar al grado de Magíster en Gestión de Tecnologías de
Información y Telecomunicaciones
Autores:
Felipe Bobadilla Alarcón, Fabián Bruna Reyes.
Profesor guía: David Ruete Zúñiga

Santiago de Chile, 2020
ÍNDICE
ÍNDICE .................................................................................................................... 2
ÍNDICE DE TABLAS ............................................................................................... 5
ÍNDICE DE ILUSTRACIONES ................................................................................ 6
1. INTRODUCCIÓN ............................................................................................. 8
1.1. Introducción ................................................................................................ 8
1.2. Motivación .................................................................................................. 9
1.2.1. Casos de Éxito................................................................................... 12
1.2.2. Banca en Chile .................................................................................. 13
1.3. Marco de trabajo ...................................................................................... 15
1.3.1. Dentro de las ventajas que se aprecian en esta decisión se tiene: ... 16
1.3.2. Dentro de las desventajas vemos: ..................................................... 16
1.3.3. Los alcances que tendrá el proyecto serán: ...................................... 16
2. IDENTIFICACIÓN DEL PROBLEMA.............................................................. 17
2.1. Entorno..................................................................................................... 17
2.2. Modelo Ishikawa ...................................................................................... 18
2.2.1. En cuanto al Presupuesto: ................................................................. 19
2.2.2. En cuanto al Personal: ....................................................................... 19
2.2.3. En cuanto a la Operación: ................................................................. 20
2.2.4. En cuanto a la Infraestructura: ........................................................... 20
3. OBJETIVOS, HIPÓTESIS Y ALCANCE ......................................................... 22
3.1. Objetivos .................................................................................................. 22
3.1.1. Objetivo general................................................................................. 22
3.1.2. Objetivos específicos ......................................................................... 22
3.1.3. Métricas ............................................................................................. 22
3.1.4. Trazabilidad ....................................................................................... 25
3.2. Hipótesis .................................................................................................. 25
3.3. Alcances del proyecto .............................................................................. 26
3.3.1. Alcance .............................................................................................. 26
3.3.2. Limitaciones al alcance ...................................................................... 26
3.3.3. Supuestos .......................................................................................... 27
4. MARCO TEÓRICO ........................................................................................ 28
2
4.1. Transferencia de fondos........................................................................... 28
4.2. Blockchain ................................................................................................ 29
4.2.1. ¿Por qué blockchain es tan segura? ................................................. 30
4.2.2. Tipos de blockchain ........................................................................... 31
4.2.3. Las Redes de Blockchain como Servicio (Blockchain as a Service –
BaaS) 35
4.3. Infraestructura hiperconvergente ............................................................. 41
4.3.1. ¿Cómo funciona la infraestructura hiperconvergente? ...................... 41
4.3.2. ¿Qué diferencia hay entre la infraestructura convergente y la
infraestructura hiperconvergente? .................................................................. 42
4.4. Virtualización ............................................................................................ 42
4.4.1. Definición de las máquinas virtuales.................................................. 42
4.4.2. Principales características de las máquinas virtuales ........................ 43
4.5. Contenedores Docker .............................................................................. 43
5. ESTUDIO DE MERCADO .............................................................................. 45
5.1. Sistema de transferencia de fondo. .......................................................... 45
5.1.1. Opciones de pagos en efectivo y sin efectivo. ................................... 45
5.1.2. Un futuro sin efectivo, Suecia ¿así es como será el futuro? .............. 46
5.1.3. ¿Puede blockchain cambiar el mundo financiero? ............................ 46
5.2. Medios de pagos. ..................................................................................... 47
5.3. Actualidad en Chile .................................................................................. 50
6. METODOLOGÍA ............................................................................................ 51
6.1. Metodología de trabajo............................................................................. 51
6.2. Metodología de gestión ............................................................................ 52
6.3. Plan de tesis ............................................................................................. 54
6.3.1. Programación .................................................................................... 55
7. DEFINICIÓN DE REQUERIMIENTOS ........................................................... 56
7.1. Requerimientos funcionales ..................................................................... 56
7.2. Requerimientos no funcionales ................................................................ 57
7.3. Trazabilidad entre objetivos específicos y requerimientos funcionales .... 57
8. SITUACIÓN ACTUAL Y ALTERNATIVAS DE MEJORA................................ 59
8.1. Solución de infraestructura ....................................................................... 61
8.2. Diagrama de Infraestructura actual .......................................................... 62
3
8.3. Diagrama de Nueva Infraestructura ......................................................... 64
8.4. Solución de software. ............................................................................... 64
8.5. Tipo de software ....................................................................................... 65
9. PRERREQUISITOS Y DESPLIEGUE DE LA SOLUCIÓN. ............................ 68
9.1. Instalación de medios............................................................................... 68
9.2. Instalación de prerrequisitos. ................................................................... 70
9.2.1. Instalación de Docker ........................................................................ 70
9.2.2. Instalación Docker-Compose ............................................................. 71
9.2.3. Instalación de lenguaje GO. .............................................................. 71
9.2.4. Instalación de NVM y NodeJs ............................................................ 71
9.2.5. Descarga de imagen Fabric. .............................................................. 72
9.3. Despliegue de una red blockchain básica. ............................................... 72
9.3.1. Conexión a composer ........................................................................ 73
9.3.2. Prueba de transacción blockchain ..................................................... 74
9.4. Construcción de una red blockchain multi-organizacional........................ 76
9.4.1. Caso de uso: Transferencia electronica de fondo entre cuentas. ...... 79
9.4.2. Personalización de integrantes de la red ........................................... 84
10. CRUCE Y VALIDACIÓN DE OBJETIVOS DEL PROYECTO. ..................... 86
10.1. Validaciones de objetivos específicos. .................................................. 86
10.1.1. Obtener una confiabilidad del 98%. ................................................ 86
10.1.2. Disminuir en al menos un 5% el costo de infraestructura. .............. 87
10.1.3. Obtener un 99,7% de disponibilidad del servicio. ........................... 89
11. CONCLUSIONES ........................................................................................ 90
12. BIBLIOGRAFÍA............................................................................................ 94
4
ÍNDICE DE TABLAS
Tabla 1: Costos por infraestructura .................................................................................................................. 19

Tabla 2: Valor estimado de personal actual que administra la infraestructura. .............................................. 20
Tabla 3: Tiempo de incidentes por tópico. ........................................................................................................ 20
Tabla 4: Solución actual infraestructura e impactos ........................................................................................ 21
Tabla 5: Problemas ........................................................................................................................................... 21
Tabla 6: Objetivos específicos ........................................................................................................................... 22
Tabla 7: Métricas .............................................................................................................................................. 23
Tabla 8: Fórmula de porcentaje de confiabilidad ............................................................................................. 23
Tabla 9: Datos de transacciones TEF durante 2020.......................................................................................... 23
Tabla 10: Resultado de fórmula de porcentaje de confiabilidad ...................................................................... 24
Tabla 11: Fórmula de objetivo específico N2 .................................................................................................... 24
Tabla 12: Fórmula de objetivo específico N3 .................................................................................................... 25
Tabla 13: Resultado de fórmula de objetivo específico N3 ............................................................................... 25
Tabla 14: Trazabilidad ...................................................................................................................................... 25
Tabla 15: Descripción ReqFun........................................................................................................................... 56
Tabla 16: Características ReqFun ..................................................................................................................... 56
Tabla 17: Descripción ReqNOFun ..................................................................................................................... 57
Tabla 18: Características ReqNOFun ................................................................................................................ 57
Tabla 19: Trazabilidad ObjEsp vs ReqFun ......................................................................................................... 58
Tabla 20: Valores infraestructura y licencias solución. ..................................................................................... 63
Tabla 21: Resumen de objetivo específico 1 ..................................................................................................... 87
Tabla 22: Costos de implementación y tecnología de la solución .................................................................... 89
Tabla 25: Resumen de objetivos específicos ..................................................................................................... 92
5
ÍNDICE DE ILUSTRACIONES
Ilustración 1: Tecnologías claves ...................................................................................................................... 11

Ilustración 2: Gráfico de tenencia de cuentas transaccionales por país. .......................................................... 14
Ilustración 3: Gráfico de transacciones bancarias según tipo de instrumento de pago ................................... 14
Ilustración 4: Ciclo de tecnologías emergentes (Gartner, Octubre 2019) ......................................................... 15
Ilustración 5: Gráfica de transferencia electrónica en línea (TEF) .................................................................... 17
Ilustración 6: Diagrama uso de sistema TEF ..................................................................................................... 29
Ilustración 7: Esquema de la cadena de bloques de blockchain ....................................................................... 30
Ilustración 8: Tabla comparativa de las distintas clasificaciones de blockchain .............................................. 34
Ilustración 9: Infraestructura hiperconvergente ............................................................................................... 41
Ilustración 10: Arquitectura tradicional vs arquitectura virtual ....................................................................... 43
Ilustración 11: Contenedor para máquinas virtuales ....................................................................................... 44
Ilustración 12: Uso medios de pago.................................................................................................................. 48
Ilustración 13: Circulante a PIB ......................................................................................................................... 48
Ilustración 14: Transacciones sin efectivo ........................................................................................................ 49
Ilustración 15: Instrumentos distintos al efectivo ............................................................................................. 50
Ilustración 16: Etapas de metodología cascada del proyecto .......................................................................... 51
Ilustración 17: Fases de procesos PMBOK (Project Management Institute, 2013) ........................................... 52
Ilustración 18: Áreas de conocimiento PMBOK (Project Management Institute, 2013) ................................... 53
Ilustración 19: EDT del proyecto ....................................................................................................................... 54
Ilustración 20: Programación del proyecto....................................................................................................... 55
Ilustración 21: Red infraestructura TEF actual ................................................................................................. 59
Ilustración 22: Diagrama que muestra el flujo transaccional desde un banco a otro. ..................................... 60
Ilustración 23: Ejemplo de modelo activo-pasivo ............................................................................................. 61
Ilustración 24: Diagrama hpe synergy-hyperconvergecia ................................................................................ 62
Ilustración 25: Diagrama de infraestructura actual ......................................................................................... 62
Ilustración 26: Servidor Blade Syn480 HP ......................................................................................................... 63
Ilustración 27: Diagrama de nueva infraestructura ......................................................................................... 64
Ilustración 28: Tipos de blockchain ................................................................................................................... 65
Ilustración 29: Comparación de los principales protocolos de consenso. ......................................................... 66
Ilustración 30: Preparación máquina virtual .................................................................................................... 68
Ilustración 31: Configuración mínima de S.O. .................................................................................................. 69
Ilustración 32: Asignación de espacio en disco ................................................................................................. 69
Ilustración 33: Verificación versión de S.O........................................................................................................ 70
Ilustración 34: Instalación de docker ................................................................................................................ 70
Ilustración 35: Instalación de docker-compose ................................................................................................ 71
Ilustración 36: Instalación de lenguaje GO ....................................................................................................... 71
Ilustración 37: Instalación de NVM y NodeJs .................................................................................................... 72
Ilustración 38: Descarga de imagen Fabric ...................................................................................................... 72
Ilustración 39: Inicio block génesis y red blockchain ........................................................................................ 73
Ilustración 40: Validación servicio web............................................................................................................. 73
Ilustración 41: Navegador con conexión al composer ...................................................................................... 74
Ilustración 42: Conexión a la red en ejecución.................................................................................................. 74
Ilustración 43: Creación de nuevo participante ................................................................................................ 74
Ilustración 44: Creación de registro de prueba ................................................................................................. 75
Ilustración 45: Ejecución de cambio de registro ............................................................................................... 75
Ilustración 46: Validación de transacción ......................................................................................................... 75
6
Ilustración 47: Verificación de transacción ....................................................................................................... 76
Ilustración 48: Simulación de dos instituciones bancarias................................................................................ 76
Ilustración 49: Creación de las dos instituciones .............................................................................................. 77
Ilustración 50: Cambio de parámetro de tipo de orderer ................................................................................. 77
Ilustración 51: Creación de bloque génesis....................................................................................................... 78
Ilustración 52: Validación de existencia del bloque génesis ............................................................................. 78
Ilustración 53: Creación de canal de transacciones .......................................................................................... 78
Ilustración 54: Anclaje de peer a organizaciones ............................................................................................. 78
Ilustración 55: Inicio de contenedores .............................................................................................................. 79
Ilustración 56: Verificación red en ejecución .................................................................................................... 79
Ilustración 57: Verificación ejecución red blockchain ....................................................................................... 79
Ilustración 58: Instanciación prueba de transferencia ..................................................................................... 80
Ilustración 59: Creación canal de ejemplo ........................................................................................................ 80
Ilustración 60: Anclaje de peers a cada organización ....................................................................................... 80
Ilustración 61: Anclaje de las organizaciones ................................................................................................... 81
Ilustración 62: Instanciación de "chaincode".................................................................................................... 81
Ilustración 63: Inicialización de cuentas bancarias ........................................................................................... 81
Ilustración 64: Traspaso de dinero desde cuenta A a la B ................................................................................ 82
Ilustración 65: Transacción por 15mil ............................................................................................................... 82
Ilustración 66: Transacción por 40mil ............................................................................................................... 82
Ilustración 67: Verificación de log de transacciones......................................................................................... 83
Ilustración 68: Detalle de transacciones en el log ............................................................................................ 83
Ilustración 69: Inicio de contenedores en red personalizada ............................................................................ 85
Ilustración 70: Ejemplo de transacción de blockchain ...................................................................................... 87
Ilustración 71: Solución de infraestructura en cruce con Hyperledger Fabric .................................................. 88
Ilustración 70: Tipos de redes blockchain ......................................................................................................... 90
Ilustración 71: Diagrama alto nivel: Propuesta Blockchain Transferencias electrónica de fondos. ................. 93
7
1. INTRODUCCIÓN
1.1. Introducción
En los últimos años de bancarización del mercado chileno se han denotado grandes
cambios, especialmente con la irrupción de Internet de forma transversal en toda la
industria, el crecimiento vertiginoso de la plataforma tecnológica y el rol esencial
que juega el cliente en esta nueva etapa. Este último es el eslabón más difícil de
atraer, pues es un individuo que prácticamente requiere todo al instante y que al
mínimo problema busca una alternativa en la variedad de ofertas que existen en el
mercado.
Las reglas de juego han estado cambiando, prácticamente todos los sectores
financieros han adoptado dichos cambios. En este escenario, las entidades de la
banca han generado y ofrecidos nuevos servicios, nuevas formas que puedan
satisfacer cada una de las necesidades de los clientes, intentan atraer a nuevos y
dar foco a fuga de los existentes. Se han presentado diversos tipos de servicios
hacia el cliente con la finalidad de fidelizarlo, entre los cuales podemos nombrar:
servicios remotos, transacciones al instante, diversas formas de entregar dinero
(Físico o virtual), diversas formas de pago, entre muchos más. De los variados
servicios que la banca ha otorgado a los clientes, podemos resaltar dentro de los
más importantes, los cajeros automáticos (ATM’s), los puntos de ventas (POS) y las
transferencias electrónicas en línea (TEF).
Si bien existen 3 canales principales de movimiento de dinero, este documento se
centrará en uno de ellos: el servicio de transferencia de fondos TEF. Dicho servicio
es entregado por dos compañías denominadas de apoyo al giro: Redbanc y CCA.
Estas cumplen un valor significativo en el procesamiento de las transacciones como
también la seguridad del mismo canal. Son entidades creadas a partir de la
necesidad de las instituciones bancarias de tener una tercera parte que opere en
modalidad de juez en el caso de alguna controversia en relación con las
transacciones efectuadas por el canal TEF. Hoy en día ambas compañías son
contingencia una de la otra para este canal transaccional y cada una por si sola
entrega servicios adicionales a las instituciones.
Con relación a esta dos compañías o también llamados canales transaccionales, es
que se dará foco a una de ellas, pues esta concentra todas las conexiones
interbancarias con las actuales instituciones y las nuevas que deseen unirse, lo cual
es altamente atractivo para la integración de nuevos sistemas para las actuales
instituciones y las nuevas que deseen adheriste. Cabe señalar que el canal TEF
para Redbanc es uno de sus servicios primarios y resulta totalmente atrayente
explotarlo y buscar derivadas con la finalidad de entregar valor agregado a sus
clientes.
8
Para entender en el contexto donde se realizará el análisis, se deben conocer cómo
opera en términos generales una transferencia electrónica de fondos o TEF.
Un cliente de un banco A, cuando quiere transferir a otra cuenta del mismo banco,
esta es procesada de forma interna, sin embargo, cuando el mismo cliente quiere
hacerlo a una cuenta de un banco B, esta debe ser gestionada por una de las
instituciones de apoyo al giro las cuales interconectan a los distintos bancos. Las
transacciones luego de ser adquiridas por un canal (banco) son enviadas hacia
alguno de los switch centrales de la sociedad de apoyo al giro donde son
procesadas por dicha entidad y luego derivadas hacia los distintos emisores
(bancos), dependiendo a quién pertenezca la cuenta destino, por lo tanto uno de los
eslabones más importante de la cadena de las transacciones electrónicas en línea
es el switch central y la seguridad que este le proporciona al modelo.
La cantidad de transacciones varía según el día, la hora, etc. Además, se pueden
observar distintos porcentajes de dedicación de soporte e infraestructura dentro de
la actividad diaria, siendo los peaks el momento donde la cantidad de transacciones
llega al máximo de la curva de actividad.
Hoy en día la entidad en análisis opera de forma frecuente como contingencia de la
otra compañía de apoyo al giro (CCA) para este servicio TEF, por lo cual requiere
realizar un cambio de paradigma para darle valor agregado a las transacciones
procesadas por su switch, entregar una solución escalable e integral y que en
consecuencia otorguen valor a sus clientes directos (Bancos).
1.2. Motivación
Para los años 1950 lo que demoraba un automóvil en pasar por el sector de pits era
67 segundos, esto era encontrado como extraordinario. En los años 2013, este
mismo automóvil demoraba 2,5 segundo y era demasiado.
Esta nueva mirada no solo es en el deporte automovilístico, sino que aplica a
variadas situaciones en la vida. La tecnología es unos de los factores que interviene
de forma directa en esto, ayudando a que los tiempos disminuyan de manera
considerable para todo ámbito de cosas. Lo que nos demorábamos antiguamente
en obtener dinero de nuestra cuenta corriente, yendo al banco en persona, en
comparación a como lo hacemos en la actualidad, obteniéndolo en cualquier cajero
automático, transferencia electrónica e inclusive no necesitando el dinero como
medio de pago efectivo, es una diferencia abismal.
El cliente actual, es un individuo el cual no espera ni da segundas oportunidades,
es por esto que tenemos de poner foco sobre y hacer que la tecnología actué de
forma proactiva en nuestra toma de decisiones y nos ayude a mantenerlo atraído.
La hiperconectividad ha dado al cliente la capacidad de acceso y análisis a la
9
información, de manera instantánea, que ha convertido a éste en un cliente
exigente, con la habilidad de comparar en segundos precios, servicios y, lo que se
está convirtiendo poco a poco en la máxima prioridad, experiencias. Pero esto es
solamente el principio, los avances que llegarán en la próxima década seguirán
distanciando al cliente del proveedor tradicional, y eso no deja de lado, ni mucho
menos, al sector de la banca.
Norman Blackwell, presidente de Lloyd’s Bank, declaró en una ocasión lo siguiente:
“La banca se enfrenta a un cambio más importante en los próximos 10 años de
cualquiera que haya sucedido en los últimos 200” El presidente de una de las
mayores entidades bancarias del mundo es una voz lo suficientemente relevante
como para ser tomada en serio. En nuestro país, también los máximos dirigentes
del Banco Santander o del BBVA están totalmente convencidos, y son los
principales impulsores, que transformar sus instituciones en la línea de la revolución
digital que estamos viviendo será lo que haga tener éxito a las entidades bancarias
en el medio y largo plazo.
Encontramos en The Financial Brand1 un estudio sobre las tecnologías que están
teniendo, y que tendrán, un impacto determinante en el futuro del sector bancario,
y cómo los expertos del sector están considerando estas nuevas influencias sobre
las estrategias venideras. Entre las tendencias que los expertos consideran las de
más impacto sobre la banca podemos destacar la entrada en juego de la inteligencia
artificial y el big data a la hora de relacionarse los bancos con sus clientes, y las
nuevas fórmulas de acceso a internet y a la interconectividad como son los
wearables, incluso yendo un poco más allá, los implantes, y el internet de las cosas.
Dentro de las preguntas importantes que uno debe hacerse es saber cómo cambiará
todo esto el mundo de las finanzas. Y dentro de las conclusiones más inmediatas,
está que la conectividad digital de todos para todo, en cualquier lugar y en cualquier
momento, y la capacidad de analizar y utilizar estos datos en todos los aspectos de
la vida diaria, ofrece oportunidades y desafíos. La forma en que la industria de
servicios financieros responda a estos cambios masivos determinará el éxito de las
instituciones y de la industria en general.
El impacto de la tecnología digital en los servicios financieros en los últimos años
refleja el impacto dramático en la economía en general. Y, mientras que los líderes
de la industria están tratando de determinar las implicaciones de estos cambios y
de prepararse mejor para los desarrollos que están en el horizonte, la mayoría de
nosotros no estamos completamente conscientes de los cambios masivos que se
avecinan. Para brindar una mejor perspectiva, el Foro Económico Mundial realizó
un estudio titulado Deep Shift: Puntos de inflexión tecnológica e impacto social,
basado en las opiniones de 800 expertos y ejecutivos de todo el mundo. Este
informe analiza el momento y el impacto de los 21 "puntos de inflexión" que cambian
1 Sitio especializado en industria bancaria https://thefinancialbrand.com
10
el juego o los momentos en que un cambio tecnológico específico puede afectar a
la sociedad en general. En el estudio, el primer punto de inflexión se predijo para
2018 y el último para 2027.
Ilustración 1: Tecnologías claves
Este estudio posiciona a muchas nuevas tecnologías como tendencias y soluciones

disruptivas para el mundo financiero. Tecnologías como Big Data, IoT, Machine
learning y blockchain, son tendencias que se vienen desarrollando a nivel mundial
en distintos tipos de industrias y por sobre todo en el mundo financiero.
Se muestra que para el año 2027 el Blockchain se encontrara entre las tecnologías
más utilizadas, sin embrago ya en la actualidad existen empresas que se
encuentran en fases de desarrollo y próximas a liberar sus productos con este tipo
de tecnologías.
Es por esto que se hace necesario indagar y informarse acerca de estas nuevas
tecnologías, pues podrían afectar de forma positiva los procesos de la industria
financiera y en consecuencia entregar soluciones más confiables y instantáneas al
usuario final.
Las tecnologías blockchain puede de ser gran valor a la industria financiero, sin
embargo, aún existe desconocimiento y falta de atrevimiento para apostar por este
tipo de tecnologías en el mundo financiero en Chile, más aun que en la mayoría de
los casos sus aplicaciones son soportadas por infraestructura legacy.
11
Según Firmas como Deloitte y medios de comunicación especializados como
Forbes y Bloomberg, la tecnología blockchain entrará en una nueva era en 2019,
revolucionando sectores como la bolsa de valores y el comercio transfronterizo.
Según los resultados de la encuesta más reciente de PwC sobre blockchain, a 2018,
un 32% de las empresas consultadas aseguran encontrarse en etapa de desarrollo
de soluciones basadas en blockchain, mientras que el 10% están ejecutando pilotos
y el 15% afirman que estas soluciones ya han sido implementadas.
El crecimiento de blockchain en las empresas será tal que, de hecho, PwC predice
que para 2020 el 77% de los bancos y otras entidades financieras habrán adoptado
la tecnología blockchain como parte de sus sistemas o procesos.
“Aunque el concepto es simple, traerá ahorros considerables para los bancos. La

tecnología permitirá a los bancos reducir la burocracia excesiva, realizar
transacciones más rápidas a costos más bajos y mejorar su seguridad”, afirma
Ahmed Banafa, investigador de la Universidad de Berkeley y experto en blockchain,
internet de las cosas e inteligencia artificial.
1.2.1. Casos de Éxito2
Aunque tan solo el 15% de las entidades encuestadas por PwC han implementado
soluciones blockchain, muchas instituciones del sector financiero ya están
empezando a invertir en esta tecnología. Entre los casos más exitosos se
encuentran Santander, NASDAQ y We.trade.
SANTANDER
Tras el lanzamiento en abril de 2018 de su servicio de pago ‘One Pay FX’, el primer
servicio de pagos internacionales basado en blockchain, el Banco Santander ha
decidido liquidar definitivamente su compañía de remesas para apostarle a la
expansión de ‘One Pay FX’ a nuevos mercados más allá de España, Reino Unido,
Brasil y Polonia (países en los que actualmente funciona este servicio).
La plataforma ‘One Pay FX’ permite hacer transferencias internacionales entre
particulares de forma más rápida, llegando a su destinatario el mismo día en muchos
casos o al día siguiente. Además, permite a los clientes conocer el importe exacto
que llegará en la moneda del destinatario antes de confirmar la transacción.
2 Referencia desde el sitio: https://blog.cobiscorp.com/blockchain-seguira-revolucionando-sector-

financiero-2019
12
NASDAQ
En 2016 NASDAQ dio a conocer Linq, una solución que permite a las
empresas representar digitalmente la propiedad de acciones utilizando tecnología
basada en blockchain.
En la superficie, Linq funciona como una base de datos, pero su potencial es más
amplio. “El objetivo es introducir interoperabilidad existente en las redes y eliminar
significativamente la fricción en las transferencias de información”, señala Alex
Zinder, Director Global de Desarrollo de Software en NASDAQ.
WE.TRADE
En julio de 2018 los bancos HSBC, Santander, Rabobank, Societe Generale,
Deutsche Bank, UniCredit, Nordea, KBC y Natixis realizaron una alianza para crear
el consorcio We.trade. Se trata de una plataforma de financiamiento que utiliza
contratos inteligentes para “simplificar la financiación para las empresas tanto nivel
nacional como internacional, de modo que las transacciones comerciales puedan
ejecutarse de manera más eficiente y segura”, aseguró Anja Bedford, jefe de
proyectos para la banca de transacciones globales de Deutsche Bank.
Por su parte Roberto Mancone, COO de We.trade, resaltó la flexibilidad de la
plataforma, la cual funciona gracias a la iniciativa de código abierto Hyperledger. “La
plataforma se construyó con capas API (interfaz de programación de aplicaciones),
lo que permite que cada uno de los bancos participantes se incorpore a través de
modelos SaaS, On-premise o Cloud, dependiendo de las capacidades del banco”,
señaló.
Uno de los mayores desafíos para el sector financiero es la transformación digital.
Con la implementación de tecnología blockchain en 2019, las instituciones de este
sector podrán optimizar procesos, ser más eficientes y ofrecer una mejor
experiencia de usuario, dando un paso más en materia de innovación bancaria.
1.2.2. Banca en Chile
En Chile existen diversas instituciones financieras, algunas que son de cara directa
al cliente como lo son los bancos y otras que son de apoyo al giro, las cuales prestan
servicios de apoyo al sector financiero.
El presente informe pondrá foco en una de las empresas de apoyo al giro, nombre
que se mantendrá en reserva, que afecta de forma directa la operación diaria de las
instituciones bancarias y la de los usuarios finales. Esta empresa es la encargada
de entregar a los bancos diversas soluciones tecnológicas que son de apoyo a la
banca, entre de las más importante destaca el servicio de transferencias
electrónicas de fondos TEF.
13
Para tener un orden de magnitud de la cantidad de transacciones que debemos
tener en cuenta y la cantidad de cuentas existentes en Chile, se presenta una tabla
de la Superintendencia de Bancos e instituciones financieras SBIF.
Ilustración 2: Gráfico de tenencia de cuentas transaccionales por país.
La imagen muestra que existe una relación positiva entre indicadores de inclusión
financiera y desarrollo económico del país, utilizando PIB per cápita como proxy de
este último. Según estas estadísticas, las cifras de Chile son comparables a país
con similar nivel de desarrollo.
Como bien se visualiza, la cantidad de cuentas bancarias existentes en Chile nos

presenta un desafío el cual se debe soportar con tecnologías de primera línea y de
vanguardia mundial. Es por esto que se pretende indagar, diseñar y proponer una
solución que se integre con tecnologías blockchain y que permitan escalar y
soportar la demanda del mundo digital financiero.
Ilustración 3: Gráfico de transacciones bancarias según tipo de instrumento de pago
En la imagen la SBIF nos presenta un consolidado de los tipos de transacciones al

año 2019, en este se visualizan los tipos de transacciones y los montos asociados
14
a estas operaciones. Se identifica que las transacciones por transferencia de fondo
representan un 15% del total de transacciones monetarias, ubicándolas como el
tercer medio de pago más utilizado en Chile. Es por esto que el desafío no es menor,
se debe contar con la suficiente tecnología de infraestructura y aplicaciones de
vanguardia para poder soportar tal nivel de transacciones.
1.3. Marco de trabajo
El presente trabajo se basara principalmente en la integración entre las opciones

que nos entregan las nuevas tecnologías de Blockchain y el servicio de
transferencias electrónicas de fondos interbancarias que nos provee la banca en
Chile en la actualidad. No obstante, lo que se busca esencialmente es que esta
integración sea reutilizable a otros procesos del mundo financiero en Chile.
Se pretende utilizar las tecnologías de blockchain para otorgar valor agregado a los
procesos tecnológicos con que cuenta la banca. Entregar seguridad a las diversas
operaciones monetarias, poder integrar distintos tipos de infraestructura de TI y
poder generar transparencia a cualquier proceso que utilice este tipo de tecnologías.
Ilustración 4: Ciclo de tecnologías emergentes (Gartner, Octubre 2019)
15
Para poder posicionar Blockchain dentro de las posibilidades a utilizar, se presenta
un comparativo de las tecnologías emergentes a nivel mundial, dicho grafico es
informado por Gartner (Gartner, 2019).
Por otra parte, es fundamental que basemos el estudio y análisis de este tipo de
tecnologías en el escenario de banca en Chile, en particular de la empresa que
proporciona el sistema de transferencia de fondos interbancaria. Esta institución de
apoyo al giro, es la encargada de proveer diversas aplicaciones que son críticas
para las operaciones entre instituciones financieras. Dentro de sus clientes directos
se encuentran los 12 bancos más importantes del país.
Para este caso de análisis se utilizarán datos y modelos tecnológicos productivos
para adaptar y buscar de mejor forma la integración de Blockchain en el sistema de
transferencias. Se planteará un modelo en un ambiente controlado en donde se
expondrán los resultados de integración indicada.
1.3.1. Dentro de las ventajas que se aprecian en esta decisión se tiene:

➢ Se tendrán datos reales de la empresa de apoyo al giro y serán utilizado solo
en un periodo determinado.
➢ Se podrá generar una alternativa de solución entre un modelo de
infraestructura TI, tecnología Blockchain y el sistema de transferencia de
fondo.
➢ Como se conoce el modelo de operación y de infraestructura, se podrán
entregar las mejores recomendaciones y cambios al modelo.
1.3.2. Dentro de las desventajas vemos:

➢ No se podrá contar con la infraestructura TI para el nuevo modelo, esto
debido a los altos costos de una solución de esta envergadura.
➢ Tipo de tecnología poco utilizada en el mundo financiero. Desconocimiento
técnico de involucrados.
1.3.3. Los alcances que tendrá el proyecto serán:

➢ Se trabajará solo con el modelo de transferencia de fondos y no con otros
sistemas satélites.
➢ Se propondrá e integrará un modelo con tecnología Blockchain al sistema de
transferencia de fondos.
➢ Se ejecutarán pruebas con instituciones ficticias solo para realizar los casos
de usos del modelo.
16
2. IDENTIFICACIÓN DEL PROBLEMA
Esta sección presenta el entorno donde reside el análisis de la problemática, para

luego introducir la identificación del origen y las causas raíz del problema, junto con
las oportunidades de mejora se obtendrán.
2.1. Entorno
Considerando los antecedentes descritos en el capítulo anterior y las capacidades

de la tecnología Blockchain que aún están en búsqueda de casos de uso (Glaser,
2017), se hace evidente que podemos obtener mejoras en ciertas circunstancias
con la ayuda de la tecnología de Blockchain. El escenario se asocia a donde
poseemos una plataforma de transferencia electrónica en línea centralizada y con
múltiples puntos de falla, debido a que no está implementada ninguna tecnología
que apoye esta tarea. Basado en esta identificación será posible encontrar las
oportunidades para corroborar que la tecnología Blockchain es apropiada o no.
Como punto de partida, debemos considerar las transacciones que son procesadas
por cada uno de los bancos conectados a un switch central, de la institución de
apoyo al giro y como se han comportado en periodos anteriores.
A nivel de vista macro, el usuario envía dinero por ciertas circunstancias y en
periodos determinados, estos son adquiridos por los bancos y luego dichas
transacciones son enviadas un switch central (de alguna de las instituciones de
apoyo al giro) y luego enviada al banco destino. Todo lo anterior es parte de la
infraestructura crítica para las instituciones de apoyo al giro, como para el país.
Ilustración 5: Gráfica de transferencia electrónica en línea (TEF)
17
2.2. Modelo Ishikawa
El Diagrama Ishikawa es una herramienta importante que ayuda a la generación de ideas sobre las causas de los
problemas, lo que a su vez sirve como base para encontrar la solución. Un Diagrama de Causa-Efecto es un método gráfico
sencillo para presentar una cadena de causas y efectos, así como clasificar las causas y organizar las relaciones entre las
variables. El diagrama ayuda a conceptualizar en forma sencilla problemáticas de todo tipo, incluyendo las más
complicadas.
18
Una vez que las causas fueron esquematizadas en el diagrama, en las causas del
efecto "Descuadre de transacciones TEF", se encontraron factores como los
siguientes:
2.2.1. En cuanto al Presupuesto:
➢ Este ítem está relacionado con la capacidad de la empresa para poder utilizar
su presupuesto para la renovación tecnológica, lo cual en muchas ocasiones
es limitado o repercute en otras áreas de la empresa. Cada cierto tiempo se
debe pagar por licenciamiento por uso de hardware o renovación de este.
➢ El modelo actual de operación considera maquinas altamente costosas, son
mainframe propietarios de la marca HP que poseen piezas y sistema
operativo hecho a medida y no existe posibilidades de cambios por
alternativos.
Tabla 1: Costos por infraestructura
ITEM VALOR Periodo

2 Servidores mainframe 2.000.000 US 5 año
Adicionales/Repuestos 300.000 US 5 año
2.2.2. En cuanto al Personal:
➢ La contar con servidores propietarios de una marca y cerrados en su código

a nivel de sistema operativo, el poder encontrar personal calificado es
extremadamente difícil, como también entrenarlo. Por consiguiente el
personal que actualmente administra esta infraestructura es costoso, crítico
y escaso.
➢ Capacitar a nuevos administradores, es una acción que toma al menos un
par de años para quedar con la expertiz que se requiere. Además que cada
curso que se imparte involucra dedicación al 100% perdiendo personal en la
operación diaria.
➢ El no contar con personal capacitado afecta de manera proporcional a los
tiempos de resolución de incidentes y limita el rango de acción de mejoras
en el modelo operacional.
19
Tabla 2: Valor estimado de personal actual que administra la infraestructura.
Tipo de incidente Valor

5 Ingenieros especialistas 30 Millones x mes
Cursos Anuales 30 Mil US
2.2.3. En cuanto a la Operación:
➢ Tiempos elevados en la acción de una recuperación de servicio producido

por incidentes. Esto es consecuencia por el modelo actual de recuperación
de incidentes, proceso manual y secuencial. Lo citado genera
indisponibilidad de servicio que se traduce en pérdidas de posibles
transacciones e insatisfacción de clientes.
➢ Proceso de DRP poco automatizado y no documentado. Esto genera
demoras en los tiempos de mantención o recuperación de servicio frente a la
perdida de uno de los SITES activos.
Tabla 3: Tiempo de incidentes por tópico.
Tipo de acción Indisponibilidad por año Ocurrencia

Recuperación por incidente 4 horas aprox por incidente 10 al año
DRP 2 horas aprox 15 al año
2.2.4. En cuanto a la Infraestructura:
➢ Alta complejidad para realizar mantenciones sobre los mainframe por ser
infraestructura de bajo conocimiento, lo que genera poca flexibilidad para
intervenir el sistema, ya sea por mejoras o por indisponibilidad programada
de otros sistemas que conviven con el sistema de transferencias de fondo.
➢ Inconsistencia de datos transaccionales entre ambiente primario y ambiente
de contingencia. La solución actual de infraestructura no se integra en su
totalidad con el sistema TEF.
➢ La solución actual del modelo de infraestructura no cuenta con la suficiente
seguridad para validar los nodos con quien interactúa. En ocasiones los
clientes (instituciones bancarias) reclaman por transacciones que no son
reconocidas por errores propios de su operación.
20
Tabla 4: Solución actual infraestructura e impactos
Solución actual de
Impactos Cantidad
infraestructura
Poca flexibilidad Proyectos aplazados Entre 4 a 6 al año
Horas en trabajos de
Problemas de sincronismo 100 horas al año
consistencias entre sites
10 al año –
Reclamos formales de
TRX erróneas Promedio 2500
clientes
TRX cada reclamo
Gracias al diagrama Ishikawa y sus ramas, pudimos determinar varios problemas a

solucionar, los más importantes y que realmente necesitan una solución de fondo,
son los descritos en la Tabla 3, que se muestra a continuación:
Tabla 5: Problemas
Identificador Problema
Altos costos en inversión por renovación tecnológica de
Problema N1
infraestructura.
Problema N2 Máquinas mainframe altamente complejas.
Problema N3 Baja o nula documentación.
Problema N4 Tiempos elevados de mantención y recuperación ante incidentes.
Problema N5 Inconsistencia de datos entre servidor primario y contingencia.
Problema N6 Reclamos de clientes por transacciones no reconocidas.

Falta de control de nodos que son participes del sistema de
Problema N7
transferencia de fondo
21
3. OBJETIVOS, HIPÓTESIS Y ALCANCE
3.1. Objetivos
Con los antecedentes expuestos en el capítulo anterior, es posible determinar

objetivos tanto general como específicos para el proyecto. De esta forma será
posible evaluar el éxito del trabajo a realizar, además de sentar las expectativas de
las soluciones propuestas.
3.1.1. Objetivo general
El objetivo general del proyecto es proponer y evaluar una solución escalable e

integral que contribuya a modernizar mediante tecnología blockchain las
transferencias electrónicas en línea (TEF) en la banca chilena.
3.1.2. Objetivos específicos
Con el fin de lograr el objetivo general presentado en el punto anterior, se presentan

los siguientes objetivos específicos a través de los cuales se pretende solucionar
cada uno de los problemas presentados en la sección 2.2, que estén dentro del
alcance del proyecto.
➢ Obtener un 98% de confiabilidad de transacciones TEF.
➢ Disminuir en al menos un 5% el costo de infraestructura.
➢ Obtener un 99,7% de disponibilidad del servicio.
3.1.3. Métricas
A continuación, se presentan las métricas consideradas para evaluar el éxito de los

objetivos específicos planteados en sección 3.1.2. Para ello se considera la
nomenclatura según Tabla 3.
Tabla 6: Objetivos específicos
Identificador Objetivo específico

ObjEspN1 Obtener un 98% de confiabilidad de transacciones TEF.
ObjEspN2 Disminuir en al menos un 5% el costo de infraestructura.
ObjEspN3 Obtener un 99,7% de disponibilidad del servicio.
22
Se efectúa la definición mediante las métricas actuales (MA) y la métrica esperada
(ME) por cada uno de los objetivos específicos, el resumen se aprecia en la Tabla
5.
Tabla 7: Métricas
Objetivos Métricas Métricas

Métrica / Unidad
específicos actuales esperadas
ObjEspN1 Confiabilidad / porcentaje 94,5 98
ObjEspN2 Costo infraestructura / UF 86.000 81.700
ObjEspN3 Disponibilidad / porcentaje 99,2 99,7
➢ Objetivo específico N1:

El valor de las métricas actuales se obtiene a partir de la definición de
confiabilidad, la cual se describe acorde a la siguiente expresión:
Tabla 8: Fórmula de porcentaje de confiabilidad
Métrica actual Fórmula

Porcentaje de (((Transacciones totales TEF - Transacciones con error TEF) /
Confiabilidad Transacciones totales TEF) * 100)
Tabla 9: Datos de transacciones TEF durante 2020
Transacciones TEF año 2020

Mes Aprobadas Rechazadas Total
Abr_19 1047860 49291 1097151
May_19 579330 17752 597082
Jun_19 871167 26156 897323
Jul_19 752043 32329 784372
Ago_19 574090 23686 597776
Sep_19 1003228 41698 1044926
Oct_19 732851 28359 761210
Nov_19 1938299 247603 2185902
Dic_19 2048330 95999 2144329
Ene_20 1081109 56525 1137634
Feb_20 967475 39454 1006929
Mar_20 1299868 54253 1354121
Abr_20 676988 30613 707601
Total 13572638 743718 14316356
Porcentaje 94,8 % 5,2 % 100%
23
Del total de transacciones procesadas para canal TEF en el año 2020, se obtuvieron
un promedio mensual de 1.044.049 transacciones, el cual tiene un desglose de
13.572.638 transacciones aprobadas y 743718 transacciones rechazadas.
Para realizar el cálculo de la métrica actual nos basaremos en los datos antes
obtenidos como media del comportamiento transaccional, esto para transacciones
aprobadas como rechazadas.
Con los valores descritos en la Tabla, es posible obtener la métrica actual (MA) para
el objetivo específico N1 (ObjEspN1), considerando las transacciones totales
correspondientes a un mes, equivalentes a 1.044.049 de transacciones y las
transacciones incorrectamente procesadas para el canal TEF son 57.209.
Tabla 10: Resultado de fórmula de porcentaje de confiabilidad
Métrica actual Fórmula MA

Porcentaje de
= (((1044049 – 57209) / 1044049) * 100) = 94,5%
Confiabilidad
Actualmente los gastos operacionales relacionados a la infraestructura crítica

utilizada para las transacciones TEF ascienden a 86 mil UF, en relación a
estos gastos mensuales es que apostamos a reducir los costos de la
manutención en un 5% dicho valor.
La métrica actual (MA) corresponde al valor representado en Tabla. El valor de
la métrica esperada (ME) se define de acuerdo con lo planteado en el objetivo
específico N2, por lo tanto, es: N
Tabla 11: Fórmula de objetivo específico N2
Fórmula
ME ≤ 0,95 * MA
El valor de la métrica actual (MA) se obtiene a partir de la definición de gestión

de disponibilidad declarado por ITIL (Jan van Bon, 2010), la cual describe
disponibilidad acorde a la siguiente expresión:
24
Tabla 12: Fórmula de objetivo específico N3
Métrica actual Fórmula

Porcentaje de (((Tiempo acordado de servicio – Tiempo de inactividad) /
Disponibilidad Tiempo acordado de servicio) * 100)
Con los valores descritos en Tabla, es posible obtener el MA para el objetivo

específico N3, considerando el tiempo acordado de servicio correspondiente a
un año, equivalente a 8760 horas del servicio para el canal TEF.
Tabla 13: Resultado de fórmula de objetivo específico N3
Métrica actual Fórmula MA

Porcentaje de
= (((8760 – 70) / 8760) * 100) = 99,2%
Disponibilidad
3.1.4. Trazabilidad
A continuación, se presenta una matriz de trazabilidad donde aprecian los

problemas que resuelve el éxito de cada uno de los objetivos específicos planteados
en sección 3.1.2. Considerar la nomenclatura planteada en Tabla 3 y Tabla 4.
Tabla 14: Trazabilidad
Problemas
P1 P2 P3 P4 P5 P6 P7
ObjEspN1 X X X X X X
ObjEspN2 X X X X
ObEspN3 X X X X X X
3.2. Hipótesis
Contando con las medidas de seguridad y confiabilidad que prestan los modelos de
Blockchain y su integración con diversas infraestructuras, la hipótesis planteada es
la siguiente:
25
Con la implementación de un sistema Blockchain para atender las transferencias
electrónicas financieras (TEF), será posible aumentar el nivel de servicios de dicho
canal transaccional.
3.3. Alcances del proyecto
En este punto, se presenta el alcance del proyecto, indicando cuales puntos de la

sección 2.2 serán abordados y desarrollados. Adicionalmente se presenta la
limitación y supuestos sobre los cuales se trabajará.
3.3.1. Alcance
El presente análisis solo se enfocará en las transacciones adquiridas por canal TEF
y todas las operaciones relacionadas a este.
Se pretende solo atacar los indicadores que afectan el Uptime del servicio TEF y los
costos asociados a la infraestructura.
El modelo por presentar podrá ser utilizado para las demás redes de adquirencia,
como también puede ser entregado a las demás entidades financieras para que sea
aplicado a sus medios de pagos.
Para el caso de análisis solo utilizaremos los datos contenidos en la compañía
donde se centrará el estudio, por lo cual no se utilizarán fuentes de información
externas.
De los datos procesados, estos serán expuestos a través de herramientas gráficas
de información.
Solo se utilizarán herramientas de Blockchain y de modelamiento de datos.
3.3.2. Limitaciones al alcance
El análisis de los datos solo será realizado a un subconjunto de estos, con una
capacidad de historia de 12 meses.
No se entregará información sensible relacionada al negocio.
El uso de los datos es de índole confidencial por ende la manipulación de los
entregables deben ser tratados como tal.
26
No se contempla la implementación final, tampoco se considera el reemplazo de
software ni programación de nuevos aplicativos.
3.3.3. Supuestos
Se tendrá el acceso a la información necesaria de al menos un año para poder

realizar el análisis de dicha información.
La herramienta Hyperledger fabric 3 se encontrará disponible todo el tiempo que se
desarrolle el proyecto, además de contar con el equipamiento necesario para su
instalación y ejecución.
Se podrá acceder al modelo operacional actual del sistema de la compañía.
3 Herramienta para simulación blockchain
27
4. MARCO TEÓRICO
En este capítulo se definen las bases teóricas que soportan el trabajo realizado en
esta tesis. Se exponen conceptos, definiciones y fórmulas, necesarias para
comprender el desarrollo de la solución.
Como ya se ha explicado, el presente trabajo se basará en el análisis de como la
tecnología blockchain se integra con el mundo financiero en Chile, en específico su
integración con el sistema de transferencias de fondos interbancario, de acuerdo a
esto es que es necesario entender que estamos estudiando.
4.1. Transferencia de fondos
Por transferencias electrónicas de fondos se entienden todas aquellas operaciones

realizadas por medios electrónicos que originen cargos o abonos de dinero en
cuentas, tales como: traspasos automatizados de fondos efectuados por un cliente
de una cuenta a otra; órdenes de pago para abonar cuentas de terceros
(proveedores, empleados, accionistas, etc.); recaudaciones mediante cargos a
cuentas corrientes (impuestos, imposiciones previsionales, servicios, etc.); giros de
dinero mediante cajeros automáticos, etc. En general, comprenden las descritas y
cualquier otra operación que se efectúe por aquellos medios, en que un usuario
habilitado para ello instruye o ejecuta movimientos de dinero en una o más cuentas.4
Por ejemplo, podemos encontrar las siguientes clasificaciones de las transferencias,

si atendemos a criterios geográficos, a través del medio que se cursa la orden de
transferencia o en el tipo de rapidez que le solicitamos a la transmisión de dinero de
una cuenta a otra.
Cómo se clasifican las transferencias
Clasificación geográfica. Dentro de este grupo se atiende al país de destino de los
fondos según la residencia de la cuenta corriente de destino. Con este criterio
podemos encontrar:
• Transferencias nacionales: Tanto el ordenante como el beneficiario se
encuentran en el mismo país.
• Transferencias exteriores: Aquellas en el que el beneficiario se encuentra en
otro país diferente al ordenante.
4 Referencia desde el sitio: https://www.sbif.cl/sbifweb3/internet/archivos/norma_87_1.pdf
28
Para entender en detalle que es una transferencia de fondo, a continuación, se
expone un diagrama de uso del sistema.
Ilustración 6: Diagrama uso de sistema TEF
Básicamente la transferencia consiste en:

• Usuario del banco “A” a través de la plataforma web del banco, dispone
fondos hacia otra cuenta del banco “B”.
• Una vez realizada la acción del cliente del banco “A”, esta orden de
transacción es enviada a la empresa concentradora de transmisiones TEF.
• La empresa TEF se encarga de validar fraudes y consistencias de datos.
• La empresa TEF envía la transacción al Banco “B”.
• El banco “B” libera los fondos en la cuenta del cliente en su banco.
4.2. Blockchain
La cadena de bloques, más conocida por el término en inglés blockchain, es un

registro único, consensuado y distribuido en varios nodos de una red. En el caso de
las criptomonedas, podemos pensarlo como el libro contable donde se registra cada
una de las transacciones.
Su funcionamiento puede resultar complejo de entender si profundizamos en los
detalles internos de su implementación, pero la idea básica es sencilla de seguir.
En cada bloque se almacena:
29
• Una cantidad de registros o transacciones válidas.
• Información referente a ese bloque,
• Su vinculación con el bloque anterior y el bloque siguiente a través del hash
de cada bloque ─ un código único que sería como la huella digital del bloque.
Por lo tanto, cada bloque tiene un lugar específico e inamovible dentro de la cadena,
ya que cada bloque contiene información del hash del bloque anterior. La cadena
completa se guarda en cada nodo de la red que conforma la blockchain, por lo que
se almacena una copia exacta de la cadena en todos los participantes de la red.
A medida que se crean nuevos registros, estos son primeramente verificados y
validados por los nodos de la red y luego añadidos a un nuevo bloque que se enlaza
a la cadena.
Ilustración 7: Esquema de la cadena de bloques de blockchain
4.2.1. ¿Por qué blockchain es tan segura?
Al ser una tecnología distribuida, donde cada nodo de la red almacena una copia
exacta de la cadena, se garantiza la disponibilidad de la información en todo
momento. En caso de que un atacante quisiera provocar una denegación de
servicio, debería anular todos los nodos de la red, ya que basta con que al menos
uno esté operativo para que la información esté disponible.
30
Por otro lado, al ser un registro consensuado, donde todos los nodos contienen la
misma información, resulta casi imposible alterar la misma, asegurando su
integridad. Si un atacante quisiera modificar la información en la cadena de bloques,
debería modificar la cadena completa en al menos el 51% de los nodos.
Por último, dado que cada bloque está matemáticamente vinculado al bloque
siguiente, una vez que se añade uno nuevo a la cadena, el mismo se vuelve
inalterable. Si un bloque se modifica su relación con la cadena se rompe. Es decir,
que toda la información registrada en los bloques es inmutable y perpetua.
De esta forma la tecnología de blockchain nos permite almacenar información que
jamás se podrá perder, modificar o eliminar.
Además, cada nodo de la red utiliza certificados y firmas digitales para verificar la
información y validar las transacciones y los datos almacenados en la blockchain,
lo que permite asegurar la autenticidad de dicha información.
De esta forma, podemos pensar en blockchain como un escribano. Un medio para
certificar y validar cualquier tipo de información. Un registro confiable,
descentralizado, resistente a la manipulación de datos, y donde queda todo
registrado.
En la actualidad estamos acostumbrados a los modelos centralizados. Le damos
toda nuestra información a empresas como Google o Facebook para que la
administren, mandamos todos nuestros mensajes a través de los servidores de
Telegram o WhatsApp para que se ocupen de enviarlos o gastamos fortunas en
escribanos e instituciones para que certifiquen y guarden nuestras escrituras o
documentos importantes.
En blockchain los datos están distribuidos en todos los nodos de la red. Al no haber
un nodo central, todos participan por igual, almacenando y validando toda la
información. Se trata de una herramienta muy potente para comunicarnos y
almacenar información de forma confiable; un modelo descentralizado donde la
información es nuestra, ya que no dependemos de una compañía que brinde el
servicio.5
4.2.2. Tipos de blockchain
Existen 3 tipos de categoría de Blockchain: Públicas, Privadas e Híbridas.
5 Referencia desde el sitio: https://www.welivesecurity.com/la-es/2018/09/04/blockchain-que-es-

como-funciona-y-como-se-esta-usando-en-el-mercado/
31
Blockchain pública
Este fue el primer tipo de blockchain que existió, y se refiere a las blockchains que
se encuentran públicamente accesible desde Internet. Un ejemplo de este tipo de
blockchain son Bitcoin, Ethereum, Dash, Monero o Zcash. Este tipo de blockchain
mantienen abierto al público sus datos, el software y su desarrollo, de forma que
cualquier persona puede revisar, auditar, desarrollar o mejorar los mismos.
Para lograr esto, las blockchain públicas tienen medidas de seguridad que
garantizan que ningún actor malicioso pueda fácilmente alterar el funcionamiento
de esta. Es ahí donde entran en acción la tolerancia a fallas bizantinas en la
programación, protocolos de consenso robustos, protecciones DDoS o contra
ataques de 51% o doble gasto. En pocas palabras, cualquier medida que ayude a
mejorar la seguridad de la red es implementada en la misma. El fin de todo esto es
mantener la red en funcionamiento y preservar su descentralización.
Entre las características de este tipo de redes podemos mencionar:

• Las blockchain públicas permiten que cualquier persona pueda formar parte
de esta. Bien sea como usuario, minero o administrador de un nodo, las
personas pueden acceder a la red y formar parte de ella sin restricción
alguna.
• El funcionamiento de la red es completamente transparente y abierto. Los
datos de la blockchain desde sus inicios están disponibles para todos sin
restricciones. Cualquier persona puede revisar o auditar el funcionamiento
de la red y su software.
• No existen entidades centralizadas. Las redes públicas son completamente
descentralizadas y no existe una autoridad central que regule su
funcionamiento.
• El mantenimiento económico de la blockchain depende del sistema integrado
en la misma. Generalmente este sistema económico depende de la minería
y el cobro de comisiones por cada transacción que se realice dentro de la
red.
Blockchain privada o permisionada
Más tarde, con la evolución de la tecnología blockchain y su expansión, muchas

empresas se vieron interesadas en ella. Esto derivó en el desarrollo de soluciones
blockchain privadas o permisionadas. Este tipo de blockchain generalmente cuenta
con los mismos elementos que una blockchain pública, pero a diferencia de éstas,
32
las blockchain permisionadas dependen de una unidad central que controla todas
las acciones dentro de la misma.
Esta unidad central es la que permite dar acceso a los usuarios, además de
controlar sus funciones y permisos dentro de la blockchain. Generalmente son
opciones de desarrollo de tipo software privativo, aunque también hay desarrollos
de software libre. Uno de los desarrollos de blockchain privadas más importantes
del mundo criptográfico es Hyperledger. Este proyecto iniciado por la Fundación
Linux y varias empresas del sector tecnológico es el mayor ejemplo de blockchain
privada. También podemos mencionar el caso de Corda de R3 o Quorum de
JPMorgan.
• El acceso a la red está restringido a elementos que solo pueden ser
autorizados por la unidad central de control.
• El acceso al libro de transacciones o cualquier otro medio de información
generado por la blockchain es privado.
• El mantenimiento económico de la blockchain depende generalmente de la
empresa que sostenga el proyecto. Con frecuencia, las blockchain privadas
no cuenta con criptomonedas ni se realizan acciones de minería.
Blockchain híbrida o federada
Este tipo de blockchain es una fusión entre las blockchain públicas y las privadas.
Es un intento de aprovechar lo mejor de ambos mundos. En estas blockchain, la
participación en la red es privada. Es decir, el acceso a los recursos de la red es
controlado por una o varias entidades. Sin embargo, el libro de contabilidad es
accesible de forma pública. Esto significa que cualquier persona puede explorar
bloque a bloque todo lo que sucede en dicha blockchain.
Por ejemplo, este tipo de redes blockchain son muy útiles para gobiernos u
organizaciones empresariales que deseen almacenar o compartir datos de forma
segura. Un perfecto caso de uso está sucediendo en el sector sanitario, donde se
empieza a usar blockchain para almacenar los datos de sus líneas de producción
de medicamentos. Los datos almacenados pueden ser revisados por las
autoridades competentes con el fin de controlar la calidad, tanto a nivel de la misma
empresa como de gobierno. El objetivo de la aplicación de este modelo de
blockchain es mantener un alto de nivel de transparencia y confianza.
• El acceso a la red está restringido a elementos que solo pueden ser
autorizados por el resto de las unidades de control.
33
• El acceso al libro de transacciones o cualquier otro medio de información
generado por la blockchain es público.
• No existe minería ni criptomonedas. El consenso de la red se da por otros
medios que aseguran que los datos son correctos.
• Es parcialmente descentralizado lo que conlleva a un mejor nivel de
seguridad y transparencia.6
Tabla comparativa de las distintas clasificaciones de blockchain.
Publico Privados Federados

Bitcoin, Hyperledger, Hyperledger,
Ethereum, Corda, Corda,
Litecoin Quorum Quorum
Cualquiera puede
Si No No
participar
Los participantes actúan,
Si No No
en general, como nodos
Transparencia Si A veces A veces
Unico administrador No Si No
Hay más de un
No No SI
administrador
No hay administradores Si No No
Ningún participante tiene
más derechos que los Si No No
demás
Se puede implementar
Si Si Si
Smart contracts
Existe recompensa por
A veces No No
minado de bloques
Soluciona problema de
Si No A veces
falta de confianza
Seguridad basada en
Si No A veces
protocolos de consenso
Seguridad basada en hash Si A veces A veces
Ilustración 8: Tabla comparativa de las distintas clasificaciones de blockchain
6 Referencia desde el sitio: https://academy.bit2me.com/cuantos-tipos-de-blockchain-hay/
34
4.2.3. Las Redes de Blockchain como Servicio (Blockchain as a Service
– BaaS)
Algunas grandes compañías ofrecen servicios de blockchain en la nube. Algunos

ejemplos son IBM especializada en Hyperledger Fabric, Amazon colaborando con
Digital Currency Group, o Microsoft ofreciendo servicios de R3, Hyperledger Fabric
o Quorum, entre otras. Estos servicios no solo consisten en almacenamiento de
información, en este caso del blockchain, sino que también ofrecen un aumento en
la seguridad, la no necesidad de invertir en hardware y la posibilidad de un entorno
más amigable con el que trabajar, pudiendo crear tu propio canal de blockchain sin
necesidad de programar.7
Algoritmos de consenso.
Elegir el protocolo de consenso correcto es una decisión clave para un proyecto

de blockchain. Estos protocolos permiten a una red de computadoras llegar a un
acuerdo sobre el estado de un registro compartido sin la necesidad de confiar en
terceras partes ni en actores centralizados.
Los algoritmos de consenso buscan asegurarse de que el próximo bloque de

transacciones que sea agregado a la cadena represente “la única versión de la
verdad”. Debe ser diseñado de tal modo que evite que actores maliciosos
introduzcan cambios ilegítimos en el registro.
A continuación, se revisará las diferentes alternativas que han sido propuestas

para la creación de algoritmo de consenso en blockchain.
Proof-of-Work (PoW).
El primer protocolo de consenso fue el Proof-of-Work (prueba de trabajo). Diseñado

para blockchains públicas, fue introducido por Satoshi Nakamoto en el blockchain
de Bitcoin, y luego adoptado por muchas otras criptomonedas.
En el algoritmo de PoW, los mineros ponen sus computadoras a trabajar en resolver
un acertijo criptográfico. Mientras mayor sea la capacidad de cómputo (hashrate) de
un minero, mayor es su probabilidad de resolver el acertijo. El primero que lo
resuelve gana el derecho a poner el siguiente bloque en la cadena, y recibe como
recompensa unos bitcoins recién minados.
7 Referencia desde el sitio: https://blogs.iadb.org/conocimiento-abierto/es/tipos-de-blockchain/
35
La prueba de trabajo fue el primer protocolo de consenso y es el más utilizado
actualmente. Sin embargo, tiene algunas desventajas:
• Consumo de Energía. Debido a la capacidad de cómputo requerida, PoW es
costoso e intensivo en energía. Según el MIT Technology Review, “Se estima
que el Bitcoin consume casi tanta energía anual como toda Nigeria”. Los
cómputos que hacen los mineros para generar los bloques son inútiles.
Aunque esos cómputos garantizan la seguridad de la red, es energía que no
puede aplicarse a otra actividad productiva.
• Vulnerabilidad. El protocolo de PoW puede ser vulnerable a los ataques de
51%. Si mineros deshonestos capturasen el 51% del poder de cómputo de la
red, podrían manipular el blockchain para su propio beneficio. Por ejemplo,
modificando el registro para enviar una misma moneda más de una vez.
Proof-of-Stake.
Los algoritmos de Proof-of-Stake (PoS) fueron diseñados para evitar las

desventajas de PoW — en particular, el alto consumo de energía. PoS, en sus
distintas variedades, es la alternativa más común al PoW. Al igual que PoW, también
fue diseñado para blockchains públicas.
En lugar de mineros gastando energía para recibir una recompensa por minar
bloques, en el PoS los nodos “validadores” deben invertir una cantidad de
criptomoneda.
En vez gastar 5000 dólares en comprar computadoras sofisticadas para ganar una
recompensa de minería, en PoS esos 5000 dólares se gastarían en compra
criptomoneda y usarla como depósito para comprar una cantidad equivalente de
probabilidad de creación de bloques.
El algoritmo de PoS elige de manera aleatoria al validador que agregará el próximo
bloque, entre todos los que depositaron fondos. En este sentido, función como una
lotería: mientras más boletos uno compre, mayores son sus chances de ganar.
Peercoin, Blackcoin y NXT son algunos de los primeros en usar PoS. Ethereum
planea adoptar PoS en el futuro.
Entre los beneficios del PoS se encuentran los siguientes:
• Velocidad. Provee un procesamiento más rápido de transacciones.
• Eficiencia. Consume menos energía.
• Menos hardware. No requiere una computadora potente.
Las desventajas del PoS incluyen:
36
• Vulnerabilidad. Atacar un sistema de PoS requiere invertir dinero para
comprar criptomoneda y depositarla. En PoW, por el contrario, hay que
invertir dinero, pero también tiempo, expertise, hardware, electricidad, etc.
• Concentración de riqueza. Como la tendencia de monedas permite ganar
recompensas, los ricos tienden a recibir más monedas. Y esto tiende a la
concentración de riqueza y del poder dentro de la red.
Delegated Proof-of-Stake (DPoS)
En los algoritmos de consenso de DPoS, los tenedores de monedas usan sus

monedas para elegir delegados, llamados “testigos”. Los testigos son quienes
agregan nuevos bloques a la cadena. Los testigos con mayor cantidad de votos
tienen mayor probabilidad de agregar el próximo bloque.
La diferencia entre el PoS y el DPoS es parecida a la que existe entre la democracia
directa y la democracia representativa.
En PoS normal, cada usuario que tiene monedas puede depositarlas y tener la
chance de ser elegido para agregar el siguiente bloque y ganar monedas a cambio.
En un sistema DPoS, cada usuario que tiene monedas puede votar por delegados.
Además de los beneficios del PoS, el DPoS ofrece dos ventajas:
• Mejor distribución de las recompensas. Los usuarios eligen a los delegados
que les ofrezcan mayores recompensas. Así que los pequeños usuarios (y
no sólo los ricos) pueden ganar recompensas. Esto hace que el DPoS sea
más descentralizado que PoW y PoS.
• Seguridad de voto en tiempo real. Cualquier acción maliciosa de un testigo
puede ser detectada inmediatamente por los votantes, quienes pueden
expulsar al delegado corrupto.
Las desventajas del DPoS son:
• Carteles. Los testigos pueden organizarse en carteles.
• Facilidad de organizar un ataque. Como hay menos gente a cargo de
mantener la red viva, es más fácil organizar un ataque de 51%.
• Potencialmente más centralizado. Aunque el DPoS puede ser más
descentralizado que los otros protocolos, potencialmente puede acabar más
centralizado si hay apatía de los votantes. Sin una cantidad importante de
usuarios comprometidos, el poder puede terminar concentrado en pocas
manos.
37
Leased Proof-of-Stake (LPoS)
Otra variante de PoS es LPoS. Desarrollada por la plataforma WAVES, intenta

resolver el problema de concentración de la riqueza que afecta a PoS. También
busca aumentar la seguridad de la red a través de la inclusión de más participantes.
Para esto, LPoS genera incentivos para que quienes tienen pocas monedas las
alquilen a los nodos.
Los nodos que alquilan las monedas adquieren mayor peso y aumentan sus
probabilidades de agregar el siguiente bloque en la cadena.
Esta recompensa es compartida con los que alquilaron sus monedas al nodo
ganador (esto contrasta con DPoS donde los participantes no necesariamente
reciben una recompensa).
Proof-of-Elapsed-Time (PoET)
Hyperledger Sawtooth, originalmente desarrollada por Intel, utiliza el Proof-of-

Elapsed-Time como algoritmo de consenso.
Un aspecto notable de este algoritmo es que aplica tanto a las blockchains públicas
como a las permisionadas.
Permite a los nodos de una blockchain permisionada alcanzar un consenso, incluso
cuando las partes no se conocen entre sí (en general, las blockchains
permisionadas requieren que los usuarios se conozcan y confíen unos en otros).
PoET es similar a PoW pero sin la desventaja del alto consumo de energía.
Utiliza la computación confiable de Intel para definir aleatoriamente tiempos de
espera para la construcción de bloques.
La forma en que el protocolo elige al nodo que agregará el próximo bloque requiere
mucha menos energía que PoW.
La desventaja, sin embargo, es que este protocolo requiere confiar en los chips de
Intel.
No está alineado con la filosofía de descentralización del blockchain.8
8 Referencia desde el sitio: https://medium.com/astec/entendiendo-los-protocolos-de-consenso-de-

blockchain-4858c71722d2
38
Práctica de la tolerancia a faltas bizantinas (PBFT)
La práctica de la tolerancia a faltas bizantinas en inglés practical byzantine fault

tolerance (PBTC), se centra en el estado de máquina. Replica el sistema, pero
elimina el problema de los generales bizantinos. Ahora, ¿cómo lo hace?
Bueno, el algoritmo asume desde el principio que podría haber posibles fallos en la
red y que algunos nodos independientes pueden tener fallas de funcionamiento en
algún momento.
El algoritmo está diseñado para sistemas de consenso, asíncronos y optimizados
de una forma más eficiente para enfrentarse a todos los problemas.
Además, todos los nodos dentro del sistema se organizan en un orden específico.
Se selecciona un nodo como el principal y otros funcionan como plan de respaldo.
Aunque, todos los nodos dentro del sistema funcionan en armonía y se comunican
entre sí.
El nivel de comunicación es bastante alto, esto se debe a que quieren verificar toda
la información que sea encontrada en la red. Esto elimina el problema de la
información poco confiable.
También, con este nuevo proceso, son capaces de descubrir incluso si uno de los
nodos está comprometido. Todos los nodos llegan a un acuerdo por mayoría de
votos.
Los beneficios del algoritmo de consenso PBFT
El algoritmo de práctica de tolerancia a faltas bizantinas comparte algunos datos

interesantes con nosotros. El modelo fue diseñado principalmente para casos de
uso práctico, y son extremadamente fáciles de implementar. Por lo tanto, PBFT
posee una cierta ventaja sobre todos los otros algoritmos de consenso.
• No hay necesidad de confirmación: Las transacciones en esta red funcionan
un poco diferentes. Puede finalizar una transacción sin ningún tipo de
confirmación, como vemos en el sistema de prueba de trabajo.
Si los nodos concuerdan con un bloque específico, este se finaliza. Esto se
debe al hecho de que todos los nodos auténticos se comunican entre sí al
mismo tiempo y llegan a un entendimiento del bloque especificado.
• Reducción de energía: El nuevo modelo ofrece una buena reducción en el
consumo de energía en comparación con PoW. En PoW, cada bloque
necesita una ronda individual de PoW. Pero, en este modelo no todos los
39
mineros están resolviendo el típico algoritmo de hashing. Es por eso que el
sistema no necesita tanto poder computacional.
Inconvenientes del sistema
A pesar de que PBFT proporcionó muchas ventajas y hechos prometedores, todavía

tiene muchas desventajas. Veamos cuales son:
• Brecha en la comunicación: El factor más importante de este algoritmo es la
comunicación entre los nodos. Cada nodo en la red tiene que asegurarse de
que la información que recopilan sea sólida, pero sucede que los algoritmos
de consenso solo funcionan de manera eficiente para un grupo pequeño de
nodos. Si el grupo de nodos aumenta en gran medida, el sistema puede tener
dificultades para realizar un seguimiento de todos los nodos y no podrá
comunicarse con cada uno de ellos.
• Ataque Sybil: La PBFT es muy vulnerable a los ataques Sybil. En estos
ataques, se pueden manipular un grupo de nodos, y al hacerlo, estos
comprometen toda la red. Esto también empeora mucho más con las redes
más grandes haciendo que la escalabilidad del sistema se reduzca.
Si uno pudiera usar este modelo con otros algoritmos de consenso,
probablemente obtenga un combo sólido y seguro.
Tolerancia a faltas bizantinas simplificada (SBFT)
En la tolerancia a faltas bizantinas simplificada, el sistema trabaja un poco diferente.

Primero, un generador de bloques recopilará todas las transacciones a la vez y las
validará después de agruparlas en un nuevo tipo de bloque.
En términos simples, un bloque recopilará todas las transacciones, las agrupara de
manera correcta en otro bloque y finalmente las validará todas juntas.
El generador aplica ciertas reglas que todos los nodos siguen para validar todas las
transacciones. Después, un firmante de bloques los valida y agrega su propia firma.
Es por eso que, si alguno de los bloques omite incluso una de las llaves, la
transacción será rechazada.
SBFT es para una red privada donde la confidencialidad es la prioridad de la red.
La plataforma fue diseñada de manera que expone información confidencial con
ciertas limitaciones. Es por eso que el sistema utiliza tres tipos de técnicas, como
prueba de conocimiento cero, direcciones de uso único y metadatos cifrados.
40
4.3. Infraestructura hiperconvergente
La infraestructura hiperconvergente (HCI) permite combinar los recursos

informáticos, el almacenamiento y la red en un solo sistema. Esta solución
simplificada utiliza software y servidores x86 para sustituir el hardware caro y
diseñado con fines específicos. Gracias a la infraestructura hiperconvergente, es
posible reducir la complejidad del centro de datos y aumentar su escalabilidad.
Una arquitectura tradicional de tres niveles resulta cara de implementar, su
funcionamiento es complejo y su escalabilidad, difícil. No espere a que la
infraestructura de TI responda a los requisitos de las aplicaciones. Adopte la HCI
sin perder el control, aumentar costes o renunciar a la seguridad.
Ilustración 9: Infraestructura hiperconvergente
4.3.1. ¿Cómo funciona la infraestructura hiperconvergente?

• Todas las funciones esenciales del centro de datos se ejecutan en una
capa de software estrechamente integrada, en lugar de utilizar
hardware diseñado para fines específicos.
• Son tres los componentes de software que conforman una plataforma
hiperconvergente: la virtualización del almacenamiento, la
virtualización de recursos informáticos y la gestión.
• El software de virtualización desvincula y agrupa los recursos
subyacentes, y después los asigna dinámicamente a aplicaciones que
se ejecutan en máquinas virtuales o contenedores.
• La configuración basada en políticas adaptadas a las aplicaciones
elimina la necesidad de utilizar estructuras complejas, como LUN y
volúmenes.
• Las funciones avanzadas de gestión reducen aún más las tareas
manuales y ayudan a automatizar operaciones completas.
41
4.3.2. ¿Qué diferencia hay entre la infraestructura convergente y la
infraestructura hiperconvergente?
Ambas infraestructuras de TI integran los cuatro componentes de un centro

de datos. A diferencia de las soluciones convergentes, que dependen del
hardware para ello, los sistemas hiperconvergentes lo logran por medio de
software. Un centro de datos de infraestructura convergente utiliza casi los
mismos productos que las infraestructuras de TI tradicionales, aunque con
una arquitectura simplificada y una gestión más sencilla.9
4.4. Virtualización
La virtualización consiste en crear una representación basada en software, o virtual,

de una entidad física como, por ejemplo, aplicaciones, servidores, redes y
almacenamiento virtuales. Es la forma más eficaz de reducir los gastos de TI y, a la
vez, aumentar la eficiencia y la agilidad para empresas de cualquier tamaño.
Debido a las limitaciones de los servidores x86, muchas organizaciones de TI se
ven obligadas a implementar múltiples servidores, que funcionan muy por debajo de
su capacidad, a fin de responder a las necesidades actuales de almacenamiento y
procesamiento. Esta situación genera una gran ineficiencia y unos costes operativos
excesivos.
La virtualización utiliza el software para imitar las características del hardware y

crear un sistema informático virtual. Esto permite a las organizaciones de TI ejecutar
más de un sistema virtual, y múltiples sistemas operativos y aplicaciones, en un solo
servidor. Entre las ventajas obtenidas, se incluyen las economías de escala y una
mayor eficiencia.
4.4.1. Definición de las máquinas virtuales
Una máquina virtual es un sistema informático virtual, es decir, un contenedor de

software bien aislado que incluye un sistema operativo y una aplicación. Cada
máquina virtual autónoma es completamente independiente. Si se instalan varias
máquinas virtuales en un mismo ordenador, es posible ejecutar varios sistemas
operativos y aplicaciones en un solo servidor físico o «host».
Una capa ligera de software, llamada «hipervisor», desvincula las máquinas

virtuales del host y asigna recursos informáticos de forma dinámica a cada máquina
virtual según las necesidades.
9 Referencia del sitio: https://www.vmware.com/
42
Ilustración 10: Arquitectura tradicional vs arquitectura virtual
4.4.2. Principales características de las máquinas virtuales

Las máquinas virtuales tienen las siguientes características, que ofrecen varias
ventajas:
Creación de particiones
• Ejecute varios sistemas operativos en una sola máquina física.
• Distribuya los recursos del sistema entre las máquinas virtuales.
Aislamiento
• Permita aislar la seguridad y los fallos en el nivel de hardware.
• Garantice el rendimiento gracias a los controles avanzados de recursos.
Encapsulación
• Guarde el estado completo de una máquina virtual en archivos.
• Transfiera y copie máquinas virtuales con la misma facilidad que si fueran
archivos.
Independencia del hardware
• Suministre o migre cualquier máquina virtual a un servidor físico.10
4.5. Contenedores Docker
Se trata de un proyecto open source pensado para crear contenedores ligeros y

portables para aplicaciones de manera que puedan ejecutarse en cualquier sistema
operativo con Docker instalado.
Esa definición todavía sigue siendo algo confusa, por tanto, para acercarlo más a la
realidad, vamos a pensar en la definición de contenedor.
Se denominan contenedores por su analogía con los contenedores de los barcos,
las características que comparten son muchas: su contenido está aislado, pueden
alojar cualquier objeto, se pueden transportar fácilmente. Los contenedores
10 Referencia del sitio: https://www.vmware.com/
43
revolucionaron el transporte, redujeron el coste, los tiempos de carga y descarga,
los daños en la mercancía… hoy en día el 90% de los envíos se realizan en
contenedores estándar.
Ahora bien, si pensamos en una aplicación software, es sencillo deducir que cada
una de ellas necesita un entorno en el que funcionar: una máquina, un sistema
operativo, con un software específico, unas librerías, etc. Gracias a Docker,
podemos encapsular todas las dependencias de una aplicación en un contenedor,
consiguiendo aislar la aplicación y sus dependencias y por tanto obteniendo una
aplicación más fácil de mover entre servidores, sistemas operativos, localizaciones,
etc.
Por otro lado, esta tecnología se considera virtualización ligera ya que, a diferencia
de las máquinas virtuales tradicionales, los contenedores son objetos que
comparten el kernel de Linux, por tanto, ocupan mucho menos espacio y son mucho
más ligeros de arrancar ya que no tienen que iniciar un sistema operativo completo.
Por este motivo en un mismo servidor se podría alojar cientos de contenedores,
hecho que no ocurre con máquinas virtuales.
Ilustración 11: Contenedor para máquinas virtuales
Como se puede observar en la imagen, un contenedor no contiene un sistema

operativo completo, consiguiendo con ello ser más ligero.11
11 Referencia del sitio: https://www.conasa.es/blog/contenedores-docker/
44
5. ESTUDIO DE MERCADO
5.1. Sistema de transferencia de fondo.
El rol que juega en la actualidad el sistema de transferencia de fondos en la banca

financiera en Chile, es un papel importantísimos para que los clientes de cada banco
puedan efectuar diversos tipos de pagos electrónicos o transferencias de dinero
desde cualquier parte en que se encuentren. Además, el sistema sirve como
plataforma de compensación entre instituciones, permitiendo de esta forma que las
instituciones financieras disminuyan tiempos administrativos entre ellas.
A pesar de que existan otros medios por donde efectuar transferencia de dinero, el
actual sistema de transferencia de fondos sigue siendo la gran apuesta de todas las
instituciones financieras.
Todo parece indicar que el sistema de transferencia de fondos seguirá
desempeñando un papel clave a largo plazo, tanto para los bancos minoristas (aun
con las muchas innovaciones y lanzamientos de productos de tecnología
financiera), como también para los propios consumidores, incluidos los “nativos
digitales”.
5.1.1. Opciones de pagos en efectivo y sin efectivo.
A pesar de las discusiones sobre cómo lograr una “Sociedad sin Efectivo”, el
enfoque de las instituciones financieras debería ser el de permitir la mayor
opción de pagos para sus clientes, sin dejar de persistir en sus esfuerzos por
lograr la inclusión financiera (que seguirá siendo un factor importante en el
futuro próximo).
Y es que además de los muchos estudios e informes que demuestran la
popularidad e importancia que sigue teniendo el dinero en efectivo, hay una
estadística que salta a la vista: Aproximadamente, $ 400,000 USD se retiran
cada segundo en los más de 3,2 billones de cajeros electrónicos que hay
instalados en todo el mundo.
Una cifra cercana al 17% del PIB mundial que resalta, no solo el hecho de
que el efectivo puede coexistir con otros métodos de pago, sino la necesidad
y el deber de los bancos de priorizar la disponibilidad de dinero en efectivo
en sus cajeros automáticos, para garantizar que las personas que aún
dependen de la moneda física (que son millones en todo el mundo) puedan
acceder a ella cuando y donde lo deseen.
45
5.1.2. Un futuro sin efectivo, Suecia ¿así es como será el futuro?
Tan generalizado está el pago con tarjeta y a través de transferencia de

fondos u otros medios de pagos digitales en Suecia, que muchas iglesias lo
aceptan en su colecta de donaciones.
Son casos llamativos en un contexto más generalizado de comercios que

cuelgan carteles de “No aceptamos dinero en efectivo”, oficinas bancarias
que no permiten ingresarlo u obtenerlo… o el tercio de la ciudadanía que dice
que ya no utiliza nunca billetes o monedas.
Y es que solo el 1% del valor de todos los pagos en Suecia se mueve con
efectivo y, en tiendas, únicamente el 20% de las transacciones sigue siendo
con dinero “contante y sonante”. El uso de este se ha reducido a la mitad en
solo 5 años, según el banco central sueco. ¿Cómo ha ocurrido?
El cambio tiene lugar en un país en el que el 97% de la población tiene acceso

a tarjetas, el 85% a servicios de banca por internet y un 61% utiliza ya una
aplicación móvil de pago a comercios y entre particulares, a través de
servicios que fueron pioneros en Europa.
La singularidad sueca no parece haber causado, por ahora, problemas

económicos o sociales. Por el contrario, sucede en un país con más de
50.000 dólares de renta media per cápita y que aparece de forma estable
entre los 10 Estados con menos desigualdad del mundo.12
5.1.3. ¿Puede blockchain cambiar el mundo financiero?
El dinero podría moverse a la velocidad de la luz. Pero no lo hace. Hay que

esperar varios días para poder cobrar un cheque o liquidar una transacción
bursátil. Esto puede cambiar con una nueva tecnología llamada blockchain
(cadena de bloques), que se propone transformar el sector de los servicios
financieros.
Este tipo de tecnología nos permitirá realizar todo tipo de transacciones,
desde operaciones en mercados de renta fija y renta variable hasta procesos
de votación, de forma más rápida, más segura y más barata. No es tan solo
una tecnología disruptiva, sino una tecnología fundacional que podría
revolucionar los distintos sectores y crear nuevas economías. La mayoría de
las grandes instituciones financieras en el mundo ya están experimentando
con blockchain, y algunas incluso han comenzado a adoptar esta nueva
12 Referencia desde el sitio: https://revista-triodos.com/el-pais-que-elimina-dinero-en-efectivo/
46
tecnología, que se está utilizando en algunos mercados de préstamos
garantizados.
La tecnología de la cadena de bloques resulta atractiva para las empresas
financieras porque genera confianza entre las partes cuando se relacionan
de forma directa. Eso es algo imprescindible a la hora de llevar a cabo
transacciones financieras.
Según un reciente estudio realizado de forma conjunta por Accenture y Aon,
blockchain podría reducir en un 30% de media el coste de infraestructuras de
ocho de los diez mayores bancos de inversión del mundo.
Los compradores y vendedores de muchos instrumentos financieros,
incluidos los efectos comerciales, tardan tres días o más en liquidar dichas
transacciones. Blockchain podría eliminar este retraso, permitiendo que los
títulos y los fondos cambiaran de manos de forma inmediata, ya que podría
confirmar al instante que el vendedor tiene el título y el comprador los fondos.
Blockchain no solo es más rápido, sino también más barato. Los
consumidores suelen pagar una comisión por enviar dinero a alguien que
está en otro país. Una nueva empresa ha lanzado una aplicación que permite
que dos personas puedan intercambiar dinero, mediante blockchain y sin
intermediario alguno, por un precio inferior. La mayor parte de las entidades
reguladoras también comienzan a acercarse a esta nueva tecnología, que
podría ofrecerles transparencia y rastreabilidad.
5.2. Medios de pagos.
En Chile, el efectivo sigue siendo el principal medio de pago, lo que se refleja en el

creciente saldo de billetes y monedas en circulación, que ha pasado de 2,4% del
PIB a mediados de la década anterior a 3,5% del PIB, en septiembre de 2017. No
obstante, el dinero electrónico ha tenido una importante penetración, por ejemplo,
en el 2000 las transacciones distintas del circulante en que se usaba las tarjetas de
débito eran inferior a 1% y en junio de 2017 su participación llegó a 35%.
Así, hoy en día, este tipo de tarjeta es el instrumento distinto del efectivo más usado
para realizar transacciones. Sin embargo, en términos de monto de las operaciones,
las transferencias electrónicas ocupan el primer lugar, lo que puede estar explicado
por su seguridad, amplia aceptabilidad y mayor límite para el valor de las
operaciones.
Evolución de los instrumentos de pago en Chile El circulante o dinero en efectivo y
monedas juegan un importante rol en la economía. De acuerdo con los resultados
de la Encuesta Financiera de Hogares del Banco Central de Chile del 2014,
47
prácticamente la totalidad de los hogares encuestados declara utilizar el efectivo
como medio de pago y de manera habitual, 76% lo hace diariamente. Después del
efectivo, el instrumento más usado es la tarjeta de débito, con 65% de los hogares
que indica su uso y casi 50% lo hace de manera diaria o varias veces por semana.
Le siguen las transferencias electrónicas de fondos (TEF), tarjetas de crédito
bancarias y cheques, donde su frecuencia de empleo es más bien mensual u
ocasional, según muestra la Ilustración 7.
Ilustración 12: Uso medios de pago
La situación descrita en el párrafo precedente ha experimentado cambios en las

últimas décadas, con importante sustitución entre los medios de pago. No obstante,
la demanda de circulante sigue siendo creciente, por su uso en transacciones de
bajo valor y de manera presencial. En efecto, el valor del circulante ha aumentado
más rápido que la tasa de crecimiento del PIB desde el 2008, con lo que el stock de
billetes y monedas en circulación ha pasado de 2,4% del PIB antes del 2008 a cifras
en torno a 3,5% en los últimos años, según muestra la Ilustración 8.
Ilustración 13: Circulante a PIB
48
Por su parte, el cheque representaba cerca de 60% de las transacciones distintas
al efectivo en el año 2000, mientras que en junio de 2017 alcanzaba sólo a 6%. Este
cambio se explica por la masificación del resto de los otros instrumentos de pago,
dado que ofrecen más seguridad, comodidad, aceptabilidad y menores costos para
el usuario. Entre ellos, destaca la evolución que han experimentado las tarjetas de
débito y las TEF, las cuales pasaron de una participación casi nula en el año 2000
a representar 35 y 22%, respectivamente, en junio de 2017. En la actualidad, las
tarjetas de débito son el medio de pago distinto al efectivo de mayor utilización, en
un contexto en que, el número de transacciones se ha cuadriplicado en el mismo
período, pasando de 512 millones de transacciones en el 2000 a algo más de 2.200
en junio de 2017, según muestra la Ilustración 9.
Ilustración 14: Transacciones sin efectivo
En lo que respecta al valor de la transacción o ticket promedio, se observa que ha

habido un incremento del valor de la transacción promedio con tarjeta de crédito y
giro de dinero desde cajeros automáticos (ATM), pasando de promedios de
alrededor de $30.000 en el 2002 a valores del orden de $60.000 en junio de 2017,
para cada instrumento. Por su parte, las tarjetas de débito se han mantenido entre
$15.000 y $20.000 en el mismo período (Gráfico 6). A su vez, el monto promedio
del cheque ha permanecido en torno a $2.000.000 en el período analizado, mientras
que las TEF experimentaron un fuerte incremento entre los años 2002 y 2007, para
posteriormente descender y situarse ligeramente por debajo de $2.000.000, en lo
más reciente, según muestra la Ilustración 10.
49
Ilustración 15: Instrumentos distintos al efectivo
5.3. Actualidad en Chile
En Chile solo existen dos compañías que proveen el sistema de transferencia fondo,
estas son dependientes una de la otra, esto por temas regulatorios de la
superintendencia de bancos SBIF que les exige a las empresas de apoyo al giro
mantener una contingencia real ante una posible falla en unos de los sistemas TEF.
Es importante considerar que las transacciones efectuadas por este medio
corresponden principalmente a pagos de sueldos (pagos masivos), transferencias
de altas sumas de dinero entre clientes de distintos bancos, compensación
interbancaria, entre las más importantes.
El sistema en la actualidad es un sistema crítico para la banca en Chile, cualquier

falta en la disponibilidad de este u integridad de sus datos conllevan multas
millonarias a los bancos participes del sistema. Es por esto que se tiene que contar
con un sistema altamente redundante y por consecuente costoso, el cual permita
cumplir la demanda nacional que cada vez va en aumento.
50
6. METODOLOGÍA
Para llevar a cabo el proyecto, es necesario definir ciertas metodologías, las cuales
permiten llevar a cabo las tareas de forma ordenada y controlada.
Para ello se define una metodología de trabajo, que tiene relación con los pasos
que se seguirán para llevar a cabo el proyecto, y una metodología de gestión que
tiene relación con un conjunto de buenas prácticas para gestionar las actividades
del proyecto.
6.1. Metodología de trabajo
Como metodología de trabajo, se define una del tipo tradicional ya que el proyecto
tiene sus requisitos claros y las actividades se realizan de forma secuencial y
ordenada, solo al terminar una etapa se puede continuar con la siguiente, lo que la
hace apropiada para el análisis de la tecnología y la integración del sistema TEF en
una nueva infraestructura. Para aquello se define la metodología de trabajo
cascada.
Ilustración 16: Etapas de metodología cascada del proyecto
51
6.2. Metodología de gestión
Para la metodología de gestión del proyecto, se considera el conjunto de buenas

prácticas que ofrece PMBOK. Las cuales se aplican en la gestión, administración y
dirección de proyecto, donde se identifican 47 procesos, distribuidos en 5 procesos
generales, destacados en Ilustración 15. (Project Management Institute, 2013)
➢ Inicio: Define un nuevo proyecto o fase de este.
➢ Planificación: Concreción y establecimiento de los objetivos.
➢ Ejecución: Desarrollo de las actividades definidas en el proyecto
para lograr los objetivos establecidos.
➢ Control monitorización: Supervisión y evaluación del desempeño del
proyecto.
➢ Cierre: Finaliza el proyecto en su totalidad precisando un grado
de aceptación y satisfacción con los resultados obtenidos.
Ilustración 17: Fases de procesos PMBOK (Project Management Institute, 2013)
En cada uno de estos procesos, intervienen las áreas de conocimiento de PMBOK,

que se aprecian en Ilustración 16.
➢ Gestión de la Integración: Establece los criterios para la correcta gestión,
administración y coordinación de los distintos procesos.
➢ Gestión del Alcance: Define el alcance del proyecto, define todos de los
procesos y actividades.
➢ Gestión del Tiempo: Gestiona el tiempo necesario para la ejecución de cada
uno de los procesos implicados, junto con el control de cumplimiento de este.
➢ Gestión del Costo: Gestiona los costos asociados al proyecto y el control de
estos.
52
➢ Gestión de la Calidad: Determina las políticas de la calidad a las que deben
ser sometidos los resultados.
➢ Gestión de los Recursos Humanos: Gestiona y direcciona los equipos
implicados en el proyecto.
➢ Gestión de la Comunicación: Gestiona las vías y las estrategias de
comunicación entre las distintas estructuras y áreas internas del proyecto.
➢ Gestión del Riesgo: Gestiona y soluciona los riesgos implicados en cada
uno de los procesos.
➢ Gestión de Adquisiciones: Gestiona el proceso de compra de bienes,
estructuras, herramientas o servicios externos a los equipos implicados en el
proyecto.
➢ Gestión de los Interesados: Gestiona la administración de las expectativas
generadas con el proyecto.
Ilustración 18: Áreas de conocimiento PMBOK (Project Management Institute, 2013)
53
6.3. Plan de tesis
Con el fin de establecer las tareas para llevar a cabo el proyecto, junto con las áreas
de conocimiento necesarias para gestionar la satisfactoria realización de este, se
define un esquema de desglose de tareas de acuerdo con las metodologías
definidas, ver Ilustración 16.
Ilustración 19: EDT del proyecto
54
6.3.1. Programación
Luego de definidas las tareas en el esquema EDT, Ilustración 16, se definen los
tiempos para cada una de las actividades, las cuales permiten llevar un control y
seguimiento del avance del proyecto. Estos tiempos se aprecian en la Ilustración 4
e Ilustración 17, donde se desglosan las tareas y sus tiempos en cada una de las
fases de la metodología de trabajo.
Ilustración 20: Programación del proyecto
55
7. DEFINICIÓN DE REQUERIMIENTOS
En esta sección se definen los requerimientos funcionales y no funcionales de la

solución.
7.1. Requerimientos funcionales
Los requerimientos funcionales son declaraciones de los servicios que proveerá el

sistema, adicionalmente considera la manera en que éste último reaccionará a
entradas particulares.
La siguiente tabla detalla la descripción de los requerimientos funcionales (ReqFun):
Tabla 15: Descripción ReqFun
ID Descripción
ReqFun1 Tiempo de recuperación cero
ReqFun2 Integridad: Los datos del sistema solo pueden ser modificados por
entes válidos
ReqFun3 Descentralización: La infraestructura opera des centralizadamente en
dos o más datacenters
ReqFun4 Concurrencia: La solución final puede ser soportada por dos o más
nodos
ReqFun5 Las actualizaciones de los nodos y el sistema serán sin interrupción
de servicios.
La siguiente tabla detalla características de los requerimientos funcionales

(ReqFun):
Tabla 16: Características ReqFun
ID Características
ReqFun1 Los nodos deben ser capaces de soportar la caída de cualquiera de
los nodos del sistema haciendo que su recuperación sea inmediata.
ReqFun2 Los entes de la red son validados y son los únicos que pueden realizar
modificaciones al sistema y dichos cambios son validados por todos
los otros nodos.
ReqFun3 Al tener nodos en distintos datacenters en forma descentralizada se
puede asegurar la continuidad de servicios a pesar de problemas en
un datacenter.
ReqFun4 Al tener una solución soportada por al menos dos nodos se asegura
la continuidad del servicio y validación de las transacciones.
ReqFun5 Dado que la red puede operar sin un nodo, este mismo se puede
actualizar sin afectar la continuidad del servicio.
56
7.2. Requerimientos no funcionales
Los requerimientos no funcionales son los que especifican criterios para evaluar la
operación de un servicio de tecnología de información, en contraste con
los requerimientos funcionales que especifican los comportamientos específicos.
La siguiente tabla detalla la descripción de los requerimientos no funcionales
(ReqNOFun):
Tabla 17: Descripción ReqNOFun
ID Descripción
ReqNOFun1 Escalabilidad
ReqNOFun2 Tolerancia a fallas
ReqNOFun3 Uptime
La siguiente tabla detalla características de los requerimientos no funcionales

(ReqNOFun):
Tabla 18: Características ReqNOFun
ID Características
ReqNOFun1 La escalabilidad es factible de realizar dentro de un mismo nodo,
el cual podrá crecer en hardware o cantidad de máquinas
dispuestas para la atención del servicio. Debido a que la solución
está pensada para entidades bancarias, estas no varían
mayormente. Sin embargo, de igual forma se pueden adicionar
nodos a la solución, es factible obtener un crecimiento de la
solución para adicionar nuevos bancos o entidades.
ReqNOFun2 La solución final será capaz de soportar la caída de un nodo sin
afectar la continuidad del servicio.
ReqNOFun3 Se asegura con este tipo de solución, la continuidad operacional y
de servicios.
7.3. Trazabilidad entre objetivos específicos y requerimientos funcionales
En la siguiente tabla se puede apreciar la matriz de trazabilidad en donde se

contraponen los objetivos específicos y los requerimientos funcionales.
57
Tabla 19: Trazabilidad ObjEsp vs ReqFun
Requerimientos funcionales
ReqFun1 ReqFun2 ReqFun3 ReqFun4 ReqFun5
ObjEspN1 X X X
ObjEspN1 X X X X X
ObjEspN1 X X X X X
58
8. SITUACIÓN ACTUAL Y ALTERNATIVAS DE MEJORA.
Ya se ha dicho previamente lo costoso que es mantener y renovar la actual

infraestructura que soporta el sistema TEF, además de considerar la poca
flexibilidad que posee dicha solución e integración con otras tecnologías. De
acuerdo con esto, lo que se busca principalmente es integrar un sistema de
transferencia electrónica de fondo TEF, implementado con tecnología blockchain en
un entorno escalable, seguro y que permita la integración de futuras nuevas
soluciones y por consecuente una disminución del costo en tecnología.
A continuación, se entrega un contexto del modelo de infraestructura y sistema del
actual sistema TEF.
Ilustración 21: Red infraestructura TEF actual
En la imagen se muestra el actual modelo de operación del sistema, en donde se

presenta un nodo principal encargado de comunicar un banco con otro para realizar
el movimiento de dinero, todo esto en un modelo de operación centralizado.
59
Todos los bancos o instituciones financieras que deseen utilizar el sistema TEF
deben ser partícipes del modelo presentando, el cual además de enviar dineros de
un banco a otro, genera compensaciones bancarias al fin del día. Dichas
compensaciones permiten a los bancos validarse en cuanto a todos los fondos
transmitidos y recibidos. Este proceso es sumamente importante para mantener la
consistencia de los montos transmitidos. Si algún banco llegase a reportar una
controversia con otro banco, es el nodo principal del servicio el encargado de dirimir
la problemática.
Ilustración 22: Diagrama que muestra el flujo transaccional desde un banco a otro.
Como se mencionó anteriormente, el servicio TEF es responsable de recibir, validar

y enviar el mensaje a destino, para esto la infraestructura debe estar siempre
disponible, pues si falla el nodo principal, perjudica a todo el modelo. Cualquier
incumplimiento al uptime acordado del servicio, es penalizado por la SBIF.
Es por esto que la empresa cuenta con servidores full tolerance, capaces de seguir
operando, aunque un dispositivo de estas falle.
La modalidad de operación de la infraestructura TEF es Activo – Pasivo, esto quiere
decir, servicios activos en un datacenter son replicados hacia el datacenter pasivo.
La réplica de datos de un datacenter a otro, se encuentra limitado por el medio de
comunicación y el software de réplica utilizado.
Tanto el sistema operativo como los servidores de la actual solución son un sistema
cerrado propietario de HPe (Mainframe). Por consiguiente, es altamente complejo
operar e integrar nuevas soluciones en estas máquinas. Cabe señalar que el actual
sistema de TEF está desarrollado a medida para operar sobre este tipo de
mainframe.
60
A continuación, se presenta el modelo Activo-Pasivo.
Ilustración 23: Ejemplo de modelo activo-pasivo
Estas dos máquinas conforman el modelo actual de infraestructura de TEF,

operando siempre con una maquina principal y la otra en modo de contingencia. El
DRP asociado a este servicio tiene una duración de aproximadamente de 90
minutos. Tanto la caída de servicio o un DRP programado afecta de forma directa
la disponibilidad de servicio, el cual está asociado directamente con el uptime
comprometido con la SBIF.
8.1. Solución de infraestructura
Básicamente la propuesta a nivel de infraestructura pretende integrar tecnología ya

presente en la compañía, buscando aprovechar los recursos disponibles, reducir
costos en mainframe y tener la capacidad de integrar cualquier tipo de tecnología
sin que el medio no lo permita.
Actualmente se cuenta con un modelo de infraestructura con características
hiperconvergentes. Básicamente nos referimos al empleo de un conjunto de
soluciones que, gracias al uso de determinadas herramientas se presenta como si
se tratara de una única solución, con gestión unificada e interacciones entre sus
componentes.
61
Ilustración 24: Diagrama hpe synergy-hyperconvergecia13
Esta infraestructura en la actualidad presenta un uso del 30% de utilización de

recursos, con la posibilidad de aumentar en hardware y potenciar así aún más su
disponibilidad. Actualmente se encuentran operando servicios de alta criticidad
como lo son: sistemas de bloqueos de tarjetas, sistemas de fraudes y sistemas de
monitoreo.
8.2. Diagrama de Infraestructura actual
Ilustración 25: Diagrama de infraestructura actual
13Referencia desde el sitio: https://assets.ext.hpe.com/is/content/hpedam/documents/4aa5-3000-

3999/4aa5-3811/4aa5-3811spl.pdf
62
Si bien existe un porcentaje considerable de no utilización de la infraestructura
propuesta 70%, este análisis considera la cubicación de una red blockchain en alta
disponibilidad, por cual se tiene que considerar la compra de infraestructura y
licencia. A continuación, se detalla lo necesario.
Tabla 20: Valores infraestructura y licencias solución.
ITEM Cantidad
Servidor Blade Syn480 2
Licencias vSphere 4
Licencias RHEL DC 2
Licencias Veeam BKP 4
Costo implementación 1
Implementación SW 1
De lo requerido, a continuación, su explicación.

• Servidor Blade Syn480: Se debe integrar en cada enclosure Synergy para
ambos datacenter, un Blade de estas características. Sus prestaciones son
las mismas de los actuales en operación.
• Licencias vShere: Son requeridas para integrar el cluster de nodos ESX de
la solución. Las licencias son 4 pues cada máquina posee 2 cores físicos.
• Licencias RHEL Datacenter: Son licencias para que en cada nuevo servidor
físico se puedan desplegar máquinas virtuales con sistema operativo Redhat.
Esta licencia permite instalar cuantas máquinas virtuales soporte el servidor
físico.
• Licencias Veeam BKP: Son requeridas para integrar los nuevos nodos ESX
a la plataforma de respaldo existente. Su licenciamiento es por core físico de
cada nuevo server.
• Costo de implementación: Esta relacionados a las horas hombre en la
implementación de los nuevos nodos al ambiente. Contempla grupo técnico
y grupo gestor.
Ilustración 26: Servidor Blade Syn480 HP
63
8.3. Diagrama de Nueva Infraestructura
Ilustración 27: Diagrama de nueva infraestructura
Se pretende conformar 4 máquinas virtuales por cada nuevo servidor físico, con un
total de 8 máquinas virtuales. Estas máquinas estarán en modalidad activo-activo,
esto con el fin de tender los más posible a 0 el tiempo de recuperación del servicio
y por consecuencia aumentar el uptime comprometido.
Como medida de seguridad y con el fin de asegurar la caída de uno de los dos sites,
las maquinas físicas en su conjunto, no deben superar el 45% de utilización, esto
para lograr soportar todas las máquinas virtuales del site con problemas. Con esto
se logra soportar un 90% de utilización en tan solo un datacenter.
8.4. Solución de software.
Como ya se ha dicho, se busca analizar e implementar una solución de tecnología

blockchain que reemplace y potencia el actual servicio de transferencia electrónica
de fondos. Para lo cual, se debe definir qué tipo de blockchain se debe utilizar con
relación al entorno y servicio prestado. En el mundo del blockchain se tienen 3 tipos
de redes: las redes públicas, redes privadas y por ultimo las redes de tipo consorcio
o federada. A continuación, tabla comparativa de las redes como posible solución.
64
Ilustración 28: Tipos de blockchain
Con relación al ecosistema presentado, en donde se tienen múltiples

organizaciones financieras, el tipo de red que más se acomoda a esta situación, es
la red de tipo consorcio o federada. Esta determinación viene principalmente a que
se requiere la comunicación entre muchas entidades y el control de solo una, quien
determina quien es participe o no de la red. Otro beneficio que presenta esta
selección es que tenemos un modelo descentralizado, el cual permite seguir
operando, aunque algunos de los nodos no se encuentren disponible en la red. El
hecho de que se puedan seleccionar los nodos y otorgar que permisos puedan
tener, nos proporciona control sobre el sistema, permitiendo mantener la velocidad
transaccional adecuada al tipo de servicio ofrecido, siendo una solución ágil, rápida
y por supuesto segura.
Con respecto a las redes públicas, estas se descartan esencialmente porque
cualquier nodo puede escribir en la red y participar del consenso de las
transacciones. La red de tipo privada puede encajar en el modelo, pero solo para
procesos internos de la compañía, como lo son sistemas de fraude y bloqueos.
8.5. Tipo de software
Ya seleccionada la modalidad en que operara nuestra red blockchain, se debe

evaluar qué tipos de software nos permitirá implementar una red de tipo consorcio
y que cumpla con los requisitos mínimos que el negocio requiere, los cuales son:
disponibilidad, seguridad e integridad de la información. El tipo de software a utilizar
viene directamente relacionado con el protocolo de consenso que utiliza la solución,
esto determinara que tan eficiente resulte ser. Es por esto que se presenta la
siguiente evaluación del tipo de protocolo a utilizar.
65
Ilustración 29: Comparación de los principales protocolos de consenso.14
En relación con el tipo de protocolo de consenso a utilizar, descartamos de partida

los algoritmos que son de tipo públicos, pues no encajan con el tipo de solución
requerida. En lo que respecta a los protocolos de tipo restrictivos (PBFT y Ripple),
estos son los que encajan en solución propuesta, sin embargo, PBFT cumple más
las expectativas, pues posee un porcentaje más elevado en la tolerancia a fallos.
Cabe destacar que en la solución propuesta solo participaran las actuales
instituciones financieras que son parte del modelo TEF, las cuales no superan los
13 nodos. Por consecuente la propiedad de escalabilidad no es un punto relevante
por la baja cantidad de nodos que participaran en la red.
Ya determinado el tipo de red Blockchain y su protocolo de consenso más apropiado

para el modelo propuesto, se ha escogido el software Hyperledger Fabric por
contener las características antes descritas. Cabe señalar que el software
seleccionado es un proyecto de blockchain empresarial de código abierto. Además,
como cualquier otra red blockchain, viene con contratos inteligentes, registros y
protocolos que ayudan a los participantes a administrar todas sus transacciones.
Hyperledger Fabric tiene algunas diferencias con las plataformas típicas de

blockchain. Una de ellas es el hecho de que está autorizada y es una red privada.
Por lo tanto, en lugar de permitir que participantes desconocidos ingresen a un
sistema, crea una función de membresía y permite a los que están autorizados.
De acuerdo con lo planteado, se determina que la solución de software seleccionada

es apropiada para ser implementada en el nuevo modelo de infraestructura. Para
14Referencia desde el sitio: https://www.sciencedirect.com/science/article/pii/S240595951930164X
66
temas académicos se implementará una red Blockchain con el software descrito
sobre máquinas virtuales que simulen nodos equivalentes a las instituciones
financieras.
67
9. PRERREQUISITOS Y DESPLIEGUE DE LA SOLUCIÓN.
Antes de comenzar con el despliegue de la red Blockchain sobre Hyperledger

Fabric, se debe preparar el ambiente donde se ejecutará la instalación y las pruebas
de la solución propuesta.
En este caso se utilizará la herramienta de virtualización Oracle VirtualBox 6.1, en
este hypervisor se creará una máquina virtual con las siguientes características,
estos son los requerimientos mínimos de instalación.
9.1. Instalación de medios.
Como software que permita virtualizar máquinas virtuales, se utilizara el software

gratuito Oracle VirtualBox 6.1. Para ambiente productivo se mantendrá el hypervisor
de VMWare 6.1.
Descargar la imagen de sistema operativo a virtualizar
(https://releases.ubuntu.com/18.04/), para efectos didácticos se utilizará la imagen
de SO ubuntu-18.04-desktop-amd64. En producción se recomienda utilizar un SO
con soporte de marca, por ejemplo, Redhat enterprise.
El detalle de la máquina virtual a crear sobre virtualbox es el siguiente:
• 2 vCPU.
• 2048 MB vRAM.
• Disco duro 40 GB.
• Tarjeta de red en modalidad “Red NAT”.
• Arquitectura 64 bit.
Ilustración 30: Preparación máquina virtual
68
La instalación del sistema operativo debe contener los softwares mínimos para no
recargar la máquina con paquetes o servicios innecesarios. Se debe instalar en
modalidad mínima.
Ilustración 31: Configuración mínima de S.O.
En relación con las particiones de disco, se recomienda establecer de la siguiente

forma:
• Partición de arranque: /boot, 1000 MB.
• Partición de área de intercambio: SWAP, 4096 MB.
• Partición de binarios y SO: /, el resto de la asignación de disco.
Ilustración 32: Asignación de espacio en disco
69
Una vez finalizada la instalación de nuestra máquina virtual, se procederá a realizar
la instalación y preparación de los prerrequisitos para el soporte de hyperledger
fabric.
9.2. Instalación de prerrequisitos.
Iniciamos la máquina virtual, nos autenticamos con el usuario creado, para este
ejemplo será el usuario “blockchain01”. Una vez dentro del ambiente se comprueba
que la versión instalada es la Ubuntu 18.04.4 LTS Bionic.
Ilustración 33: Verificación versión de S.O.
9.2.1. Instalación de Docker
Antes de comenzar la instalación, se actualiza el sistema operativo, para luego

comenzar el despliegue de Docker. Se instalará esta componente con la finalidad
de montar nuestras imágenes de hyperledger en modalidad contenedor.
Ilustración 34: Instalación de docker
70
9.2.2. Instalación Docker-Compose
Se integra Docker-compose para organizar de forma más sencilla los procesos de

los contenedores de Docker.
Ilustración 35: Instalación de docker-compose
9.2.3. Instalación de lenguaje GO.
Se realiza la descarga de paquete go y se despliega en el SO. Se estable como

variable de ambiente para que sea reconocido por el usuario dueño de la instalación.
Ilustración 36: Instalación de lenguaje GO
9.2.4. Instalación de NVM y NodeJs
Se realiza la instalación de NVM, el cual nos permitirá controlar e instalar las

diferentes versiones de componentes que se requieran. Junto con nvm se realiza la
instalación de node, requerido para el entorno de JavaScript.
71
Ilustración 37: Instalación de NVM y NodeJs
9.2.5. Descarga de imagen Fabric.
Se realiza la descarga de imágenes de la versión fabric 1.2.0 para el despliegue

sobre contenedores Docker. Adicionalmente, se realiza la instalación de composer,
el cual permitirá levantar la consola gráfica que mostrará de modo simple la red
blockchain.
Ilustración 38: Descarga de imagen Fabric
9.3. Despliegue de una red blockchain básica.
Ya instalados los componentes necesarios, se verifica que no existan contenedores

en ejecución con el comando “Docker ps -a”. Nos situamos en el directorio de fabric/-
sample/basic-network y procedemos a levantar los contenedores fabric “nohup
./start.sh &”.
72
Luego se verifica que los contenedores estén en ejecución “docker ps -a”. De forma
posterior se inicializa el block génesis y la red blockchain con el scripts
“./generate.sh”
Ilustración 39: Inicio block génesis y red blockchain
Se procede a levantar la consola composer con el comando “composer-playground

&”. Este comando se puede ejecutar desde cualquier PATH. La ejecución devuelve
que el servicio web se encuentra en ejecución en el puerto 8080.
Ilustración 40: Validación servicio web
9.3.1. Conexión a composer
Se realiza la conexión al composer por medio de un navegador en el cual

ingresamos la ruta local, además del puerto asignado, en este caso 8080 de la
siguiente manera: “http://localhost:8080”
73
Ilustración 41: Navegador con conexión al composer
9.3.2. Prueba de transacción blockchain
Se realiza la conexión a la red en ejecución “basic-sample-network”.
Ilustración 42: Conexión a la red en ejecución
Se crea un nuevo participante, en este caso se crea “Fabian Bruna”
Ilustración 43: Creación de nuevo participante
74
Se genera un registro de prueba llamado “prueba_tesis”
Ilustración 44: Creación de registro de prueba
Se ejecuta la petición de cambio de registro con una nueva transacción, en este

caso se pasa el valor “Cambio_exitoso”.
Ilustración 45: Ejecución de cambio de registro
Se procede a enviar la transacción, la cual es validada por el sistema.
Ilustración 46: Validación de transacción
75
Se verifica el trakking de la transacción en donde pasa del valor “prueba_tesis” al
nuevo valor “Cambio_exitoso”.
Ilustración 47: Verificación de transacción
9.4. Construcción de una red blockchain multi-organizacional.
Para poder construir una red con más de un solo nodo, hay que dirigirse al directorio
~/Fabric/fabric-samples/first-network de nuestra instalación de Hyperledger Fabric.
Este directorio encontraremos templates (plantillas) y binarios que permitirán crear
una red multi-organizacional.
El ejemplo simulará la creación de dos instituciones bancarias pertenecientes a una
misma red de blockchain. Siendo una institución “Org1” y la otra “Org2”.
Ilustración 48: Simulación de dos instituciones bancarias
Para comenzar con la creación de la red, lo primero es generar los certificados

correspondientes a las entidades que serán participes. Se crearán certificados
76
representativos para cada entidad, los cuales permitirán la autenticación y
seguridad en la red. Para generar los certificados se utilizará el binario “cryptogen”,
al cual se le pasará como argumento el archivo “crypto-config.yaml”. Este último
contiene la definición de los integrantes de nuestra red.
Ilustración 49: Creación de las dos instituciones
En la imagen anterior, se visualiza como se crean las dos organizaciones

pertenecientes a un mismo dominio. Además, se crea el directorio “crypto-config”,
el cual contiene los certificados de las entidades de nuestra red.
Antes de seguir la creación, se debe cambiar un valor sumamente importante dentro

de nuestra red. Esto definirá que tan escalable y tolerante a fallos será nuestra red
blockchain.
Ilustración 50: Cambio de parámetro de tipo de orderer
Se cambia del valor “solo” al valor” Kafka” en el tipo de orderer a crear.
77
Si se establece el valor en “solo”, la red ante alguna caída del nodo orderer no podrá
seguir operando.
Ilustración 51: Creación de bloque génesis
Ahora se procede a crear el bloque génesis, este será nuestro primer bloque en
nuestra red.
Se utilizará el binario “configtxgen”, al cual se le indica dónde generar la salida, esto
en el directorio “./channel-artifacts/”, allí se creará el “genesis.block”
Ilustración 52: Validación de existencia del bloque génesis
Se realiza la validación de la existencia en la ruta antes señalada.
Ilustración 53: Creación de canal de transacciones
Posterior a la creación del primer bloque, se procede a crear el canal de

transacciones, para ello se utiliza el binario “configtxgen”. Este creará el canal con
el nombre que se estableció en la variable CHANNEL_NAME, para este caso
denominado “mychannel”
Ilustración 54: Anclaje de peer a organizaciones
Luego de la creación del canal, se procede al anclaje de los peer de las

organizaciones definidas (en archivo configtx.yaml).
78
Ilustración 55: Inicio de contenedores
Una vez ya enlazados las componentes de la red. Se procede a iniciar los distintos
contenedores a través de composer, que en este caso representan a los nodos de
nuestra red blockchain.
Ilustración 56: Verificación red en ejecución
Para verificar que nuestra red se encuentre en ejecución, corroboramos con el

comando “Docker ps -a”.
9.4.1. Caso de uso: Transferencia electronica de fondo entre cuentas.
Para comenzar el proceso de transferencia, antes se debe verificar la correcta

operación de nuestros contenedores. En este caso, simulan a organizaciones
financieras distintas, siendo Org1 el Banco A y Org2 el Banco B.
Ilustración 57: Verificación ejecución red blockchain
79
Corroboramos que la red blockchain se encuentre en ejecución, esto con el
comando “docker ps -a”.
Ilustración 58: Instanciación prueba de transferencia
Para instanciar nuestra prueba de transferencia, se debe ingresar al contendor “CLI”

en donde se inicializará los peers de cada organización. Ingresar con el comando
“docker exec -it cli bash”.
Ilustración 59: Creación canal de ejemplo
Una vez dentro del contenedor, se procede a crear el canal de ejemplo. Para este
caso se crea el canal “mychannel”, en donde se le especifica el nodo orderer que
usará, además de indicar que la transmisión estará cifrada en TLS.
Ilustración 60: Anclaje de peers a cada organización
80
Ya creado el canal, se anclan los peers de cada organización. Para esto se deben
declarar las variables de entorno correspondientes a cada organización, puesto que
cada uno se valida hacia la red con su certificado único creado (Instancia de
creación de la red, punto XX). Con esto, la red valida que los participantes son
válidos en su entorno.
Ilustración 61: Anclaje de las organizaciones
Luego se deben anclan las organizaciones, peer0.org1.example.com:7051 y

peer0.org2.example.com:7051.
Ilustración 62: Instanciación de "chaincode"
Se debe instanciar el chaincode, al cual denominaremos “TRANSACCION_TEF”.
Ilustración 63: Inicialización de cuentas bancarias
Posterior a la instanciación del chaincode, se inicializan las cuentas bancarias

(Ficticias) a operar.
81
Para este caso, se crea:
• Cuenta A con un saldo de 200000.
• Cuenta B con un saldo de 300000.
Ilustración 64: Traspaso de dinero desde cuenta A a la B
Se procede a generar la invocación de la primera transacción, se realiza el traspaso

de dinero desde la cuenta A hacia la cuenta B, esto por un monto de 25000.
Luego se verifican nuevamente los saldos, en donde:
• Cuenta A queda con 175000.
• Cuenta B queda con 325000.
Ilustración 65: Transacción por 15mil
Se vuelve a generar otra transacción, se realiza el traspaso de dinero por el monto

de 15000.
Luego se verifican nuevamente los saldos, en donde:
Ilustración 66: Transacción por 40mil
82
Por último, la cuenta B le traspasa a la cuenta A un monto de 40000.
Quedando los saldos en:
Ilustración 67: Verificación de log de transacciones
Para poder visualizar que las transacciones fueron validadas y aprobadas por
ambos nodos, se verifica en el log de cada contenedor correspondiente a las
organizaciones.
Se observan 4 transacciones hacia la red, el detalle es:
- Instanciación de las cuentas con los saldos iniciales.
- Primera transferencia desde cuenta A hacia la cuenta B.
- Segunda transferencia desde cuenta A hacia la cuenta B.
- Tercera transferencia desde cuenta B hacia la cuenta A.
Ilustración 68: Detalle de transacciones en el log
Para poder visualizar la secuencia de las transacciones, se debe aplicar el comando

“Docker logs ID del contenedor”. En este caso es el contendor que se creó a partir
de la prueba de caso de uso.
83
9.4.2. Personalización de integrantes de la red
Para personalizar en mayor medida los integrantes de nuestra red, se deben

modificar los archivos de creación de nodos. Estos archivos se establecen IPs,
cantidad de peers, nodos, modalidad de la red y permisos.
Los archivos por modificar son:

• configtx.yaml
• docker-compose-cli.yaml
• docker-compose-base.yaml
• docker-compose-e2e-template.yaml
• docker-compose-couch.yaml
Como ejemplo, se modifican los siguientes valores.
• Nombre de la red: tef
• Nombre del dominio: tesis.cl
• Nombre de organización 1: Banco_1
• Nombre de organización 2: Banco_2
El cambio de nombre se realiza a través del comando “sed”.
Posterior a realzar todos los cambios en los archivos, se procede a repetir los pasos
de creación de la red, se deben cambiar los valores en los argumentos a ejecutar.
• ../bin/cryptogen generate --config=./crypto-config.yaml
• export FABRIC_CFG_PATH=$PWD
• ../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-
artifacts/genesis.block
• export CHANNEL_NAME=TEF
• ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx
./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
• ../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate
./channel-artifacts/Banco_1_MSPanchors.tx -channelID $CHANNEL_NAME
-asOrg Banco_1_MSP
• ../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate
./channel-artifacts/Banco_2_MSPanchors.tx -channelID $CHANNEL_NAME
-asOrg Banco_2_MSP
84
Ilustración 69: Inicio de contenedores en red personalizada
Luego de la creación, se realiza la partida de los distintos contenedores. En esta

ocasión con entidades personalizadas.
85
10. CRUCE Y VALIDACIÓN DE OBJETIVOS DEL PROYECTO.
Posterior al despliegue del ambiente y la ejecución de las pruebas, se ha podido

visualizar como es el comportamiento de una red blockchain implementada con
Hyperledger fabric, desde cuando es constituida por solo una organización y cuando
es compuesta por dos o más organizaciones participes de esta. Cabe señalar que
fabric se cumple en su esencia, pues su arquitectura fue concebida para ejecutarse
sobre ambientes distribuidos, que es donde mejor provecho adquiere.
En cuanto a su despliegue, se logró apreciar:
• Una red restrictiva a nivel de permisos.
• Transacciones confidenciales (privadas).
• Es programable mediante sus chaincodes, instanciación de transacciones.
• Trafico a través de protocolo seguro TLS.
• Distribución de nodos en contenedores independientes.
También fue posible determinar que cada nueva transacción gatillada hacia la red
es validad por todos los nodos que la constituyen, manteniendo la consistencia de
la secuencia de los datos presentados y el cifrado de estos. Además, se logró
presentar una solución desplegada sobre tecnología de contenedores, lo cual
permite lograr un modelo flexible y escalable en cuanto a la infraestructura de TI.
10.1. Validaciones de objetivos específicos.
10.1.1. Obtener una confiabilidad del 98%.
De acuerdo con las pruebas de consistencia y validación de datos, se logra

determinar que cuando una transacción es ejecutada sobre una red blockchain, esta
mantiene su integridad e inmutabilidad, entregando al sistema una confiabilidad de
los datos del 99%, sin desmedro del performance de la red. Esto radica
esencialmente a que es un sistema permisionado, todos los miembros de la red
tienen que ser conocidos y contar con un certificado valido para la red.
Según la prueba presentada en el caso de uso punto 9.4.1, se logra evidenciar como
una transacción es gatillada hacia toda la red blockchain, siendo esta validada por
los nodos participes (Peers de las organizaciones Org1 y Org2), para luego añadir
la transacción al bloque previo existente (Actualización de saldos de cuenta) y por
último actualizar el saldo en ambas cuentas. En el diagrama que se presenta a
continuación se visualizan los hitos indicados.
86
Ilustración 70: Ejemplo de transacción de blockchain
Con lo expuesto anteriormente, se valida el cumplimiento al objetivo específico 1

(ObjEspN1), en donde se alcanza una confiabilidad de los datos de 99% por sobre
el objetivo planteado 98%.
Cruce: Métrica actual (MA), Métrica esperada (ME) y resultados obtenidos (RO).
Tabla 21: Resumen de objetivo específico 1
Objetivos específicos Métrica / Unidad MA ME RO

Objetivo específico N1 Confiabilidad / porcentaje 94,5 98 99
10.1.2. Disminuir en al menos un 5% el costo de infraestructura.
Como se ha planteado, hyperledger fabric es una solución de concepción

distribuida, en donde todos los nodos que participan son independientes unos de
los otros, permitiendo a una organización presentar múltiples nodos (peers),
creando un modelo tolerante a fallos.
87
También, se presentó que el software de Hyperledger fabric pudo ser desplegado
en una máquina virtual con contenedores Docker, siendo cada contenedor un nodo
distinto e independiente. Esta propuesta de despliegue permite integrar la solución
con casi cualquier tecnología de infraestructura en la actualidad, no limitando la
solución a una tecnología de TI especifica.
En relación con esto, es que la solución de software puede ser desplegada sobre la
infraestructura propuesta, punto 8.3. Esto nos permite lograr una arquitectura
distribuida y tolerante a fallos, con la ventaja de ser implementado en tecnología
existente en la compañía.
A continuación, se presenta la solución de infraestructura en cruce con Hyperledger
Fabric.
Ilustración 71: Solución de infraestructura en cruce con Hyperledger Fabric
Se presenta una arquitectura distribuida sobre contenedores docker, en dichos

terminales, los nodos hyperledger desplegados. La solución de contenedores será
soportada por clusters de máquinas virtuales. Dichas máquinas virtuales se
encuentran cubicadas en la infraestructura existente en la compañía, tecnología
hiperconvergente (Punto 8.1). De acuerdo con lo señalado en el punto 8.2, se
considera la compra de equipamiento para el crecimiento de la infraestructura virtual
y que el presente proyecto no afecte la utilización de recursos de la actual.
88
A continuación, el costo de implementación y tecnología.
Tabla 22: Costos de implementación y tecnología de la solución
ITEM Valor unitario Cantidad Valor total

(USD) (USD)
Servidor Blade Syn480 $ 14.950 2 $ 29.900
Licencias vSphere $ 6 .100 4 $ 24.400
Licencias RHEL DC $ 3.724 2 $ 7.448
Licencias Veeam BKP $ 3.438 4 $ 13.752
Implementación Infra $ 10.733 1 $ 10.733
Implementación SW $ 15.000 1 $ 15.000
TOTAL $101.233
Con la solución de infraestructura propuesta, se logra cumplir el objetivo específico

2 (OE2). Entregando una solución flexible, escalable y de menor costo.
Cruce: Métrica actual (MA), Métrica esperada (ME) y resultados obtenidos (RO).

Objetivo específico N2 Costo infraestructura Global / UF 86.000 81.700 2.769
10.1.3. Obtener un 99,7% de disponibilidad del servicio.
Con la propuesta de infraestructura TI y la integración de la tecnología distribuida

de Blockchain, es posible lograr un ambiente tolerante a fallos y redundante, esto
esencialmente por la arquitectura definida a nivel de infraestructura y la capacidad
del software de seguir operando, aunque uno de sus nodos no esté presente.
Permitiendo de esta forma entregar servicios sin interrupciones, ya sea por falla o
por mantención programada.
Es por esto, que ambas soluciones se complementan, de tal forma que nos
proporcionan arquitectura robusta y nos permiten entregar una disponibilidad del
servicio de un 99,7%.
De acuerdo con lo anterior, es que se cumple y se valida el objetivo específico 3
(ObjEspN3).
Cruce: métrica actual (MA), métrica esperada (ME) y resultados obtenidos (RO).

Objetivo específico N3 Disponibilidad / porcentaje 99,2 99,7 99,98
89
11. CONCLUSIONES
En el transcurso del desarrollo esta tesis, se analizaron distintos tipos de blockchain,

donde quedó en evidencia que pueden atender diversas problemáticas, ya sea del
mundo financiero o de otra industria. Dado que este estudio se centró en la banca,
se pudo apreciar que existen numerosos temas que pueden ser resueltos o
mejorados mediante el uso de esta tecnología. Por mencionar alguno, tales como
compensaciones interbancarias, sistemas de fraude centralizado, activación y
desactivación de productos, podría ser resuelto mediante esta tecnología con
procesos rápidos y proveyendo resultados positivos para la industria financiera en
Chile.
Se pudo apreciar que existen variadas soluciones que pueden resolver y/o potenciar
diversas problemáticas en banca, siempre apuntando a la seguridad y disponibilidad
de la información. Es por lo que se profundizo en el análisis de las diversas redes
en las que se puede implementar blockchain, tales como: redes públicas, redes
privadas y de tipo consorcio. Apuntando siempre a un cruce con el mundo financiero
y en particular a la mejora del sistema bancario de transferencia electrónica de
fondos en el país.
De lo anterior, se determinó, y de acuerdo con los requerimientos del negocio, que
el tipo de red blockchain que más encajaba en el entorno financiero eran las redes
de tipo privadas y de consorcio. Descartando de inicio la posibilidad de utilizar redes
de tipo públicas, esto principalmente por temas regulatorio de la banca y por
supuesto por la concepción de este tipo de red, en donde todos los nodos u
organizaciones de cualquier índole pueden ser partícipes, influyendo notoriamente
en la seguridad y rendimiento de nuestra red.
Ilustración 72: Tipos de redes blockchain
90
Con relación a la problemática presentada y al análisis de las redes blockchian, se
seleccionó las redes de tipo consorcio o federada, esta elección fue principalmente
pues cumplía con el tipo de distribución descentralizada y encajaba con el modelo
financiero en estudio, permitiendo aumentar la confidencialidad de los datos, la
disponibilidad de información y una reducción en los costos de operación e
implementación de tecnológica TI. No obstante, se determinó que las redes de tipo
privada encajaban perfectamente en algunos de los sistemas internos, pudiendo ser
explorada en un futuro cercano.
En el detalle del análisis de la arquitectura de blockchain, se pudo visualizar que
ciertos algoritmos encajaban en la operación de una red de consorcio, lo cual llevo
a una revisión y comparativa de los procesos de consenso disponibles para este
tipo de redes. De acuerdo con el modelo buscado para el sistema de transferencia
de fondos, se seleccionó el algoritmo de consenso PBFT15, pues cumplía con las
características necesarias a los requerimientos funcionales del proyecto, teniendo
en cuenta siempre que el algoritmo se ve afectado en su rendimiento ante una
mayor cantidad de nodos, visualizando una relación indirecta en el crecimiento de
nuestra red (cantidad de nodos) versus el performance de esta. Es importante
señalar que el sistema TEF no tiene incorporaciones de instituciones de forma
frecuente, por lo cual no es un tema de preocupación dentro de lo pronto, en el caso
que superaran la cantidad de 30 nodos en la red, se tendría que evaluar otro tipo de
algoritmo.
Cabe señalar y en lo que respecta a la implementación de la red de consorcio
Blockchain como solución al actual sistema de transferencia electrónica de fondos,
es que se decide utilizar el software de Hyperledger Fabric para el despliegue de
esta. Básicamente se selecciona esta herramienta, pues cumple con las
características de red de despliegue para una red de tipo consorcio. Además, es
una solución que cuenta con mucha documentación y desarrollo, lo cual permite
una mejor implementación y feedback del producto.
Para la implementación del software se requirió de una máquina virtual, a la cual se
le instalaron ciertos requerimientos básicos para que el software pudiera operar.
Uno de los componentes claves dentro de la instalación, fue la utilización de
contenedores con Docker, esto permitió llevar la instalación a un escenario pseudo
real, en el cual se desplegaron múltiples contenedores que simulaban a
organizaciones independientes en nuestra red. La utilización de contenedores fue
una de las propuestas en la evaluación de infraestructura, como reemplazo a la
existente, pues básicamente permite a las organizaciones obtener un nivel de
flexibilidad y escalamiento por sobre lo acostumbrado en la infraestructura de TI.
Con el despliegue del software y los contendores operando entre sí, fue posible
ejecutar las pruebas sobre el ambiente. Se simularon pruebas tanto en un ambiente
15 Practical Byzantine Fault Tolerance - Práctica tolerancia a fallos bizantinos
91
aislado (solo una organización), como también pruebas en donde pudiese participar
más de una organización. En particular, en el segundo caso (análisis de estudio),
se pudo ejecutar y visualizar como una transacción de blockchain fue procesada y
validada por todos los nodos que la componen, siendo una respuesta instantánea y
concordante con lo esperado. Básicamente, la prueba fue un caso de uso llevado a
la realidad, una transferencia de fondo entre dos cuentas distintas, tal como ocurre
en la banca. Con esta prueba se pudo validar que el modelo de TEF puede operar
sin inconvenientes en este tipo de tecnologías, obviamente existen otras aristas a
evaluar, pero en su esencia cumple las expectativas del modelo.
Sumado a la implementación y pruebas de transacciones en el entorno blockchain,
se propuso una infraestructura de TI, la cual pudiese otorgar flexibilidad,
escalabilidad y por supuesto menos costos en infraestructura, esto con el fin de
poder desplegar este tipo de tecnologías de forma eficiente y sin complicaciones.
Se propuso una tecnología existente en la compañía, la cual viene siendo tendencia
a nivel mundial, pues permite crecer en recursos e instancias aplicativas de acuerdo
a la demanda presentada, de esta forma se utiliza solo lo que se consume. La
integración de las tecnologías de contenedores sumando a las tecnologías de
infraestructura hiperconvergente proporciona una solución altamente tolerante a
fallos, escalable y que se adapta a cualquier tipo de iniciativas emergentes.
De la integración de la propuesta de infraestructura TI y del despliegue de la
tecnología blockchain, es que se lograron cumplir los objetivos específicos
propuestos al comienzo de este informe. El resumen a continuación:
Cruce: métrica actual (MA), métrica esperada (ME) y resultados obtenidos (RO).
Tabla 25: Resumen de objetivos específicos

Objetivo específico N1 Confiabilidad / porcentaje 94,5 98 99
Objetivo específico N2 Costo infraestructura Global / UF 86.000 81.700 2.769
Objetivo específico N3 Disponibilidad / porcentaje 99,2 99,7 99,98
Con todo lo presentado, se logró determinar que las tecnologías blockchain en

conjunto con una infraestructura de TI robusta y flexible, pueden resolver y potenciar
distintas problemáticas del ambiente financiero en Chile.
Finalmente, con la implementación de un sistema Blockchain para atender las
transferencias electrónicas financieras (TEF) e integrado con una infraestructura de
TI flexible, será posible aumentar el nivel de servicios de dicho canal transaccional,
con lo cual queda validada la hipótesis planteada en este proyecto.
92
Ilustración 73: Diagrama alto nivel: Propuesta Blockchain Transferencias electrónica de fondos.
93
12. BIBLIOGRAFÍA
Jan van Bon, A. d. (2010). Fundamentos de ITIL®, Volumen 3. Van Haren

Publishing.
Ishikawa, K. (1982). Guide to quality control. New York: Asian Productivity

Organization.
Garnet (7 enero 2020) https://www.gartner.com Obtenido desde el sitio

https://www.gartner.com/newsroom/id/3412017
The financial brand (7 enero 2020) https://thefinancialbrand.com Obtenido desde el

sitio https://thefinancialbrand.com/93422/digital-banking-transformation-success-
failure-tony-saldanha-podcast/
Cobiscorp (20 enero 2020) https://blog.cobiscorp.com Obtenido desde el sitio

https://blog.cobiscorp.com/blockchain-seguira-revolucionando-sector-financiero-
2019
Sbif (25 enero 2020) https://www.sbif.cl Obtenido desde el sitio

https://www.sbif.cl/sbifweb3/internet/archivos/norma_87_1.pdf
Welive security (25 enero 2020) https://www.welivesecurity.com Obtenido desde el

sitio https://www.welivesecurity.com/la-es/2018/09/04/blockchain-que-es-como-
funciona-y-como-se-esta-usando-en-el-mercado/
Bit2me academy (8 febrero 2020) https://academy.bit2me.com Obtenido desde el

sitio https://academy.bit2me.com/cuantos-tipos-de-blockchain-hay/
Banco Interamericano de Desarrollo (8 febrero 2020) https://blogs.iadb.org

Obtenido desde el sitio https://blogs.iadb.org/conocimiento-abierto/es/tipos-de-
blockchain/
94
Astec (14 marzo 2020) https://medium.com/astec Obtenido desde el sitio
https://medium.com/astec/entendiendo-los-protocolos-de-consenso-de-blockchain-
4858c71722d2
VMware (16 mayo 2020) https://www.vmware.com/ Obtenido desde el sitio

https://www.vmware.com/products/hyper-converged-infrastructure.html
Conasa (23 mayo 2020) https://www.conasa.es Obtenido desde el sitio

https://www.conasa.es/blog/contenedores-docker/
Triodos (23 mayo 2020) https://revista-triodos.com Obtenido desde el sitio

https://revista-triodos.com/el-pais-que-elimina-dinero-en-efectivo/
HPE (6 junio 2020) https://assets.ext.hpe.com Obtenido desde el sitio

https://assets.ext.hpe.com/is/content/hpedam/documents/4aa5-3000-3999/4aa5-
3811/4aa5-3811spl.pdf
Science Direct (6 junio 2020) https://www.sciencedirect.com Obtenido desde el sitio

https://www.sciencedirect.com/science/article/pii/S240595951930164X
95

L3 - Sistema Remoto Una Solución Telemática para La Banca Electronica

Cargado por

Copyright:

Formatos disponibles

L3 - Sistema Remoto Una Solución Telemática para La Banca Electronica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

L3 - Sistema Remoto Una Solución Telemática para La Banca Electronica

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD ANDRÉS BELLO

Magíster en Gestión de Tecnologías de Información y Telecomunicaciones

ANÁLISIS DE TECNOLOGÍA BLOCKCHAIN PARA SERVICIO DE

Profesor guía: David Ruete Zúñiga

Tabla 1: Costos por infraestructura .................................................................................................................. 19

Ilustración 1: Tecnologías claves ...................................................................................................................... 11

1 Sitio especializado en industria bancaria https://thefinancialbrand.com

Ilustración 1: Tecnologías claves

Este estudio posiciona a muchas nuevas tecnologías como tendencias y soluciones

“Aunque el concepto es simple, traerá ahorros considerables para los bancos. La

1.2.1. Casos de Éxito2

2 Referencia desde el sitio: https://blog.cobiscorp.com/blockchain-seguira-revolucionando-sector-

1.2.2. Banca en Chile

Ilustración 2: Gráfico de tenencia de cuentas transaccionales por país.

Como bien se visualiza, la cantidad de cuentas bancarias existentes en Chile nos

Ilustración 3: Gráfico de transacciones bancarias según tipo de instrumento de pago

En la imagen la SBIF nos presenta un consolidado de los tipos de transacciones al

1.3. Marco de trabajo

El presente trabajo se basara principalmente en la integración entre las opciones

Ilustración 4: Ciclo de tecnologías emergentes (Gartner, Octubre 2019)

1.3.1. Dentro de las ventajas que se aprecian en esta decisión se tiene:

1.3.2. Dentro de las desventajas vemos:

1.3.3. Los alcances que tendrá el proyecto serán:

Esta sección presenta el entorno donde reside el análisis de la problemática, para

Considerando los antecedentes descritos en el capítulo anterior y las capacidades

Ilustración 5: Gráfica de transferencia electrónica en línea (TEF)

2.2.1. En cuanto al Presupuesto:

Tabla 1: Costos por infraestructura

ITEM VALOR Periodo

2.2.2. En cuanto al Personal:

➢ La contar con servidores propietarios de una marca y cerrados en su código

Tipo de incidente Valor

2.2.3. En cuanto a la Operación:

➢ Tiempos elevados en la acción de una recuperación de servicio producido

Tabla 3: Tiempo de incidentes por tópico.

Tipo de acción Indisponibilidad por año Ocurrencia

2.2.4. En cuanto a la Infraestructura:

Gracias al diagrama Ishikawa y sus ramas, pudimos determinar varios problemas a

Problema N3 Baja o nula documentación.

Problema N4 Tiempos elevados de mantención y recuperación ante incidentes.

Problema N5 Inconsistencia de datos entre servidor primario y contingencia.

Problema N6 Reclamos de clientes por transacciones no reconocidas.

Con los antecedentes expuestos en el capítulo anterior, es posible determinar

3.1.1. Objetivo general

El objetivo general del proyecto es proponer y evaluar una solución escalable e

3.1.2. Objetivos específicos

Con el fin de lograr el objetivo general presentado en el punto anterior, se presentan

A continuación, se presentan las métricas consideradas para evaluar el éxito de los

Identificador Objetivo específico

Objetivos Métricas Métricas

➢ Objetivo específico N1:

Métrica actual Fórmula

Tabla 9: Datos de transacciones TEF durante 2020

Transacciones TEF año 2020

Métrica actual Fórmula MA

➢ Objetivo específico N2:

Actualmente los gastos operacionales relacionados a la infraestructura crítica

Tabla 11: Fórmula de objetivo específico N2

➢ Objetivo específico N3: