 Listo, entonces hoy vamos a tener una sesión que introduzca otro proyecto de Hyperledger que es Caliper, pero pues realmente es una herramienta que es útil pues en todos para todos los aspectos de Hyperledger también pues, porque es una herramienta para hacer benchmarking y testing de diferentes redes de blockchain realmente, entonces podemos hacer pruebas de carga, podemos colectar métricas de esas pruebas, podemos automatizar ciertos escenarios de testing pues de pruebas, entonces es una herramienta que complementa a diferentes frameworks y vamos a dar como una introducción a esa herramienta para que lo puedan también usar y automatizar ciertas de sus pruebas y casos de usos que van a desarrollar en el futuro, entonces primero vamos a otra vez como hablar un poco desde la teoría y en este caso especialmente la arquitectura de Caliper, porque también como fabrico es una arquitectura modular, entonces luego vamos a hacerlo en práctico ya apuntando a la red que hemos construido en todas las sesiones, vamos a ver como lo podemos hacer pues implementar en práctico con el caso de uso que estamos trabajando y después como dijo Camilo ya vamos a hacer, lastimosamente el cierre del curso de esta edición al menos, listo, vamos, empezamos con Caliper entonces, Caliper es como acabo de decir, existen diferentes componentes y al final lo que hace es enviar carga o pruebas, pues carga a un local que se llama SUT o SUT, que significa Sistema Under Test o Sistema Bajo Prueba y puede ser Hyperledger Fabric, puede ser Ethereum, puede ser Sautoot, también puede usar por blockchains que no son de Hyperledger misma, porque cada sistema puede tener sus adapters y implementan ciertos APIs de Caliper y así Caliper puede enviar carga realmente a cualquier red de blockchain y sabe como pues también unos adapters o componentes para hacer, para que Caliper sabe como colectar las métricas y como esperar por la finalización de una transacción que puede ser diferente por diferentes blockchains o frameworks, entonces hay un componente de Caliper central que se llama el Master o el Manager también se llama y eso va a ser como para orquestrar todas las cargas, entonces ahí va a hablar con unos módulos que puedes ver como unos threads o procesos que están corriendo en paralelo, entonces esos son los workload modules que realmente son los módulos que realmente van a enviar las pruebas a la red, tenemos ciertas configuraciones como el benchmark configuration, el benchmark configuration hay defines como Caliper tiene que, primero que son los escenarios, que vamos a probar o también como vamos a crear la carga, si cuáles son las transacciones por segundo, si enviamos la carga en ciertos intervalos de tiempo, pues ahorita vamos a ver todas las configuraciones realmente que se pueden hacer ahí por defecto y también tienes que tener ciertas configuraciones de la red que es un poco similar a cuando usas el SDK de fabric, tienes que también especificar algunos componentes de la red iniciales, como los anchor peers por ejemplo, un order o el client que quieres usar en el SDK, entonces son esos configuraciones de la red que también se necesita, también hay otros artefactos que configuran también Caliper y el runtime, por ejemplo esos configuraciones que son específicos para los diferentes sistemas bajo de prueba y al final de las pruebas Caliper va a generar los reportes y esos reportes también se pueden obtener de diferentes formas y eso era cómodo alto nivel y entonces los sistemas bajo de prueba, los que ya son soportados oficialmente, que ya tienen sus adapters desarrollados realmente, son Hyperledger Fabric que vamos a usar hoy, también Hyperledger Beso y Ethereum también son soportados, entonces también puedes apuntar Caliper a Ethereum realmente para hacer pruebas de carga, a la Beso, a Burrow también, a Iroa, a Southwood y también a Fisco, entonces si aquí hay un blockchain que no está soportado todavía, también en la documentación puedes hacer cómo escribir los adapters y realmente entonces puedes usar Caliper por cualquier blockchain que tú quieres probar, entonces es una herramienta muy útil y entonces vamos a mirar un poco más en profundidad de cómo exactamente funciona, entonces como ya les comenté hay diferentes procesos, hay el Caliper Manager o en algunas versiones también se llama Master y luego hay un grupo de workers y pues tú puedes configurar cuántos workers tienen que existir, dependiendo de la carga pues que quieres generar y de las máquinas que tienes disponibles también depende, luego puedes dar el sistema bajo de prueba y lo que el manager hace es la orchestración y realmente dar las instrucciones a lo que los workers tienen que ejecutar, pero al final quienes crean la carga y quienes mandan la carga al sistema bajo de prueba son los workers, y por eso pues con esa arquitectura se puede enviar una carga más alto que si fuera solamente un proceso que está generando las transacciones, lo que el manager sí hace todavía es algunas inicializaciones, es opcional realmente tú podrías si estás soportado por Caliper puedes hacer ciertas cosas que el manager primero instala unos scripts o instala el chain code pues esos procesos operativos que tienes que hacer para preparar tu red, eso lo puedes también hacer con Caliper y luego los workers van a hacer realmente, van a generar y enviar las transacciones y entonces si tú dices que quieres enviar 500 transacciones en tantos segundos, entonces esos 500 transacciones van a compartir entre los workers para que esa velocidad pues lo pueda lograr, entonces el proceso de master manager lo que puede hacer, pues existen diferentes fases, entonces lo que puede hacer es realmente ejecutar cualquier script que se necesitan ejecutar antes de las pruebas, si realmente puedes hacer cualquier cosa que necesitas generar o configurar o iniciar antes de las pruebas, luego lo que va a hacer el manager es inicializar el suite pues el adapter del sistema bajo la prueba, inicializarlo, conectarse, si es necesario instalar los contratos, aunque esto para fabric en la última versión de fabric, versión 2.2.0 no está soportado más por Caliper en este momento, entonces lo que tenemos que hacer es instalar los contratos, pues antes de iniciar a Caliper y entonces tienes que pasar, pues no tienes que hacer estos pasos, pero tienes que ir directamente a las pruebas, porque luego el manager entonces dependiendo de tus configuraciones va a programar las rondas de prueba, pues los rounds y eso define entonces cuántas transacciones cada worker tiene que ejecutar, etcétera, entonces es configurar los workers para que ellos ya empiezan a enviar la carga cada uno al sistema bajo la prueba y después tú puedes también hacer correr un script, pues un script final y eso lo puedes usar para limpiar ciertos recursos o por procesar ciertos resultados, también lo que quieres hacer realmente. Entonces los poderes de workers también tienen su flujo por decirlo así, entonces un worker va a recibir el comando de ejecutar una ronda y va a tener su main loop, cuando recibe el comando va a esperar para que el manager también dice cuál es el raid, pues a qué velocidad o qué número de transacciones o qué cargo tiene que enviar realmente y cuando sabe todo eso va a construir las transacciones y va a realmente enviarlos a la red a través del adapter y va a colectar las respuestas de las transacciones que mandó, va a esperar hasta que se finalizaron o hasta que fallaron porque también puede pasar y entonces dependiendo de eso va a generar sus reportes y va a comunicarlo otra vez al manager y el manager va a colectar todas las métricas y los resultados de todos los workers que tenían desplegado y así tener un solo número de desempeño o de las métricas pueden que estés interesado. Entonces la comunicación entre el worker y el manager o entre los workers y el manager es modular, entonces tiene un componente para esa comunicación y entonces por la modularidad en que está implementado en Caliper se puede cambiar el protocolo con que se habla entre ellos y ciertas implementaciones son más simples pero son restringidos a una máquina local y estos entonces sirven más por desarrollo pero para obtener mejor desempeño y entonces poder probar mejor tu red, la idea es que todo tu distribución de los componentes es distribuido en diferentes máquinas para que también cada componente pueda alcanzar su máxima potencial por decirlo así, obtener suficiente capacidad para generar la carga mayor posible que puede generar entonces hay una opción que simplemente va a tener Caliper en una sola máquina y el mismo manager localmente en la misma máquina va a subir los workers al momento que inicias las pruebas y simplemente con comunicación entre los procesos que son desarrollados en Node.js entonces es un proceso de comunicación de Node.js realmente entre los componentes y todo en una sola máquina, entonces ahí todos los workers tienen que compartir recursos entonces no vas a generar una transaccionidad tan alta pero es muy bien para pruebas si también tienes tu red local y simplemente quieres probar si tus configuraciones están bien si las pruebas que quieres ejecutar funcionan entonces es lo más fácil y bueno para hacer pruebas iniciales de Caliper y de tu red eso es lo que vamos a ver en esta clase porque si no tendríamos que desplegar puedes tener muchas máquinas y no lo podrían hacer ustedes o también tendrían que desplegar diferentes máquinas y eso puede ser un poco costoso otra vez para el curso otra opción que ya es un poco más cercano al modelo completamente distribuido pero todavía lo que va a hacer todavía al manager es subir los workers en la misma máquina en que él está desplegado solamente que aquí la comunicación no va a ser directamente entre los procesos pero puedes instalar un message broker o un componente de mensajes un agente de mensajes y el manager entonces en vez de comunicar directamente con los workers va a publicar mensajes en el message queue o en el message broker y entonces cada worker va a escuchar ese broker para recibir las instrucciones de la cara que tiene que ejecutar y ese message broker no tienes que desplegarlo en la máquina misma la idea es que lo desplegues también en otra máquina y así ya estás distribuyendo en el momento que funciona esa conexión ya sabes que tu message broker está bien configurado y ya puedes empezar a ver cómo ahora voy a distribuir también mis workers porque cuando estamos en la opción para producción con cada componente en otra máquina ahí entonces necesito comunicarme a través de mensajes entonces cuando esto ya funciona con el message broker en otra máquina entonces desde ahí puedes evolucionar a un sistema completamente distribuido en que el manager lo va a correr en una máquina el message broker lo va a correr en una máquina y luego los workers también lo va a correr cada uno en su máquina pueden usar cada uno sus recursos al máximo generalmente lo que es la diferencia también entre los desplegues locales y desplegues distribuidas que aquí con los locales el kali per manager mismo va a desplegar pues va a desplegar sus workers o iniciarlos y entonces dinámicamente puedes configurar cuántos tienen que desplegar y lo va a hacer en la máquina misma automáticamente en el caso del desplegue distribuido tienes que tú mismo tienes que desplegar los workers la cantidad de workers que quieres tener disponible tienes que desplegarles tú mismo antes de lanzar el manager porque como aquí el manager no tiene acceso a estas máquinas no puede desplegar pues ir a desplegar procesos en otras máquinas entonces tú mismo tienes que asegurar que tienes los workers corriendo antes de lanzar las pruebas con el manager a través del message broker y pues recomendado ahí es hacer ese desplegue con Kubernetes porque kali per tiene imágenes de docker por cada componente hay un imagen para los managers y también para los workers pues yo creo que aún son creo que es el mismo imagen aún solamente que tienes que configurar los diferentes para que toman el role de worker o toman el role de manager y después desplegar también tu message queue y entonces desplegues la configuración pues de Kubernetes en tu cluster y ya puedes lanzar cuando tus workers están desplegados y tu manager también y tu message queue tu manager ya puede lanzar las pruebas enviar la instrucción al broker y el broker entonces pues los mensajes van a ser recibidos por los workers que entonces los workers van a enviar la carga a la red a la red que está configurado hay ciertos artefactos pues o archivos para implementar que realmente son muy pues relativamente simples son sobre todo configuraciones entonces el runtime configuration es como quieres que kali per mismo actúa o como quieres cuáles pruebas quieres que hace o como si siempre las ciertas configuraciones de kali per mismo luego los network configurations ahí va a especificar los componentes de la red a que tiene que apuntar y luego ya los benchmark configurations eso son ya de las pruebas que quieres ejecutar entonces puedes tener ciertos escenarios sobre que se tiene que probar cuántas transacciones cuántas rondas diferentes transacciones de tu chain que quieres probar y los callbacks los callbacks son los... es el código realmente que genera las transacciones y que las envía a la red y eso es lo que lo ejecutan los workload modules realmente son la generación de las transacciones y la ejecución realmente los callbacks y pues ahora va a ser más claro lo que es cada uno cuando lo vamos a ver en práctica entonces voy a pasar al demo que va a ser más claro lo que es cada cosa entonces en el proyecto en el hitup es el mismo que siempre solamente que ha llegado una carpeta kali per y ahí están todas las configuraciones de los benchmarks de la red el runtime configuration de kali per y ya les voy a explicar qué es cada cosa y vamos a ejecutar unas pruebas primero para hacer los comandos pues juntos con ustedes voy a elaborar ciertas cosas que ya tenían aquí por ejemplo los logs para que empezamos desde 0 y que pueden seguir cuáles comandos y se tienen que ejecutar para configurar todo listo aquí en el readme están las instrucciones entonces eso lo pueden encontrar en el repositorio hay algunas prerequisitos que tienes que tener algunas cosas de pues Node.js mismo también algunas cosas de Python make y hit pues también luego para instalar kali per en tu máquina pues lo puedes instalar globalmente pero también es bueno pues instalarlo solamente pues para este para este proyecto por así o así entonces vamos a ir a la carpeta de kali per y vamos a hacer el npm init porque los caliperes están escritos en Node.js entonces todos los packages están en npm entonces podemos iniciar eso nos crea pues el package json de este proyecto y luego lo que tenemos que hacer es instalar kali per mismo entonces obtener los node modules del core de kali per por así decirlo así y eso puedes la instalación local también puedes hacer la instalación con docker para que tienes kali per en un contenedor pero para el desarrollo es más fácil descargar pues el client el client tool lo que estamos descargando ahora cuando ya está instalado como tal kali per client en tu máquina entonces lo que tenías que hacer es decir a kali per cuál va a ser el sistema bajo de prueba entonces va a ser fabric usamos la última versión 2 porque todavía también podrías apuntarlo a una versión 1.4 o menos y también decir en cuál es de qué queremos usar y pues obviamente va a tener que ser lo mismo pues si en el caso que está disponible y luego hay que hacer agregar algunas cosas específicamente de fabric para la versión 2 siempre tienes que usar el gateway entonces el gateway es la forma en que los aplicaciones pueden conectarse con la red y como les mencioné ya en el ultimo SDK se quitaron algunas funcionalidades para instalar 5 y para hacer ciertas configuraciones pues lo sacaron a otro paquete pero por eso kali por toda la vida no lo puede usar lo que tenemos que especificar es que solamente hay que hacer la fase de las pruebas entonces no tenemos que instalar ningún contrato hay que asegurar que el contrato ya está instalado en la red que quieres probar entonces hay que especificar para que kali no intenta instalar ningún contrato porque no va a funcionar entonces vamos a hacer ese bind de kali con el sistema bajo la prueba y eso entonces va a descargar esos adapters que kali necesita para conectarse con fabric si hubiera especificado southwood con su versión pues hubiera descargado los packages para conectarse con southwood listo vamos a esperar hasta que termina listo y pues pueden ver aquí entonces en los node modules tienen que estar instalados los paquetes pues de kali y de fabric pues los adapters y la versión 2 lo que vamos a usar y eso realmente la instalación de kaliper es tan simple realmente son esas tres comandos y ya está instalado kaliper entonces ya podríamos lanzar el master o el manager con sus configuraciones pero pues vamos a pasar primero por cada configuración que tiene que hacer los archivos entonces tienes que especificar el kaliper workspace eso tiene que ser la carpeta donde tienes configurado tu kaliper.yaml que son como las configuraciones del runtime entonces son todas configuraciones de kaliper mismo pues aquí copie todos los configuraciones que existen realmente para que pueden tener una idea pero no estoy usando en este momento o los puedo dejar en las configuraciones por defecto o aún es a bind lo estoy configurando ya en los comandos es a bind aquí con el suit eso ya lo hicimos con el comando bind que hicimos realmente puedes cambiar el nombre del reporte que tienen que generar puedes configurar ciertas cosas puedes pasar al pat otras archivos de configuración pero también esos pat en vez de ponerlos en el archivo lo estamos sobre escribiendo aquí como pueden ver kaliper bench config sería lo mismo poner ese pat aquí pero puedes más flexible poder cambiarlo en el comando hay ciertas configuraciones del monitoreo de los métricas que tienen que sacar en qué formato qué labels tiene que tener todo eso lo puedes configurar hasta los colores de diferentes cosas que va a generar en los reportes aquí tienes que configurar entonces los workers pero es todo esto también lo puedes sobre escribir en las otras configuraciones entonces remote eso significa entonces si tienes la el despliegue distribuido en este caso vamos a coger los workers localmente entonces está en falsa la comunicación vamos a hacer por el interproces como lo estamos haciendo local no vamos a desplegar ningún message broker pero cuando lo quiere hacer el protocolo que kaliper usa es mqtt que es un protocolo de mensajería muy ligero que también usan mucho en proyectos de IoT pues comunicación entre los dispositivos de IoT los sensores entonces es un protocolo muy ligero pero no lo vamos a usar pero también si lo quieren desplegar pues a un lado es también es tan complejo realmente y aquí llegamos a las configuraciones del flow y el flow entonces eso es como el flujo que el manager va a ejecutar por ejemplo necesitamos correr un script un start script tenemos que hacer ciertas inicializaciones tenemos que instalar el chaincode por ejemplo otras cosas pues luego la fase de las pruebas y luego si tienes que correr algún script de terminación para limpiar ciertos recursos o otras cosas aquí tú puedes definir cuál de esas fases quieres no conozco la palabra en español pero que no quieres hacer entonces skip pues por ejemplo si no quieres hacer la fase de instalar chaincode tienes que ponerlo en true pero aquí lo pusimos en false porque tienes otra opción en vez de usar el skip puedes usar el only y el only entonces cuando tú quieres solamente usar ciertas fases en vez de decir cuáles tienes no puedes hacer puedes decir cuáles si quieres hacer entonces en este caso la red ya va a estar desplegado la inicialización de la red ya está hecho o el benchmark la instalación del contrato ya está hecho entonces todo esto lo pongo en false lo que quiero hacer es la fase de las pruebas como tal entonces aquí dices solamente quiero hacer la fase de pruebas por eso está en true pero si tú también quieres hacer ejecutar un script al final puedes hacer true aquí y pues agregar el script en las configuraciones pero para hoy solamente vamos a usar el test si usan la versión de faraik de 2.2.0 pues desde 2.2.0 nunca pues nunca les va a funcionar el instal porque los packages ya no desde cada de esa versión ya no tienen todas las funcionalidades más pues al menos no en esta en esta paquete y eso ya son las configuraciones de cada ypermismo y aquí puedes agregar algunas configuraciones del sistema bajo de prueba pues como tal en este caso de fabric ciertos pues timeouts para cierras operaciones pero esas operaciones no los vamos a hacer eso ya están hecho muchos timeouts sobre todo aquí el load balancing si lo quieres hacer por transacción o por worker pues si lo haces con por transacción pues ellos mismos van a dividir pues el trabajo entre ellos lo más lo más flexible y más fácil pues para que pues se autogestiona realmente y hace su propia balancea de cargas entonces creo que es la mejor opción y aquí hay algunas cosas importantes que para habilitar entonces pues lo mejor es usar de fabric el API sobre todo en la versión 2.2 pues de 1.4.7 aún creo que ya tenía al gateway en los SDKs aquí indicar entonces que estamos que tenemos una red en la máquina local y pues podemos también habilitar el discovery service así para que la información de la red no tenemos que especificar cada pier o cada order los orders mismo pues van a comunicar los otros componentes que ellos conocen en la red y así también el SDK porque caliper por debajo usa los SDKs el SDK mismo pues va a saber cuáles no los están disponibles en cada momento y si pondrías toda la red o todos los nodes que tú quieres usar pero es más estático entonces si lo quieres más dinámico y más residente de cierta forma pues es mejor usar el discovery service el event strategy también son configuraciones que también van a ver en los SDKs eso significa en qué momento el SDK o caliper en este caso va a considerar una transacción como finalizado entonces con MSP ANI eso significa que si un pier de cualquier MSP un pier de cualquier reunión recibe el blog y emite el evento del blog y pues esa transacción adentro entonces ya caliper va a decir ya un pier en la red ya recibió ese blog y ya lo aplicó a su world state entonces para mí esta transacción está finalizado tú puedes decir pues no conozco exactamente el sintaxis pero puedes especificar que solamente tu propio MSP no es el sintaxis eso lo pueden ver en la documentación pero hay diferentes estrategias y tú puedes decir no solamente quiero que consideras la transacción finalizada cuando uno de mis pier lo confirma pues lo recibió o tú puedes decir en vez de ANI puedes decir yo quiero que un pier de todas las reuniones tiene que haber recibido el blog ya antes de que considero la transacción final entonces puedes poner al MSP por ejemplo pues todas esas configuraciones lo puedes hacer para si pues va a depender si tú pones ANI MSP la respuesta es que la transacción va a ser pues se va a considerar como terminado más rápido en vez de que cuando esperas todos los MSPs pues eso va a tardar un poco más pero depende de cuál cuál seguridad quieres tener sobre la finalización de la transacción y el query strategy entonces eso también significa que aquí el MSP Rand Robin entonces de pues Kaliper va a enviar sus queries no solamente un pier pero a cualquier organización en forma de Rand Robin entonces primero a organización 1 luego a un pier organización 2 y así va también balancear pues la carga para hacer las transacciones que son queries realmente pero igual tú podrías decir que solamente quieres hacer queries a los pier de una organización específico entonces todo eso puedes configurar y pues aquí como pueden ver si usaríamos Saudit pues Saudit va a tener sus propios configuraciones pues particularmente para Saudit pero eso no lo vamos a usar entonces lo quite y eso es la configuración pues del run time de Kaliper como se llama entonces el workspace tiene que apuntar a ese archivo de configuración y como estamos en la carpeta misma simplemente es pues el punto aquí luego pues vamos a mirar primero el network config entonces tú tienes que especificar cuál donde están ciertos peers y Kaliper puede consultar para iniciar sus pruebas pues a donde puede apuntar entonces para eso tenemos la carpeta networks y entonces pueden ver que aquí lo llame esa es la configuración pues de la red local que tenemos en la máquina pero si tú tienes la misma red también desplegado en un ambiente de desarrollo o en producción aún tú puedes crear un archivo pues de la red con la configuración de la red por tus diferentes ambientes y pues esto no va a ser lo calma pero va a tener los IPs pues donde están despegados tus peers y solamente podrías configurar tus propios peers tu propio order y el discovery service pues será usado para conocer también todos los otros peers en la red realmente pero pues para nosotros ahora vamos a tener las configuraciones locales entonces lo que tiene que especificar es algo local pero otra vez cuál red estás configurando realmente que es fabric puedes especificar ciertas organizaciones cuando tú solamente quieres hacer pruebas para tu organización entonces en este caso solamente tienes que especificar tu propia organización y los pies de tu organización y el discovery service va a ser el resto pero aquí como estamos probando pues en una red local y estamos pues queremos actuar en nombre de todas las organizaciones por eso los agregue todos pero normalmente en una red entre varios participantes pues la idea es que solamente tienes que definir tus partes pero pues aquí queremos mostrar como actuar pues en las diferentes organizaciones entonces por eso agregue a todos tienes que especificar el MSPID los pies o al menos un PIB si quieres usar ese PIB también pues para la conexión inicial podrías también especificar los certificatores en el caso que no tienes ciertos certificados ya generados pero en el caso de nosotros con los scripts que tenemos para subir la red ya están todos los certificados lo comenté lo podrías usar o lo podrías usar aún en tus pruebas podrías también generar los certificados anteriormente antes de hacer las pruebas pero en nuestro caso ahora nos necesitamos puedes especificar los llaves pues del admin de esa organización en el caso que también quieres actuar ejecutar ciertas cosas con el admin luego tienes que especificar el canal a que caliper tiene que mandar las transacciones aquí pues yo especifico todos los orders pero realmente podrías solamente especificar uno no es necesario especificar los tres pero pues lo hice aquí para mostrarles entonces también los pies que están sirviendo este canal porque tú podrías especificar más canales en el mismo pues que están creados en la misma red puedes ser pues que tú usas otros pies para otros canales entonces otra vez tienes que especificarlos y aquí entonces tú puedes especificar cuáles pies pueden ser usados como fuente pues de eventos entonces lo que vimos aquí del event strategy entonces queremos sacar pues si estamos interesados en eventos de cualquier organización entonces también pues tenemos que especificar un pie de cada organización que se puede usar como fuente de evento si yo en aquí hubiera dicho no solamente quiero saber de escucharlo de eventos de organización uno pues entonces en este caso no debería haber hecho esto en true porque no voy a usar no estoy interesado en los eventos pues que llegan al pie dos o que el pie dos emite aquí decimos que el canal ya está creado porque con esas funcionalidades pues de esos fases de inicio cuando un canal no está creado Kaliper lo podría crear para ti pero pues creo que eso tampoco en la versión 2 está temporalmente deshabilitado y especificar los chain codes que existen en la red también para Kaliper también ya puede iniciar pues el contacto pues con con el chain code y sabe cuál chain code existe para escuchar luego puedes especificar ciertos usuarios y esos son los usuarios en el nombre de que las transacciones van a generar entonces pues aquí también especificé un usuario de cada para cada organización esos son los los clients pues que siempre hemos usado que tienen el atributo el OU attribute con el nombre del canal entonces ellos pueden actuar sobre el chain code así lo hice por cada por cada client para Kaliper puede firmar las transacciones en el nombre del client pues tienen que conocer la Java y tener el certificado aquí pues eso es algo estándar aquí pues Kaliper va a crear la la billetera basada en esa Java certificado y aquí lo va a guardar temporalmente esos son los clients y luego ya de los peers que hemos especificado aquí con solamente el nombre aquí vamos a definir pues donde están realmente corriendo entonces el URL que aquí en este caso todo es localhost como siempre hay que pasarlos para Kaliper puede confiar en ese peer y conectarse pues con el y ciertas como aquí estamos trabajando con localhost si no tienes localhost en tu certificado como DNS name entonces va a tener que decir a Kaliper yo también confío por ese peer si tiene esto en su en su certificado como DNS name porque pues aquí el está pensando que está comunicando con localhost y pero él valida el DNS name en el certificado entonces si eso no es localhost pues tienes que aquí decir que también confías cuando el DNS name es peer 0.1.1. entonces es como el override y aquí también para un time out para las conexiones pues especifica todos los peers no siempre es necesario por usar el discovery service pero pues aquí lo lo hice porque a veces si dan mejores resultados y menos fallas de la red porque si la red está hablando entre todos y averiguando pues que quienes están vivos, quienes no a veces eso genera algunos errores o time outs y sobre todo cuando estamos enviando cargas muy altos y pues también especificar los orders normalmente también un order suficiente pero aquí los especifica todos pues para que saben como hacerlo eso es la configuración de la red que es el segundo archivo que tienes que pasar para lanzar el master o el manager luego estamos ya listos para configurar el escenario que queremos ejecutar realmente o el benchmark que queremos hacer entonces para eso tengo una carpeta benchmarks aquí y tiene dos partes tiene los escenarios y aquí pues vamos a usar el currency contract entonces podemos generar un escenario en que se van a hacer el minting pues la emisión de las monedas en que después se hace una transferencia después la transferencia se hace un redeem y entonces así podías configurar un escenario con todas las transacciones en una ejecución de caliper y eso lo tienes que especificar entonces el primer archivo de configuración del escenario ahí vas a decir que pruebas realmente que tienen que ejecutar los workers realmente entonces lo especificas por el test un nombre pues una descripción que hace este escenario luego especificas los workers que tienen que ser el tipo local en este caso cuando tienes un desplegue distribuido tienes que especificar que es una configuración de remota aquí como y aquí tienes que especificar cuáles workers tienes disponibles en el caso que especificas el desplegue distribuido tienes que tienes que asegurar que cuando especificas 8 aquí tienes que estar seguro que realmente 8 workers pues desplegado aquí cuando hagamos local el manager pues al lanzar el comando el manager mismo va a iniciar pues tres procesos de workers listo voy a dejarlo en tres y aquí va a especificar entonces cada ronda de pruebas entonces puedes especificar diferentes por ejemplo puedes especificar una ronda en que vas a medir pues el desempeño de la transacción mint entonces puedes decir cuántos transacciones quieres enviar de ese mint si lo quieres hacer en un fixed rate significa si yo especifico 25 por segundo aquí todos cada segundo va a enviar a 25 transacciones pero tu también puedes especificar otros tipos de raid controller esos lo puedes encontrar en la documentación de caliper hay una una sección de los raid controllers y entonces existe el fixed rate en que tu dices la transacción por segundo y caliper va a tener esa transaccionalidad pues fija también puedes pues hay diferentes también puedes simplemente crear un backlog pues la transacción que tienes que hacer puedes combinar ciertos raids primero un fixed rate de 100 luego un fixed rate de 300 200 también puedes tener un linear raid inicia con 25 por segundo y termina en 75 entonces se va gradualmente caliper mismo va a subir esta transaccionalidad por segundo por esta ronda hay varios yo tampoco conozco todos realmente pero puedes interesante en que caso puedes mejor usar otro sobre todo el linear raid entonces tu podrías empezar bajo y terminar muy alto y así vas a encontrar como el punto donde el punto donde el sistema ya está como como se dice en español pues a su máximo potencial o algo así cuando ves que ya este esto no lo puede ejecutar más pues en el tan alto puedes encontrar como el punto en medio donde el sistema mejor funciona y los fixed rates puedes solamente una sola velocidad en que envía transacciones y eso por todo el tiempo de la ronda realmente entonces aquí usamos solamente el fixed rate entonces aquí va a enviar 100 transacciones con una velocidad de 25 por segundo entonces debería tomarse como 4 segundos para ejecutar y y pues aquí está muy bajito hay podría fabric puede alcanzar pues una transaccionalidad mucho mayor pero como aquí tenemos la red desplegar localmente también cali desplegar localmente entonces todos los recursos de cada componente están compartidos entonces los componentes no están actuando a su mayor potencial y por eso pues lo mantengamos muy bajo porque realmente no va a alcanzar mucha mucha transaccionalidad cuando ya tienes una red desplegado en máquinas en la nube que son suficientesmente poderosos y cada pier está en su propia máquina y luego está en su propia máquina caliper está desplegado distribuidamente con cada worker en su máquina o con suficientes recursos ahí va a ser los transaccionalidades mucho mayor entonces lo que tenemos que especificar por esta ronda es con esa velocidad de transacciones lo que los workers tienen que ejecutar es este callback y este callback entonces está definido aquí y eso es similar a usar como el fábricas de cari elementes también está escrito en note y tiene que tener tres funciones tiene que tener una función que es el init y ese init cada worker lo va a ejecutar antes de la cara como tal entonces la ejecución aquí es para preparar también ciertas cosas y no va a ser contado pues en el tiempo de la transacción ahorita vamos a ver lo que está adentro pero quiero pasar primero por todas las funciones que tienes que la segunda es el run y eso es lo que realmente quieres probar aquí es lo que donde si el tiempo caliper va a tomar medir el tiempo en que envía esto y en el tiempo en que termina esa transacción como pueden ver vamos a hacer la transacción mint aquí como el nombre de la ronda hay que pasar los argumentos al chico de esa función teníamos data privada entonces toda esa preparación de esa data privada pues lo hagamos en el init porque si no por cada transacción que caliper tiene que enviar en el run pues debería generar la private data cada vez pero pues aquí solamente vamos a enviar la misma private data entonces mejor lo hagamos en el init y así podemos tener mejores pues una mejor idea sobre el tiempo del mint como tal y no tanto de la generación pues de todos los parámetros también tienes que decir cual identidad o cual client pues cual certifica, cual billetera que eres usar para generar y enviar esa transacción entonces en este caso pues el mint identity ahorita vamos a ver como se pasa esa identidad y para cumplir con las políticas de endorsements puedes especificar unos target peers y como aquí estamos trabajando con private data es importante especificar los peers que pueden recibir la private data si no es una transacción con private data no tienes que especificar los target peers y al discovery service mismo va a seleccionar los peers que necesita para cumplir las políticas de endorsement pero como aquí queremos compartirlos solamente con ciertas organizaciones por los datos privados por eso nosotros mismos tenemos que especificar cuáles peers pueden endorsear la transacción y ya cuando tenemos esos parámetros de la transacción podemos enviarla al chaincode entonces con un invoke invoke smart contract y ahí pasamos entonces esos transaction arguments pasamos el nombre del chaincode la versión del chaincode aunque aunque esa versión calibre en esto no lo usa pues lo pide pero lo ignora entonces no es importante y aquí también un time out que espera para para esa transacción por si hay alguna falla o algo y ya eso es lo que ya eso ya es realmente lo que el worker va a ejecutar por cada cargaca tiene que hacer entonces si este worker tiene que ejecutar 100 transacciones entonces va a ejecutar 100 100 vs esterun entonces va a enviar 100 transacciones del tipo mint a la red y pues el tiempo que toma y como está influyendo pues los recursos de los peers del worker mismo pues todo esto y para terminar hay una función end y ahí entonces podrías limpiar ciertos recursos y por ejemplo si quieres primero hacer el mint y pero tú quieres después destruir pues todos las monedas que fueran emitidos aquí podrías hacer el redeem de esas monedas que fueran emitidos para que tu world state está limpio otra vez después de las pruebas eso lo podrías hacer guardar el transaction ID por cada mint aquí y podrías aquí entonces en el end hacer el redeem por cada moneda pues emitido y así limpiar limpiar las monedas que fueran emitidos para las pruebas eso es lo que lo que es el callback eso es realmente como el corazón pues lo que lo que cada worker realmente tiene que ejecutar cuando recibe sus instrucciones de la carga y aquí entonces hay que especificar los argumentos que quieres enviar a esa función entonces aquí puedes pasar cualquier argumento realmente como currency code porque también podríamos hacer la misma para emitir pero aquí entonces en este escenario solamente vamos a emitir usd hay que especificar cuál organización queremos usar como mint también el MSP de esa organización cuál usuario de esa organización y generar las transacciones como tal especificar a quiénes vamos a emitir pues la moneda aquí pues esto creo que no lo uso a no si eso si lo uso ahorita lo vamos a ver el monto de las emisiones pues aquí lo voy a poner pues fijo pero tu podrías en el callback usar algo de para generar diferentes montos eso lo podrías desarrollar aquí por ejemplo para tener diferentes montos para emitir pero nosotros solamente pasamos un parámetro aquí entonces cada moneda que va a ser emitido para tener el mismo monto y pues los los datos privados que hemos visto la última vez en el contrato como la cuando se emite una moneda pues siempre tienes que decir para los auditors para que tienen acceso a estos datos privados donde pues una referencia al depósito y el banco donde está el efectivo que respalda esa emisión en la red y eso es una una ronda entonces una ronda es cierto callback que va a ser ejecutado en este caso tantos veces con esa transaccionalidad y lo que también puedes decir en vez de transaction number tu podrías decir transaction duration y podrías decir yo quiero que esa prueba sigue sigue haciendo ese min sigue emitiendo monedas por 30 segundos y entonces 25 transacciones más 30 segundos pues así puedes calcular el número de transacciones que esta ronda va a ejecutar para ahora pongámoslos en 100 para que no se demora tanto porque pues para que solamente son 4 segundos para ejecutar las transacciones y así eso es una ronda que puedes definir después entonces puedes definir otra ronda que es el transfer y puedes apuntar a otro callback entonces aquí puedes crear otro callback para hacer el benchmark de otra transacción en tu chain code o puedes crear otra ronda para el redeem y entonces apuntar al redeem como tal pues es para la prueba solamente puedes crear un callback que solamente vamos a probar una transacción pues hacer el benchmark in the means pero pues aquí ustedes pueden crear lo mismo para redeem para transfer y así ejecutar todas las transacciones en un lanzamiento pues de caliper aquí pueden especificar cosas del monitoreo y de los observers entonces tiene que estar como estamos teniendo una red local caliper va a sacar las métricas de las comprendes localmente pero si tu desplegues un servidor de prometeus pues tu podrías configurar que los peers de la red pues todos los no de la red pues que este servidor de prometeus colecciona todas las métricas de los no los como tal y que caliper publica sus sus métricas pues a ese servidor de prometeus y que también entonces observa ese servidor de prometeus para sacar pues si todas las métricas y puedes especificar lo que lo que quieres monitorear entonces en este caso quiero monitorear pues todos mis contenedores de docker de la red mis peers, mi order y pues aquí tu podrías especificar cual es exactamente que eres monitorear pero vamos a decir que queremos monitorear todos los docker pues en mi máquina para ver que tan pesado es para ellos escutar pues esa carga de transacciones otra vez cuando usas prometeus para colectar esas métricas de los peers y que configurar prometeus aquí pues en esta sesión no tengo prometeus pues desplegado pero podemos hacer otra workshop en el futuro con en que si tenemos un desplego distribuido y en que tenemos a servidor de prometeus colectando pues todos los y así podrías usar el lenguaje de prometeus para ciertos queries por ejemplo para sacar pues más métricas más personalizados porque aquí como van a ver ahorita lo que calibre por defecto saca es muy básico entonces si tu quieres métricas más más personalizados o una mayor candidata métricas tienes que sacarlos de los peers mismo porque cada peer tiene su servidor de prometeus donde sacarles las métricas y entonces podrías decir por ejemplo cuánto duro un endorsement con estos queries aquí lo puedes definir pues eso es el lenguaje de queries de prometeus y pues eso lo podemos hacer en otro workshop en el futuro de pronto pero listo entonces eso es como el escenario solamente una ronda del mint y el mint entonces va a tener en su pues va a recibir todos los argumentos los argumentos son los los que paso aquí y cosas que puede hacer en el init entonces ya obtener los target peers entonces yo necesito los peers de la organización del mint y del receiver porque solamente ellos tienen que pueden conocer la información los datos privados por ejemplo puedo guardar cada valor de los argumentos aquí en como variables pues globales para que los puedo usar también en mi función run aquí entonces eso hago aquí simplemente sacar cada parámetro de los argumentos aquí y guardar globalmente para que los puedo usar en el run lo que también voy a hacer es como vamos a hacer una emisión a cierto receptor pues de cierto mint a cierto receptor lo que voy a hacer es configurar el trust line, yo creo que en el chain code no validamos esa trust line en el momento de la emisión pero si deberíamos deberíamos hacerlo pero pues para mostrarles como se podría usar el init function aquí lo que voy a hacer es aquí hacer la transacción para configurar esa trust line entonces aquí voy a decir que voy a usar la transacción esa trust line de ese contrato y aquí pues tengo que especificar cuál pues el nombre del contrato que en este caso es USD currency contract tengo que decir quién tiene que enviar esa transacción y como el receptor tiene que decir en quién confía usar la identidad del receptor que es el client de organización dos organización dos del receptor esa identidad va a generar esta transacción aquí y los argumentos para el set trust line en el chain code es decir de quién quieres recibir entonces aquí en este caso organización dos quiere recibir de organización uno tiene que ponerlo en true para decir que confía y pues el monto que quiere recibir es ilimitado y los target peers pues también son pues aquí lo especifico pero realmente no están necesarios aquí se podría borrar y ya voy a ejecutar pues esa transacción con los argumentos generados aquí y pues esperar esperar que no hay ningún error para que los pruebas pueden seguir como hago esto en el init entonces significa que todo esto enviar esa transacción no va a ser contado como como tiempo pues el tiempo no va a ser contado para la ronda porque cada worker solamente hace esto una vez y después ya no lo pues no lo hace por cada no lo hace por ejemplo cien veces no solamente cada worker lo hace una vez para iniciar para hacer estas cosas de iniciación y ya no más entonces lo que también solamente voy a hacer una vez es el generar el private data entonces si lo recuerdan todavía de la sesión pasada el private data del means tiene que tener esto nombre pues del campo y tiene que tener un objeto con cualquier objeto realmente en este caso con esos parámetros de project reference y bank vamos a pasar y tiene que ser con el bytes un bytes array entonces lo convertimos aquí con esto y ya listo lo guardamos también globalmente para que en el run que es la carga real vamos a podemos usarlo sin tener que generarlo por cada transacción que caliper que el worker load va a enviar a la red listo entonces si lanzamos ahora caliper lo que va a hacer es enviar esa transacción cien veces a la red con una velocidad 5 transacciones por segundo y eso es realmente estos tres archivos para configurar el run time la red, el network y ya el benchmark como tal que tiene la configuración pues como los escenarios y el callback que es similar pues al programar un SDK para enviar transacciones listo entonces la hora para para correr entonces aquí se apuntan entonces a todas esas configuraciones especificamos otra vez que solamente tiene que hacer la fase del testing nada de instalar chen code porque eso ya existe usar el gateway usar discovery entonces esperamos que todo va bien entonces lo que aquí está haciendo es conectándose con la red desplegando los tres workers que pedimos hacer el init la inicialización crear los billeteros pues de las identidades que tiene que usar aquí está preparando el mint y aquí empieza a submitir pues a enviar transacciones y aquí puedes ver entonces envió ya 99 transacciones aquí a 30 ya terminaron dos fallaron por alguna conexión y ya más o menos en 4 segundos terminó pues esta ronda escenario que hemos especificado y lo que generó pues aquí en el comment pues en el terminal ya de los ciertos resultados por ejemplo el nombre de la ronda cuantas transacciones fueron exitosos en este caso dos fallaron por algún error aquí que tengo que revisar aquí dice que no recibió el evento nos puede ser que que pasó un time out o que había alguna conexión con un pier que no funcionaba por un momento pero después los otros sí fueron enviado escritosamente el raid como habíamos especificado tenía que ser 25 pues más o menos lo ha acercado aquí con los workers aquí dice aquí habla de la atención que tenían las transacciones el tiempo máximo que tomó una transacción para finalizar fueron 18 segundos el mínimo 10 segundos y promedio una transacción para finalizar tomó tanto tiempo y el throughput entonces al final no era similar a esto pero 4.9 que es muy bajito pero eso es porque estamos corriendo todo localmente donde los piers pues tienen que compartir recurso también en esta red solamente tenemos un pier por raniación que en una red productivo normalmente cada raniación va a tener tres anchor piers otros piers que no son anchor piers entonces todo ese trabajo normalmente en una red de producción va a estar compartidos sobre diferentes piers que van a ser los endorsements en paralelo y por eso también es importante el modelo de UTXO porque si hubiéramos hecho esa prueba con un modelo de cuentas y no con UTXO entonces probablemente tendríamos muchísimas transacciones fallidos porque todas las transacciones intentarían escribir a la misma cuenta al mismo tiempo y eso hubiera dado problemas de concurrencia mientras que aquí solamente dos fallidos y 97 exitosos pues en ese tiempo y los fallidos no fueron por problemas de concurrencia pero algo de conexión creo que de los timers de los eventos y eso es como la información básica de Kaliper genera pero también generó un reporte ese reporte lo podemos lo podemos hacer como es que voy a abrir aquí entonces aquí es el reporte completo de Kaliper pues cuando usas prometeos puedes tener muchos más métricas pero aquí solamente usamos pues el reporte por defecto de Kaliper entonces tiene el mismo resultado de la carga y cuál fue el throughput final aquí pues lo que hizo el fixed rate con 25 y aquí podemos ver entonces los recursos que fueron utilizados y cada contenedor cuánto cpu por ejemplo uso para estas pruebas entonces podemos ver que el cpu es más alto en los orders eso es porque todos los orders aquí los orders tienen que procesar todas las transacciones entonces como el punto más como el bottleneck no sé cómo se dice en español pero donde pues cada transacción tiene que ser procesado por cada order entonces por eso seguramente lo tienen más duro los peers tienen que escutar las transacciones al chaincode como hemos enviado la transacción al pier al pier de organización 1 y de organización 2 y no a organización 3 porque no queremos queríamos combatir los datos privados a organización así pueden ver que el chaincode realmente de organización 3 no estaba haciendo casi nada fueron los dos chaincodes de organización 1 y de organización 2 que estaban escutando las transacciones mientras que de organización 3 no estaba haciendo nada y si pueden ver el memoria que estaba usando ese contenedor el traffic in, traffic out y pues otros métricas que caliper por el efecto colección pero pues cuando usan prometeos pueden sacar muchísimo más métricas, esto es muy básico y pues espero poder hacer un workshop más más extenso porque hay muchos más métricas pues para sacar de una red de fabrico pero espero que esto ya fue como un inicio ustedes mismos van a experimentar van a crear más callbacks a extender los escenarios pues esto fue como una introducción por casi podrían automatizar muchísimo sus pruebas y por ejemplo ahora cada vez que cambiamos algo en el chaincode lo que hicimos fue usar el comment line para probar si pues para probar el cambio mientras que si tu configuras todos tus transacciones con callbacks aquí podrías lanzar calliper y calliper hace todas las pruebas que tu quieres hacer y puedes ver si las transacciones están fallando puedes ver el error porque fallaron en el caso que es un error en el chaincode y pues también lo vas a ver aquí y así no puedes no tienes que hacer esos comandos para ejecutar funciones en el chaincode como estamos haciendo en la sesión anterior podrías hacer todo automatizado cada vez que hiciste un cambio que simplemente quieres hacer pruebas pues de tu chaincode y de tu red eso puede ayudar mucho con la automatización listo eso fue como el demo fue corto y básico pero espero que todos entiendan un poco más de cómo usar esa herramienta y pues Camilo va a hacer también un serie del curso pero yo les quiero dar un poco más fuentes de información todavía o los fuentes de información que yo he usado porque eso también fue una pregunta pues de Camilo de cómo ha sido ese trayecto trayectorio para la aprendizaje realmente para mí entonces pues siempre está la documentación oficial que ya deberían conocer y también pues otra vez decir que la comunidad está traduciendolo a español entonces también ciertas partes ya están disponibles en español entonces también eso es como el primer recurso donde podías ir cuando quieres aprender o tienes dudas luego el rocket chat que también ya deberían conocer en diferentes canales pueden hacer preguntas muy específicos y pues los contribuidores al fábric como tal te van a presentes ahí también otra cosa que es muy útil es inscribirse a los mailing lists entonces pueden ir a esta página para inscribirte al mailing list de fábric o a cualquier proyecto o working group de Hyperledger que te interesa y así recibes las conversaciones que se están teniendo a través de esos lists en tu coreo y puedes aprender mucho solamente leyendo lo que otras están encontrando problemas o lo que otras están intentando hacer es muy muy informativo pues luego también hay muchos papers sobre todo pues IBM que fue el contribuidor inicial y más grande pues de fábric hasta acá muchos papers y un paper que a mí me ayudó mucho fue donde explican la lectura y el flujo de execute order validate que es diferente a otros blockchains y pues aquí en esta enlace pueden encontrar el paper es un paper muy pues grativamente viejo ya creo que el 2018 cuando por primera pues cuando lanzaron la versión uno creo que apenas pues empezó con este flujo de execute order validate pero todavía pues está todavía usa ese flujo entonces el paper todavía es muy relevante y creo que si todavía no fue completamente claro ese flujo de llegar a consenso realmente ese paper les puede ayudar mucho a entenderlo más profundamente y luego pues todos los repolitores en github de fábric mismo los samples si quieren escribir chaco ten go el librería básico y el contract api chaco ten go todos los repolitores hasta todos los otros proyectos de hyperlegger y caliper por ejemplo también está en github entonces ahí también siempre pueden encontrar pues la colegio fuente sobre todo y eso puede ser muy útil también en su aprendizaje y yo creo que Camilo va a ser más de la alimentación sería muy muy bueno pues conocer de ustedes como ha sido la experiencia en el curso sería muy falloso pues tener su retro de alimentación y si pues les diría quedamos en contacto y sobre todo en rocket chat creo que es el medio más fácil para hablar y ayudarnos entre todos pues entre toda la comunidad y seguir proponiendo nuevas iniciativas y pues siempre pueden contactar también a través de LinkedIn o mi correo y eso fue para mí la sesión de hoy y muchas gracias a todos y felicidades por haber terminado este curso juntos con nosotros muchas gracias Brann muchísimas gracias me quiero dar el día de hoy al igual que Ricardo por haber dado este primer paso en ese proceso de enseñarle a nuestra comunidad sobre Hyperledger Fabric que era uno de los iniciativas de nuestra comunidad ayudar al entendimiento del proyecto Hyperledger también para eso hacemos los diferentes seminarios los diferentes webinar de casos de uso y pues es impresionante es invaluable poder contar con la experiencia que ustedes dos tienen y poder seguir trabajando con la comunidad bueno también Claudio Ceballos que nos estuvo acompañando en sesiones anteriores respondiendo sus preguntas y antes de anunciar el tema de certificado asistencia y el bono de descuento para las certificaciones de Hyperledger nos gustaría que se motivaran a hacernos sus preguntas para activar los micrófonos pueden levantar la mano y yo con mucho gusto les habilito los micrófonos mientras tanto Ricardo no sé si tienes algo que hacer con todas las personas que nos acompañaron durante estas 11 sesiones que parecía un gran reto pero bueno estamos aquí con mucho conocimiento muchísimo entusiasmo y ganas de seguir aprendiendo y practicando entonces Ricardo no sé si quieres decir algo mientras que las personas nos envían sus preguntas o levantan la mano aquí en Zoom por favor pues gracias Camilo para darle exclusivamente Bram pues muy gracias por el esfuerzo que lo colocaste sin duda pues como lo decíamos el proyecto de tener el capítulo latinoamericano de Hyperledger tenía varios desafíos del inicio uno de los cuales era lograr que las cosas comiencen a suceder lo más importante de esto ha sido que en el camino hemos encontrado con varias personas muy potentes técnicamente pero principalmente con una apertura para poder compartir sus experiencias y conocimientos que va enriqueciendo mucho a la comunidad y en general a la comunidad hispanohablante no sé si es latinoamericana sino también española ha sido muy constante en las decisiones a pesar de la diferencia de horario y les puedo decir pues yo creo que debemos gracias a ustedes porque la verdad que ustedes han llegado a este punto es de los valientes han sido varias semanas de muchísimo trabajo así que sin duda esperamos que esa curva de aprendizaje haya sido superada creo que en este punto tienen todas las herramientas para poder avanzar por propia cuenta o de manera colaborativa manteniendo los conectados en comunidad les quiero invitar a que no se desconecten de la comunidad porque este es uno solamente es la inauguración y de un programa de estudio un programa de superación profesional que estamos propiciando desde hyperlegia latinoamerica van a venir varios programas adicionales que van a complementar todo el agua y todas las tecnologías que nos ofrece hyperlegia pues básicamente eso Camilo, agradecerte por la coordinación sin duda ha sido elemental lograr apoyarnos en ti por haber coordinado varias cosas y que son esenciales es que van más allá de colocarnos frente a la cámara y el micrófono y mostrar los warships así que agradecido con los co-leaders de los diferentes países de hyperlegia donde estamos con los cuales estamos trabajando eso Camilo Perfecto Ricardo, entonces antes de despedirnos vamos a anunciar los siguientes webinar que tenemos queremos reforzar y ahorita estaba viendo que en la sesión de Q&A hay preguntas respecto al tema de traducciones entonces también vamos a hablar al respecto y mientras tanto yo les voy anunciando me gustaría escucharlos nos gustaría que nos dieran su feedback y queremos habilitar los micrófonos pero mientras que el primer voluntario o voluntaria porque también es maravilloso para nosotros contar con las mujeres que están en la industria de blockchain inclusive estamos planeando hacer el primer conversatorio de hyperlegia latinoamerica de mujeres en blockchain que nos cuenten sus experiencias con hyperlegia entonces nos pueden contactar a través de rocket chat para poderlas invitar a este espacio mientras tanto nos vamos a invitar el próximo miércoles 30 de septiembre junto con Alfonso Govela vamos a hablar sobre blockchain y en el cambio climático del mercado de la energía va a ser más que toda una masterclass en el que nos va a hablar de su experiencia como asesor de la ONU y de diferentes organizaciones y vamos a setear como el concepto para que más adelante no tuve o en noviembre podemos hacer una presentación sobre los casos de uso en la industria creo que Ricardo, tú nos vas a estar acompañando en esa presentación de los casos de uso que nos cuenten de tu experiencia porque finalmente hemos traído casos de uso de grandes empresas pero también queremos visibilizar los emprendedores entonces Ricardo tú nos vas a presentar lo que has venido haciendo es blockchain Claudio nos va a presentar lo que ha hecho Connerre y Javier Salomon nos va a contar lo que ha venido haciendo para el desarrollo de oráculos entonces queremos extenderle esta invitación a toda la comunidad les voy a copiar por el chat en este preciso momento la invitación al webinar para que se puedan registrar y adicionalmente a las personas que están interesadas en todo el tema de traducciones teniendo en cuenta que este es un proceso en el que tenemos que seguir un patrón definido desde Hyperledger directamente donde ellos nos sugieren que primero se tengan que dar de alta en esta página de el grupo de traducciones de español pero para simplificarles el ejercicio les voy a compartir en este momento y en un momento se los envío por el Rocket Chat el link para que por favor las personas que estén interesadas en seguirnos contribuyendo nos den su nombre, su color electrónico y su usuario de github para darlos de alta en este grupo y después poderlos vincular oficialmente al proyecto de traducción al español yo sé que a ratos es un poco tedioso tantos procesos pero pues son las directrices que ellos nos recomiendan para garantizar que el proceso de traducción se de la mejor manera y finalmente como ustedes lo saben somos varias personas que vamos a estar interactuando con el repositor y no queremos en ningún momento comprometer la integridad del mismo por eso nos aconsejan poder seguir esos paso a paso entonces ahorita abcién tienen preguntas de traducciones con muchísimo gusto personalmente en el canal de traducciones que es y 18 en español para las personas que se quieran sumar vamos a estar agendando para el próximo jueves en este mismo horario lo vamos a llamar como un webinar de interacción en el proceso de traducción todas las personas que estén interesadas los invitamos porque vamos a estar haciendo el fork del repositorio y en el tiempo real les vamos a estar atendiendo sus dudas o inquietudes porque finalmente este es un proceso que va a contribuir mucho en lo que queremos lograr con Hyperledger Latinoamérica también los invito a que se puedan unir a la lista de correos ya en un momento les comparto todos los enlaces y si ustedes vienen aquí a la parte inferior donde dice suscribir al calendario este calendario lo pueden agregar les voy a compartir un momento mi calendario de Google aquí en la parte inferior en otros calendarios desde URL lo importan y el automáticamente les va a traer todos los eventos que estamos agendando desde Hyperledger Latinoamérica entonces por ejemplo el 19 tenemos junto con IBM el webinar sobre IBM Futros vamos también planeado y por definir un webinar con Boston Scientific donde nos van a contar el caso de uso para la trazabilidad insumos médicos IBM Futros va a hablar sobre la trazabilidad de alimentos y también una vez más y siempre les hago la invitación a que ustedes nos puedan contactar a través de RocketChat si conocen algún caso de uso que estoy utilizando Hyperledger que nos puedan referenciar porque para nosotros va a ser muy enriquecedor poder construir de la mano de ustedes entonces esos eran los anuncios generales con respecto a lo que se viene para Hyperledger Latinoamérica así como lo decía Ricardo estamos comprometidos y queremos poderles ofrecer mucho más contenido de calidad en el cual ustedes puedan crecer los temas de Blockchain y Hyperledger particularmente y una pregunta que me hicieron respecto a que va a pasar con el certificado de asistencia y que va a pasar con el bono de descuento resulta que como este era un seminario que no requería inscripción durante las próximas dos semanas junto con el equipo Hyperledger Latinoamérica vamos a estar revisando el registro de asistencia que nos reposa en nuestro base de datos vamos a empezar a consolidar las asistencias que ustedes tienen y aquellas personas que hayan cumplido con más del 70% de participación en las sesiones en vivo pero ojo Zoom también nos reporta el tiempo de permanencia en la sesión entonces vamos a tener en cuenta estos dos parámetros para poder emitir ese certificado de participación o de asistencia de este curso abierto de Hyperledger Latinoamérica y a vuelta de correo a esas personas que hayan cumplido con el 70% perdón con el 70% se les emite el certificado de asistencia y los que hayan cumplido con el 80% adicionalmente les vamos a enviar por correo el bono de descuento del 30% para las certificaciones de Hyperledger el bono tiene una validez de dos meses a partir de hoy entonces tienen dos meses para reforzar, para repasar para volver a ver los vídeos que ya subiremos en esta semana el canal de youtube y puedan presentar la certificación de Hyperledger veo que tenemos algunas preguntas por el chat, no sé si si Ricardo Obran las revisamos si me parece super importante revisarlas he encontrado algunas preguntas de gran valor y también tengo aquí algunas también que fui anotando yo a medida que fue avanzando pues no se verán si nos permiten eso sería transmititelas bueno entre las que fui anotando como tal pues Kaliper resulta ser una herramienta de tipo cliente que termina usando en este caso el SDK de Fabric concretamente el Gateway del SDK de Fabric es así Ybrao si por debajo usa SDK en the notes tiene Fabric para conectarse con la red realmente el adapter de Kaliper usa el SDK de notes de Fabric para enviar las transacciones a la red otra pregunta en este caso las estadísticas que va a ir colectando Kaliper son las estadísticas relacionadas en los tiempos de respuesta que obtiene el cliente que está usando otras bambalinas del SDK sería igual a usar una herramienta como Jameter que termina usando un cliente o una aplicación que usa el SDK de Fabric si, si también puedes comprarlo con esto solamente que aquí entonces tu está hecho específicamente para blockchain entonces puedes confiar todas esas estrategias para confiar la finalización o la transacción pues tiene muchas cosas más por defecto que son útiles para una red de blockchain que otras herramientas para pruebas de carga si buscan otra adicional relacionada al curso más bien a la excesión del día de hoy luego de pasar las que son un poquito más generales por acá vemos en el chat porque no hay tantas preguntas muy específicas cuando tú hablas de Misha's broker, estabas hablando en concreto de la implementación de MQTT, ¿no verdad? si, eso era así ¿podrías hacer algo así como CAPCA o por ejemplo MQ broker de IBM? no estoy seguro pues como es modular, yo creo que así se podría pero no sé si yo creo que por defecto solamente está soportado MQTT en este momento pero como es modular pues y open source todos podrían generar sus propios módulos que sí permiten conectarse con otros brokers pero por defecto creo que es MQTT solamente para el despliegue de los brokers y los managers tú hablabas de que en general lo que se termina usando ahí es un cluster de Kubernetes es así y si es que así es posible usar algún tipo de herramienta distinta por ejemplo OpenShift o Docker Swarm si también es posible si es simplemente porque los brokers después de haber que ellos se terminan es como un proceso que solamente se suba y oculta la carga que reciben pues del manager y termina el proceso entonces no son servicios que están corriendo siempre pero entonces por cada prueba por cada escenario quieres hacer deberías desplegar otra vez los brokers entonces sería más fácil con un proceso de despliegue automatizado como Kubernetes o OpenShift pues que por debajo es Kubernetes entonces sí, eso es más fácil para no tener que manualmente desplegar los brokers después de cada lanzamiento si otra pregunta toda la carga que tú enviaste a través de Kaliper que era finalmente grabada en la blockchain de Fabric verdad? si, si si miramos por ejemplo KGB aquí podemos hacer que realmente todas las transacciones quedan en el KGB entonces la idea es que apuntas Kaliper pues a tus ambientes de desarrollo y tu ambiente de certificación pero pues no a producción porque como pueden ver aquí se generaron pues esas transacciones se generaron realmente en la red entonces si pues no es recomendado creo apuntarlo a producción porque va a crear transacciones de prueba en producción pero en tus ambientes de certificación sería pues útil para saber cuánto aguanta pues tu red de cargas y para automatizar pruebas en desarrollo también eso me lleva a una pregunta súper importante que normalmente sucede en instalaciones productivas cuando nosotros hacemos benchmark y de las soluciones ya sea blockchain o blockchain por lo general en el display de la infraestructura y los componentes los ambientes previos a producción a pesar que pueden llegar a tener entre comillas las nuevas configuraciones o intentas replicar por lo general algún tipo de similitud sabemos que en la práctica no son lo mismo ya sea por limitaciones de infraestructura o por limitaciones de costos no lo que suelen reducir en tamaño o incluso aquellos ambientes que suelen ser muy similares en la práctica suelen responder de manera distinta eso es muy muy común por lo tanto una prueba sobre un ambiente productivo en la infraestructura por lo general el comportamiento del ambiente productivo y es muy común hacer pruebas sobre ambientes productivos para poder determinar efectivamente la capacidad transaccionada de este sistema en concreto lo que estoy diciendo es como logramos nosotros purgar o sanitizar los datos que queda en la blockchain de un ambiente productivo cuando efectivamente va a ser necesario usar Kaliper para estos efectos sobre un ambiente productivo si ahí entonces podrías implementar en tu chain code las transacciones para limpiar por ejemplo esos monedas que hemos emitido en la función como el end del benchmark o en el script final podrías ejecutar transacciones que van a limpiar monedas emitidos por ejemplo pues en este caso si podrías usar prácticas pues para limpiar las emisiones o lo que has hecho pues en las pruebas si, es verdad estoy con otra pregunta por acá no me quiero oír sin antes saludar al menos a las personas que se animaron a chatillar el día de hoy y a emitir sus preguntas sé que han llegado cientos de personas del curso la verdad un compromiso importantísimo y nos sentimos muy muy graciosos con ustedes pero dado que hay muchas personas me quiero ir sin saludar a los que se animaron a chatillar así que si me permites Camilo a José Angel Noguera a Sofía Quiñones Casas, Ameciniano García Daniel Altamirano Víctor Manuel Ojeda Adrián Pataña, William Parra parte de la superactivo y parte de la comunidad Antonio Blanco Ángel Adolfo Parrales Ezequielosa que genial por acá también tenemos a Sergio Martínez, Alvaro Bedolla y Carlos Restrepo y claro como siempre de mi lado pues un enorme saludo a todos ustedes, también saludar a Lucio Canche que me ha sido muy divertido ahí en el chat ayudando al resto tengo ahí unas preguntas que no necesariamente son de Kaliper por lo que puedo ver así que en general no las voy a incluirle voy a dejar ahí a Camilo que si ves perdiente mencionarlas o no pues no se Camilo todo tuyo el micrófono Ricardo pues siento que estoy como emocionado y triste a la vez emocionado por estas 11 sesiones y triste pero por la sesión de hoy porque ya se acaba esta primer ciclo, es como triste y feliz y en simultánea agradecerles infinitamente a ustedes que nos apoyaron en este primer curso abierto para toda la comunidad seguir incentivando a todos que nos apoyen a crecer queremos crecer como comunidad queremos traer contenido de calidad para ustedes hoy ninguno nos quiso dar su comentario con el micrófono abierto entonces no lo pueden enviar a través de Rocket Chat, ah mira Nelson Bermudez se animó, vamos a darle la palabra Nelson y nada habrán infinita agradecimiento para ti para Ricardo, lo va a hacer la palabra Nelson Nelson ya puedes habilitar tu micrófono si me escuchan si señor como están muy buenas tardes noches para todos primero que todo estoy muy contento por estas iniciativas yo ya llevo más de 15 años en el nivel profesional trabajando con telecomunicaciones y desde la universidad vi pues creci con Ubuntu y creci viendo las vontades del escuadr libre y este tipo de iniciativas que son de comunidad de comunidad abierta donde he visto el crecimiento de Hyperledger desde que lo conocí como un proyecto que arrancó en 2013 creo y lo empecé a ver en la flisol en Bogotá en el 2018 a mi me pareció muy bueno y muy bueno que se pudiera tener cursos en español que tuvieran que te caterricen a la tecnología Hyperledger, cuando lo vi en la flisol muy etéreo, no lo vi tan cerca a las soluciones empresariales no lo vi aplicado correctamente pues en un escenario real ya con el tiempo y viendo lo que ha hecho en Colombia y lo que ha hecho Telefónica y lo que han hecho otras empresas veo una evolución muy buena para Hyperledger y es el primer curso en español que veo por fin puedo aterrizar los conceptos con las máquinas virtuales que tengo y ha funcionado muy bien los laboratorios, muy bueno el curso en ese sentido, los felicito felicito a los a las personas que dieron el curso me parece espectacular lo que vi y pues la idea es seguir adelante hay una idea muy buena en Telcos que es hacer el tema de roaming utilizó Hyperledger hay tres proveedores grandes haciendo esa labor pues la idea es que muy poca gente de Telcos conoce esta tecnología y yo creo que sí sería muy bueno que gente que se dedica a roaming, que se dedica a hacer la curaduría de los CDR entre operadores hacer las conciliaciones de pago entre operador utilizando esta tecnología se puede hacer y creo que es una muy buen gancho para este producto yo me llevo esa imagen y a las personas que tengo conocidas en el medio les voy a empezar a publicar este curso no tengo nada más que decirle a ustedes gracias Nelson, muchísimas gracias es gratificante para nosotros escuchar lo que nos dice respecto al curso finalmente como lo hemos venido recalcando este era un ejercicio y era un reto era un reto para nosotros tener un curso abierto en el que podían participar centenares de personas pero poder transmitir un contenido de calidad y éramos conscientes de que en español no existía ese material que nos ayudara en esa curva de adopción inicial y antes de darle la palabra Daniela Altamirano una pregunta que ve hace un momento en el Chádez ustedes, Ricardo Yuran por qué nos aconsejarían certificarnos en administrador de Hyperleger Fabric o en alguna de las tecnologías de Hyperleger qué oportunidades ven al certificarnos yo creo que primero es una buena prueba para ver si el contenido de este curso y lo que están aprendiendo por si mismo pues como una prueba por ustedes mismos realmente para ver si ya están en la capacidad de aplicarlo y realmente como medir su nivel una buena oportunidad con el descuento sobre todo pero también realmente estamos en Colombia por ejemplo siempre estamos buscando talento que es muy difícil de encontrar todavía todavía no hay mucha gente que ya tienen experiencia real con Hyperleger o con Hyperleger Fabric en nuestro caso y por eso también eso era como una de las motivaciones que dales este curso realmente para crecer ese grupo de talentos que se pueden que podemos pues espero que hemos podido pues contribuir a esa y si pues nosotros por ejemplo siempre estamos abiertos ahí buscando pues a personas que tienen conocimiento y de los casos de usos que se han presentado en la comunidad pues hay muchas oportunidades pues laborales realmente muchos casos de usos y como todavía es nuevo pues ustedes pueden ser todavía unos pioneros con casos duros muy interesantes que se están desarrollando entonces yo les recomiendo tener esa certificación como prueba de lo que de su conocimiento realmente y para ser muy útil para encontrar oportunidades laborales que se pueden ser genial, y tu Ricardo pues si pues yo creo que ningún tipo de documento título en realidad dice el talento real que cada uno de los individuos tenemos sin embargo hay que ser conscientes de que en la práctica a pesar de pronto las convicciones personales y la capacidad que tengamos cada uno de nosotros pues el mercado funciona de esa manera el mercado está demandando o de alguna manera intenta verificar eso a través de certificaciones de alto valor como las que entrega Hyperlegger y empresas similares entonces en la práctica me parece que es un muy buen camino para poder como dice Bran medirte y chequearse efectivamente te hace falta algo pero en la práctica pues te va a llevar a ser más competitivo profesionalmente me encontro con muchas personas del área de informática especialmente que están buscando mirar hacia otro hacia otro lado donde poder especializarse donde poder ser más competitivos me parece que ahora seguimos navegando en un océano azul donde puedes tu llegar más tempranamente mejor preparado y posicionarte profesionalmente en el ámbito o estés trabajando de igual manera empresas como la mía estamos buscando continuamente talento de hecho nosotros invertimos mucho tiempo en capacitar a otros ingenieros para que adquieran experiencia real para que adquieran conocimiento real y ejecuten eso sobre los proyectos que ejecutamos y claramente una de las decisiones que sin duda nosotros consideramos es efectivamente estas tienes algún tipo de certificación porque en la práctica nuestros equipos trabajan para otros clientes que nos demandan ese tipo de temas así que deberías aprovechar esa oportunidad no va a estar disponible para siempre tiene un tiempo de caducidad así que a seguir trabajando que esto no acaba el día de hoy es todo un montón de trabajo todavía por probarte y confiamos en que tu eres capaz de lograrlo y si no estamos aquí para seguir apoyándote Muchísimas gracias Brani Ricardo por aclararnos y alentarnos también es como un reto poder superar esta certificación y valiar efectivamente cómo nos fue en este proceso de aprendizaje en el curso invitarlos que sigan practicando por su propia cuenta realmente si aprendes ya en la práctica que creen sus pruebas de concepto que creen esos casos de uso le voy a dar la palabra Daniela Altamirano pero los motivos tenemos máximo 10 minutos más para que podamos interactuar una vez más las personas interesadas en el tema de traducciones en este mismo horario vamos a ser como un webinar explicativo de todo el proceso pero vamos a interactuar con ustedes en tiempo real para que puedan hacer todo el tema de traducciones Daniel ya puedes habilitar tu micrófono Buenas noches con todos y bueno la verdad es que solamente quisiera decirmente cuánto aprecio el gran supongo que definitivamente igual que yo nos ha tocado sacar el tiempo de otras actividades para poder dedicar a esta iniciativa en mi caso claro ha servido para evaluarme y poder ver bastantes partes del conocimiento que me hacen falta y bueno, aun cuando no entendía varias cosas sinceramente pero el deseo de realmente aprender y ver como esta es una tecnología que promete muchísimo realmente me ha motivado a poder aun cuando muchas cosas no he entendido a seguir estudiando, a seguir leyendo y a poder seguir tratando de participar gracias por el esfuerzo de ustedes y realmente me motiva mucho el poder saber que va a haber unas más iniciativas en el futuro claro tendremos que cada uno seguir el esfuerzo además también por hacer un autoridad sin embargo pues realmente todo lo que promete esta tecnología no solamente va desde un aspecto netamente comercial porque aun cuando sí es cierto que uno quiere también buscar una nueva tecnología para asegurarse un trabajo también lo que me gusta mucho de todo lo que implica blockchain es que es una tecnología que busca una igualdad ideales muy éticos entonces eso también me gusta muchísimo y por eso le felicito a ustedes por esta buena iniciativa de todo muchas gracias Daniel muchísimas gracias a ti y a todas las personas que nos estuvieron acompañando durante estas 11 sesiones para nosotros es un motivo más para seguir trabajando y seguirnos esforzando para traer más contenido español para poder visibilizar las oportunidades y los emprendimientos de muchos de los que hacemos parte de esta comunidad y nada pues les agradezco infinitamente no sé Ricardo si quieres dar unas últimas palabras van en unas últimas palabras antes de finalizar esta sesión número 11 hace un momento una pregunta en que consiste el proceso y programas certificación les voy a compartir el link de Linus Foundation donde está como la descripción de la certificación y ahí pueden encontrar más detalles entonces mientras tanto Ricardo Ibrán unas últimas palabras para finalizar oficialmente nuestro curso muchas gracias Camilo y no muchas gracias para todos los participantes todos han continuado en las sesiones prevenciales hasta esta sesión y nos vemos pues en el chato esperamos en algún proyecto o en otras iniciativas de la comunidad y muchas gracias a todos si de alguna manera para mi un agradecimiento por mi parte continuo trabajando desde la República América un enorme saludo a toda la comunidad disponible que bueno que este idioma nos una y que haya permitido compartir estos gratos momentos seguimos trabajando para seguir avanzando hacia el blockchain empresarial que desde la República América y España necesitamos un abrazo gigante muchísimas gracias a todos a la República América los invito a que nos sigan acompañando que sigamos superactivos en Roque Chat que finalice el curso y nos significa que finalizar las interacciones por favor apoyémonos entre todos porque muchas veces Branza acá de su tiempo y responde a muchas de las preguntas que ven en Roque Chat lo mismo Ricardo y todos tratamos de interactuar pero no dejemos morir esto tan bonito que ya surgió los estaremos invitando a próximos eventos muchísimas gracias que tengan una muy feliz noche hasta luego