Introducción a

Blockchain
Ponente
◎ M.C.I.C. René Adrián Dávila Pérez
◎ Profesor de Asignatura
◎ Facultad de Ingeniería
◎ Campus Champion – Algorand Foundation
◎ 2 Años de experiencia en Blockchain
◎ 2 Años de experiencia docente
◎ 10 Años de experiencia profesional
◎ 2 Artículos publicados
Temario
◎ Sistemas Distribuidos
◎ Blockchain
◎ Protocolos de Consenso
◎ Hyperledger Fabric
◎ Algorand
◎ Contratos Inteligentes
◎ PyTeal
◎ Beaker
◎ Aplicaciones Descentralizadas
◎ Desarrollo de DApp
Requisitos técnicos
◎ Python 3
◎ Editor de texto
◎ Docker
◎ Windows Enterprise/Education/Professional
Sistemas
Distribuidos
 ¿Qué es un sistema
distribuido?
Un Sistema Distribuido es una colección de
entidades que cooperan para resolver un problema
que no puede ser resuelto por una sola entidad.
En computación, es un conjunto de elementos de
hardware y software conectados a través de una red
de datos, capaz de comunicarse y coordinar sus
acciones únicamente mediante el paso de mensajes.
Características

Concurrencia Ausencia de un reloj Independencia de

global fallos
Dado que la norma dentro de Si los programas necesitan Cada componente del
un sistema en red es la cooperar deben coordinarse sistema puede fallar,
ejecución concurrente de por el paso de mensajes. Los mientras los demás siguen
programas, es necesario procesos de alta coordinación activos.
planificar la coordinación de dependen de la idea
dichos programas al compartida del tiempo en
compartir recursos. que ocurren los eventos
dentro de los programas.
Características

No comparten Separación Autonomía y

memoria geográfica heterogeneidad
Esta característica es usual en Los elementos que Los elementos de un SD están
SD, sin embargo, es posible conforman un SD pueden débilmente acoplados (es
tener memoria común a estar conectados a través de decir, operan a diferentes
través de la construcción de una red WAN o LAN, es decir, velocidades y con diferentes
“memoria compartida existe separación física entre sistemas operativos), y estos
distribuida”. los diferentes componentes. normalmente no son un
sistema dedicado.
Metas de un Sistema Distribuido

Compartir Recursos Transparente para el usuario Apertura

El usuario (humano o programa) Un SD es capaz de ocultar a los Un SD se denomina abierto

puede acceder a los recursos usuarios qué procesos y recursos cuando ofrece la inclusión de
(hardware, software, datos o de los sistemas están nuevos servicios para compartir
documentos) remotos de la distribuidos en múltiples recursos sin perjudicar ni
misma manera que a los entidades, de tal manera que duplicar a los ya existentes.
recursos locales de manera para el usuario estos parezcan
confiable. un único sistema de cómputo.
Metas de un Sistema Distribuido

Escalabilidad Heterogeneidad

Un SD se dice escalable si es El SD puede usar distintos

capaz de manejar una cantidad servicios de red, hardware,
creciente de trabajo añadiendo software, lenguajes de
recursos al sistema, siendo esto programación e
transparente para usuarios y implementaciones por
entidades del mismo sistema. diferentes programadores.
Paso de Mensajes
En un SD, el único medio de comunicación es la red de interconexión, ya que no existe un espacio de
memoria compartida para los procesos que se ejecutan en el sistema. Por esta razón la
comunicación de procesos se realiza por paso de mensajes.
Al paso de mensajes se asocia una cola (glosario) con cada destino de mensaje. Los procesos que
envían añaden mensajes a colas remotas y los procesos que reciben remueven mensajes de las
colas locales. Así podemos tener dos tipos de comunicación:

Comunicación Síncrona

Comunicación Asíncrona
Comunicación Síncrona

Los procesos se ajustan con cada mensaje, las operaciones de

envío y recepción son operaciones bloqueantes. Cuando se
realiza una operación de envío el proceso que envía se bloquea
hasta que se emite la recepción correspondiente. Si un proceso
emite una operación de recepción se bloquea hasta que llega el
mensaje. Puede suceder también que la operación de
recepción sea una no bloqueante (se le permite proceder
cuando se ha copiado el mensaje en el buffer local y la
transmisión del mensaje procede en paralelo con el envío).
Comunicación Asíncrona

En este caso, cuando el emisor llega a la instrucción en la que se

produce el envío, no se bloquea a la espera de que el programa
destinatario llegue a la instrucción en que lo recibe, sino que sigue
ejecutándose con normalidad. Por otra parte, el programa receptor
recibirá el mensaje en cualquier momento posterior al envío sin
frenar con esto al emisor hasta que la recepción se produzca. Pero
si el receptor ha llegado a una orden de recepción de mensaje pero
el emisor aún no ha enviado nada, el receptor sí se bloqueará a la
espera de que el emisor realice el envío.
Paradigmas
Cliente-servidor

Multi-hilos

Punto a punto

Llamada a Procedimiento Remoto

Comunicación cliente-servidor
Es un modelo de comunicación en el que las tareas se reparten entre los proveedores de
recursos o servicios, llamados servidores, y los demandantes, llamados clientes.

Servidores Clientes
Son procesos que son procesos que solicitan un
implementan un servicio y servicio a los servidores a
siempre están a la escucha de través de una petición y
peticiones provenientes de esperan por una respuesta
una IP y puerto específico. del servidor
Modelo Cliente
- Servidor
Use big image.
Ejemplo 1
Comunicación
peer to peer
En los sistemas punto a punto (peer to peer,
en inglés o P2P) los servidores dedicados y
clientes no existen, en contraste con la
arquitectura cliente-servidor. Aquí las
entidades conectadas al sistema se
denominan nodos (o peers, en inglés) y
estos pueden tomar el papel de cliente y
servidor a la vez.
Beneficios de los sistemas P2P:
Todos los nodos No existen puntos
comparten recursos únicos de falla

Mayor robustez del Facilidad de

sistema escalamiento

Puede desplegar
cualquier tipo de
algoritmo distribuido
Ejemplo 2
Sincronización
Conceptos básicos
Es un dispositivo electrónico integrado en cada computadora, cuya función es
Reloj Físico contar las oscilaciones que ocurren en un cristal a una frecuencia
determinada.

Tasa de desvío Es la diferencia entre la medida esperada por un reloj de referencia perfecta
de reloj nominal (considerado sin desviación) y el reloj observado

Reloj de Es el valor obtenido del reloj de hardware de una computadora a través del
Software sistema operativo

Reloj atómico Es una fuente externa para sincronizar los relojes de computadora.
Coordinación de relojes físicos
Si una computadora puede sincronizar su
reloj con una fuente de tiempo física precisa,
el objetivo de dicha computadora será
sincronizar los relojes de las demás
computadoras con esta fuente de tiempo. Si
ninguna computadora puede sincronizarse
con una fuente de tiempo externa, el sistema
puede emplear algoritmos de
sincronización para mantener sus relojes tan
sincronizados como sea posible.
Modelos de Sincronización
Es la sincronización de los relojes de los procesos con
Sincronización Externa: una fuente autoritativa externa de tiempo

Es cuando los relojes Ci están sincronizados entre sí con

Sincronización Interna: un grado de precisión conocido
Fallos de sincronización
Se considera una falla cuando un reloj no se corrige a pesar de la
aplicación de cualquier método de sincronización, podemos tener
dos tipos de fallos:

Fallo definitivo: si el reloj deja

de funcionar totalmente

Fallo arbitrario: cualquier otro

tipo de falla
Relojes Lógicos
En un sistema distribuido no se puede determinar el orden de ocurrencia de
dos eventos utilizando el tiempo físico ya que no es posible sincronizar el
tiempo dentro de un SD de manera exacta. Para resolver este problema
existen los siguiente métodos.

◎ Marcas de tiempo de Lamport

◎ Marcas de Tiempo de Vectores
Marcas de tiempo de Lamport
Este método se basa en los siguientes puntos:
◎ Si dos eventos ocurrieron en un proceso pi (donde i = 1, 2, 3, …, N), entonces dichos
eventos ocurrieron en el orden que los observa pi.
◎ Al enviar un mensaje de un proceso a otro, el evento de envío ocurre antes que el de
recepción del mensaje.
Marcas de Tiempo de Vectores
Un reloj vectorial es un arreglo de N enteros empleado en un sistema de N procesos. En este
caso cada proceso tiene su propio reloj vectorial Vi que utiliza las marcas de tiempo locales.
Diferencias entre:
Sistema descentralizado Sistema distribuido

• No existe un único nodo central, sino que • Posee un centro individual y colectivo
tiene un centro colectivo de diversos ausente.
puertos de conexión. • Ningún nodo posee el poder de filtrar la
• Todos los nodos del sistema se encuentran información que se distribuye en la red.
conectados entre sí, sin que tengan que • Si se cayera algún nodo no desconectará a
pasar por algún punto central. ningún otro.
• Se rige por el principio de adhesión o • La red se rige por el principio de la
participación. interacción, y cada nodo es independiente.
• No existe un nodo único que tome • Todos los equipos están conectados entre
decisiones, cada nodo toma su propia. sí mediante un protocolo de
decisión comunicaciones estándar y trabajan como
una única súper computadora.
Bases de Datos Distribuidas Punto
a Punto (BDD)
Una BDD es una colección de
múltiples bases de datos
interconectadas que se
extienden físicamente en varias
ubicaciones y se comunican a
través de una red informática.
Sistema de Gestión de BDD
Un Sistema de Gestión de Bases de Datos Distribuidas (DDBMS) es un sistema de software
centralizado encargado de administrar una BDD como si ésta se encontrara en una sola ubicación.
El cual cuenta con las siguientes características:

Permite la creación, recuperación, actualización y eliminación de BDD

Se encarga de sincronizar la BD periódicamente

Está diseñado para utilizarse en plataformas de BDs heterogéneas

Sistema de Gestión de BDD
Proporciona mecanismos de acceso a la BD de manera que la
distribución se torna transparente para los usuarios

Cuando se modifican datos, permite que estos se mantengan uniformes

y actualizados en toda la BDD

Cuando se utiliza una cantidad importante de usuarios necesiten

acceder a altos volúmenes de datos de manera simultánea.

Proporciona Confidencialidad e Integridad de los datos en la BD

Funcionamiento de las BDD
Su funcionamiento se basa de acuerdo a los dos tipos existentes de DDBMS comerciales
que son:

Los que establecen la Los formados por un

comunicación entre diccionario de datos, un
diferentes manejadores de DBMS (glosario), un
datos utilizando compuertas. componente de
comunicación y un DDBMS
 Proceso de Consulta
El procesador de consultas distribuidas se encarga de manejar el
orden de las operaciones del álgebra relacional, de seleccionar
los mejores nodos de procesamiento de datos y la forma en que
deben ser transformados. Mediante la optimización de consultas
es tomada por decisión de uno o varios nodos, habiendo tres
enfoques de toma de decisión:
◎ Enfoque Centralizado
◎ Enfoque Distribuido
◎ Enfoque Híbrido
Proceso de Consulta
Enfoque Centralizado Enfoque Distribuido Enfoque Híbrido

Varios nodos participan en la

Un nodo determina una
Utilizado por la mayoría de elaboración de la mejor
calendarización global de las
sistemas estrategia en el proceso de
operaciones de la estrategia
decisión

Requiere sólo la información

Requiere el conocimiento Cada nodo optimiza las
local (de los nodos
completo de la BDD subconsultas locales
involucrados)

Un solo nodo decide la

estrategia a ejecutar
Ventajas de las BDD
◎ Fiabilidad
◎ Seguridad
◎ Acceso Local
◎ Escalabilidad
◎ Desempeño
◎ Velocidad y eficiencia de los recursos
◎ Distribución del trabajo
◎ Reducción en el sobreflujo de mensajes dentro de la red
¿Qué es
Blockchain?
 Definición
Blockchain
Blockchain, traducido al español como
cadena de bloques, es un registro único,
consensuado y distribuido en varios nodos
pertenecientes a una red. En otras palabras,
es un registro histórico de todas las
transacciones entre los nodos.
.
Definición Blockchain
Cada bloque de la blockchain contiene información referente a una transacción y a su vez está
ligado al bloque anterior.
La información más relevante contenida en estos bloques generalmente es la siguiente:

Número de registro o transacciones válidas.

Información referente al bloque actual.

Información que vincula al bloque actual con el anterior y con el

siguiente bloque.
 ¿Una blockchain es una BDD?
A continuación, se mencionan algunas de las características que distinguen una blockchain de una
BDD
Una blockchain está basada en una
secuencia creciente de bloques. Todos los La cadena completa de
Los miembros de la blockchain
bloques que pertenecen a la blockchain bloques es almacenada en pueden verificar las interacciones
tienen una estructura definida e cada nodo miembro de la que hay entre sí sin la necesidad de
inmutable. blockchain. una tercera “entidad de confianza”.

1 2 3 4 5

Todos los bloques tienen un orden Una blockchain es un sistema semi-anónimo ya que,
definido no conmutativo, que se aunque todas las transacciones son rastreables
asegura al ligar el bloque actual con gracias a un registro guardado en la cadena, los
el anterior. usuarios se deben identificar con llaves públicas.
Una blockchain debe garantizar:

Disponibilidad Persistencia

Anonimato Auditabilidad
Evolución de la tecnología Blockchain

Blockchain 1.o Blockchain 2.o Blockchain 3.o Blockchain 4.o

La era de las La era de los Las aplicaciones de Busca emplear
criptomonedas Contratos Digitales. Blockchain se soluciones y enfoques
diversifican con el de Blockchain en la
auge de las (DApps). industria 4.0
Elementos básicos y estructura
de Blockchain

Red peer to peer Direcciones Transacción Nodo

Una blockchain utiliza Son identificadores Un nodo que

la topología únicos usados en las Representa la pertenece a la red
(comunicación peer transacciones de la transferencia de blockchain es una
to peer), donde cada blockchain. Con las valores, información entidad física
peer es un nodo que direcciones se o datos de una reconocida como
pertenece a la reconoce el emisor y dirección a otra miembro de la cadena
Blockchain. el receptor. de bloques.
Elementos básicos y estructura
de Blockchain

Nodo minero Ledger Bloque

Es un nodo que
Se trata de una red
participa en el
digital (base de datos) Un bloque es la
proceso de creación
que registra datos e unidad de
de los bloques que
historial de información
serán agregados a la
transacciones de contenida en la
cadena de bloques,
activos en nodos blockchain.
esto a cambio de una
descentralizados.
recompensa.
Estructura de los bloques
 Servicios seguridad en Blockchain
Definen los objetivos específicos a ser implementados a través de mecanismos de seguridad. Es una
característica que debe tener un sistema para satisfacer una política de seguridad.

Confidencialidad

Autenticación

Integridad

Control de Acceso

No repudio
 Mecanismos de seguridad en Blockchain
Consisten en la funcionalidad específica para cumplir con un servicio de seguridad. Es un
procedimiento concreto utilizado para implementar el servicio de seguridad (el cómo).

Código de detección de Control de

modificaciones encaminamiento

Firma digital Control de acceso

Cifrado Certificación

Relleno de tráfico Hash

Código de autenticación Número de secuencia del

del mensaje mensaje
Autenticación

El servicio de autenticación asegura que

las entidades que se comunican son
quienes reclaman ser. El servicio usa
información para establecer la validez de
procedencia o privilegios de una entidad,
individuo o sistema en la red, proveyendo
protección ante estos.
Public Key Infrastructure (PKI)
Es un sistema que permite establecer comunicaciones seguras utilizando certificados digitales,
permite autenticar el huésped y el usuario en una comunicación. Una operación que utiliza PKI
tiene al menos la intervención de los siguientes actores:

Usuario que inicia la

1 operación

Sistemas y/o servidores que constatan la

2 ocurrencia de la operación y aseguran la
validez de las llaves implicadas.

Destinatario de los datos

3 firmados o cifrados.
Generación de
bloques en una
blockchain
permissionless
Tipos de Blockchain
Las redes Blockchain pueden clasificarse dependiendo de su modelo de permisos, esto determina
quién puede desempeñar acciones propias de la blockchain (cómo añadir bloques).
Si cualquier usuario puede añadir un nuevo bloque se dice que la red blockchain es “Permissionless
o Pública”. Por otro lado, si sólo usuarios determinados pueden añadir nuevos bloques, la red se
denomina “Permissioned o Privada.

Comunicación Síncrona

Comunicación Asíncrona
Blockchain pública o
Permissionless
Este tipo de Blockchain maneja plataformas de ledgers descentralizados, es decir, está abierto a
que cualquiera publique un bloque (sin necesitar permiso de ninguna autoridad), esto deriva en
que cualquier usuario de la blockchain puede leer y escribir en el ledger.
Este tipo de blockchain intenta mitigar ataques
maliciosos al utilizar diversos algoritmos de
consenso (para verificar la autenticidad de la
transacción) que demandan un gasto de
recursos de aquel que quiere añadir su bloque.
Por ejemplo: PoW y Proof of Stake .
Blockchain privada o
Permissioned
En este tipo de Blockchain el usuario que quiere añadir un bloque debe ser autorizado por
alguna figura de autoridad o entidad de confianza. Dicha figura puede ser centralizada o
descentralizada. Pueden tener la misma trazabilidad que una red permissionless y los datos
pueden encontrarse distribuidos.
También usan algoritmos de consenso, aunque,
estos suelen ser más rápidos y
computacionalmente menos caros que los que
se usan en permissionless.
Estas blockchain pueden utilizar código abierto
o código propietario.
.
Protocolos de
Consenso
¿Qué es un protocolo
de consenso?
Es el procedimiento que permite
asegurar que todos los nodos de la red
estén de acuerdo en qué información
se agrega y cual se descarta en la
cadena de bloques.
.
¿Qué hacen los protocolos
de consenso?
Los protocolos de consenso se
encargan de evitar que una sola
entidad tome el control de toda la
cadena. Esto significa que si una red
tiene consenso todos los nodos
participantes están de acuerdo en el
estado de la cadena de bloques.
El Problema de los
Generales Bizantinos
Este problema plantea una situación en la
que un cierto número de partes
involucradas deben acordar una única
estrategia para evitar el fracaso total,
asumiendo que algunas de estas partes
podrían ser corruptas y por lo tanto
difundir información falsa para manipular
al resto de los participantes a su favor.
 ¿Cómo soluciona blockchain el problema
de los Generales Bizantinos?
Blockchain aporta una solución a este problema gracias a la combinación de varios factores:

Internet (Permite la conexión instantánea a distancia)

Sistemas de comunicación P2P (Permiten reconocer la

identidad entre los nodos conectados)

Validación de cada operación por todas las partes

implicadas

Uso de funciones hash para proteger la integridad de la

información (previene los ataques de terceros)
Sistema Tolerante a Fallos Bizantinos
(Byzantine Fault Tolerant BFT)
Si un sistema puede llegar a un consenso
(siempre que dos tercios de los nodos de
la red estén de acuerdo con el consenso)
y no permite que ciertas partes se
coludan para el beneficio de algunos, se
definirá como un sistema tolerante a
fallos bizantinos.
 Tipos de consenso
Existen diferentes tipos de protocolos de consenso, a continuación, se muestran los más
comunes:

Proof-of-Work (PoW)

Proof-of-Stake (PoS)

Delegated Proof-of-Stake (DPoS)

Proof-of-Authority (PoA)
Proof-of-Work (PoW)
El algoritmo de consenso de prueba de trabajo es el mecanismo de consenso más antiguo y
popular, debido a su capacidad de promover la honestidad en el ecosistema descentralizado.
Participantes en Proof-of-Work:

1 Nodos mineros

2 Operadores completos de nodos

 Algoritmo de Proof-of-Work
El nodo ganador recibe el permiso para elegir el siguiente bloque que será añadido
Existen dos tipos de nodos: los que a la blockchain, mientras que todos los demás nodos que obtuvieron la respuesta
realizan transacciones y los nodos correcta (también llamados líderes de bloques) sirven como verificadores del
que verifican estas transacciones, resultado del ganador que además reciben como recompensa tokens de acuerdo al
estos últimos son llamados “nodos poder de procesamiento, la velocidad y la precisión aportada en la resolución del
mineros”. problema.

1 2 3 4

Los nodos mineros compiten por ser los siguientes en verificar Los operadores completos de nodo validan
una transacción realizada por el resto de los nodos. Para ganar el estado final de la red
esta oportunidad deben de resolver un problema matemático
complejo. El minero que resuelva primero este problema será
el siguiente en validar una transacción.
Usos de Proof-of-Work

1 2 3
Validación de las Prevenir el ataque de Protocolo de barrera
transacciones de los 51% o los gastos de contingencia para
nodos mineros en dobles. asegurar la red en un
Blockchain. ataque DoS que
requiere un orden
definido.
 Pros y Contras de PoW

Es muy costosa la adquisición de piezas de

Evita ataques DDoS, por ejemplo, es tolerante a
computadora para un equipo profesional y la
caídas de nodos.
adquisición de periféricos.
Los nodos dedican demasiado tiempo a la
Crea una economía cerrada relativamente sana y
resolución de estos problemas, durante este
transparente que anima a los usuarios a seguir
proceso hay un gran consumo de energía
sosteniendo el ecosistema.
eléctrica.
Una vez que las recompensas no son atractivas,
Alienta el interés de sus usuarios en mantener una es más difícil que un minero tome un bloque y lo
red saludable verifique, lo que hace que el proceso de incluir un
nuevo bloque en la blockchain sea aún más lento.
64
Proof-of-Stake (PoS)
Este algoritmo establece que un nodo puede validar transacciones según el número de
monedas que posea. Esto significa que cuantas más monedas posea un validador, más
posibilidades de ser el siguiente en validar un bloque tendrá. Lo que permite eliminar la
necesidad de utilizar un equipo de cripto-minado (equipo computacional altamente complejo).
Participantes en Proof-of-Stake:

Nodos validadores o forjadores

1 (forgers en inglés)
Pasos en la Validación PoS

El forjador procesa el El forjador entonces

Los participantes realizan su siguiente bloque de toma su tarifa de
“apuesta”. transacciones. transacción.

1 2 3 4 5

El algoritmo selecciona al Cuando termina de procesarlas, la red

siguiente forjador o validador agrega esa información al bloque.
al azar basándose en las
apuestas actuales.
Usos de Proof of Stake

Validar transacciones Al seleccionar Protocolo de barrera

utilizando al forjador forjadores aumenta la de contingencia para
seleccionado. prioridad a un usuario asegurar la red en un
que ha mantenido su ataque DoS que
criptomoneda por al requiere un orden
menos 30 días y para definido.
evitar manipulación
existe un tope
máximo de 90 días
 Pros y Contras de PoS

Ofrece una mayor oportunidad para que las

personas puedan convertirse en validadores lo
cual puede mantener la red más descentralizada. Existen “ballenas” que son validadores que
poseen demasiados tokens y por lo tanto el poder
Cuando un validador decide retirarse, de su voto es demasiado grande comparado con
simplemente se libera su apuesta o depósito y los llamados “pececillos” que son inversionistas
entonces puede disfrutar de sus ganancias tanto menores. Esto significa que la forma misma en la
de la apreciación de la moneda como de sus que funciona el modelo puede ser tanto un pro
tarifas de transacción. como un contra ya que entre mayores apuestas
habrá mayor ventaja en la selección del forjador.
Utilizando este modelo es muy baja la cantidad de
dinero, energía y espacio que se pierde al generar
nuevas criptomonedas.
Diferencias
entre PoW y
PoS
Delegated Proof-of-Stake (DPoS)

Funciona de forma similar al PoS. Pero,

en lugar de usar la probabilidad, los
titulares de criptomonedas son capaces
de emitir votos prorrateados a su
participación con el fin de nombrar
testigos conocidos como delegados.
Pure Proof-of-Stake (PPoS)

La influencia de cada usuario en la elección de un nuevo bloque

es proporcional a su participación (la cantidad de tokens) en el
sistema. Los usuarios se seleccionan de manera aleatoria y
secreta para proponer bloques y votar sobre propuestas de
bloques. Todos los usuarios en línea tienen la oportunidad de ser
seleccionados para proponer y votar bloques. La probabilidad
de que se elija cierto usuario, y el peso de sus propuestas y
votos, son directamente proporcionales a su participación.
Proof-of-Authority (PoA)
La prueba de autoridad (Proof of Authority PoA en inglés) se puede considerar como un caso
particular del PoS, pero en lugar de poder participar con una apuesta o depósito financiero, se
participa apostando la identidad del nodo.
Participantes en Proof of Authority

Validadores cuya identidad se

mantiene anónima y su reputación
1 intacta mientras no procesen
transacciones maliciosas.
 Algoritmo de PoA
Se eligen validadores de forma aleatoria. La
inclusión y selección de nuevos nodos se lleva Cada validador puede firmar una sola
a cabo mediante una votación realizada por serie de bloques consecutivos durante
nodos previamente autorizados. su turno de validación.

1 2 3 4

El validador revela de forma voluntaria su Tras validar las transacciones el sistema

identidad para que sea validada y se pueda elimina los posibles actores maliciosos y
facilitar el establecimiento de responsabilidades expone su identidad.
y su funcionamiento en la blockchain.
Usos de Proof of Authority

Validación confiable
de transacciones
asegurada por la
identidad y reputación
de un nodo.
 Pros y Contras de PoA

Se considera seguro ya que los validadores que

Los sistemas que implementan PoA no cumplen
están dispuestos a invertir su propio dinero y
con el concepto de anonimato como otras
además son considerados como confiables y
criptomonedas.
verificados.

Provee una alta eficiencia en los tiempos de Pierde en gran parte la descentralización posible
transacción y el consenso de la misma. en los protocolos de consenso mencionados
anteriormente ya que si uno de los validadores
Al igual que con PoS no existe necesidad de un representa a una compañía grande y reconocida
gasto elevado de recursos para el mantenimiento entonces su reputación será más elevada y se
de la red y sus costos de mantenimiento son considerará más confiable.
bajos.
Practical Byzantine Fault Tolerance
(pBFT)
El pBFT es un algoritmo encargado de optimizar la protección BFT y ha sido implementado en
varias plataformas de Blockchain como: Hyperledger, Stellar y Ripple. Típicamente se utilizan
en combinación con otros algoritmos de consenso.
Participantes en pBFT:

Nodos ordenados secuencialmente

considerando a un nodo como
1 “líder” y a los demás como “nodos
de respaldo”.
 Algoritmo de pBFT
Para el correcto funcionamiento de un sistema pBFT, el número de nodos maliciosos debe ser menor
que la tercera parte de todos los nodos en el sistema en un escenario de vulnerabilidad dado.
Cada ronda del algoritmo de consenso pBFT se le llama vista y dicha vista se divide en 4 fases:

Los nodos ejecutan la petición y hacen una confirmación

Un cliente envía una petición al nodo líder para de la misma y la envían a los demás nodos para
invocar una operación de servicio. posteriormente enviar una respuesta al cliente.

1 2 3 4

El nodo líder entonces transmite la petición a los nodos El cliente finalmente espera f + 1 respuestas de diferentes
de respaldo. nodos con el mismo resultado, donde f representa el
número máximo de nodos potencialmente defectuosos.
Algoritmo de pBFT
Usos de pBFT

Aseguran una Actualmente 2 Tiene una versión

comunicación segura proyectos utilizan el permisionada de
pBFT que son efectiva para
Hyperledger Fabric y proporcionar
Zilliqa transacciones de alto
rendimiento
 Pros y Contras de pBFT

Permite que las transacciones puedan ser

aprobadas y finalizadas sin necesitar múltiples Problemas de escalabilidad
confirmaciones.

Eficiencia energética
Ataques “Sybil” donde un sólo ente puede crear o
manipular una gran cantidad de nodos en la red
para comprometer la seguridad.
Recompensas poco variantes
Raft
Algoritmo equivalente a Paxos en su tolerancia a fallos y rendimiento. La diferencia es que Raft
descompone el consenso en subproblemas relativamente independientes unos de otros y todas las piezas
principales en las que se divide se abordan de manera distribuida para tener un sistema más práctico.
Participantes en RAFT:

Servidores en el clúster de
1 computadoras

2 Servidor “Líder”

3 Servidores “Seguidores”

4 Servidores “Candidatos”
 Algoritmo Raft
RAFT descompone el proceso de alcanzar un consenso en 3 subproblemas independientes que son:

Elección de un líder Seguridad

1 2 3

Replicación de registros
Elección de servidor líder en Raft
Algoritmo Raft
Usos de Raft

Replicar sistemas Bases Distribuidas NewSQL utiliza RAFT MongoDB y HashiCorp

distribuidos más como TiDB y para la administración utilizan RAFT.
robustos y YugabyteDB utilizan de la base de datos.
consistentes sin RAFT para la elección
sacrificar desempeño de servidores líderes y
o precisión. replicación.
 Pros y Contras de RAFT

Consistencia

Alta disponibilidad Es estrictamente un protocolo de un solo líder por

lo que una cantidad alta de tráfico puede atascar
Está diseñado para ser fácil de entender e al sistema.
implementar
Cualquier nodo en el clúster se puede convertir en
líder.
Hyperledger
Fabric
Plataforma DLT

Fabric es una plataforma de código abierto de nivel-empresarial

permisionado de tecnología de ledger distribuido, diseñado para
contextos empresariales.
El consorcio Hyperledger se ha establecido bajo la fundación
Linux, bajo la política de open governance que rige a los
ecosistemas de la fundación Linux.
Composición

◎ Modular
◎ Configurable
◎ Contratos Inteligentes en lenguajes de
propósito general (Java/Go/Node.js)
◎ Permisionado
Protocolo de Consenso
“Pluggable”

Permite a la plataforma en una personalización más efectiva

para ajustarse a modelos confiables y casos de uso particulares.

Protocolos de Consenso:
◎ CFT – Tolerancia a fallos
◎ BFT – Tolerancia a fallas bizantinas
Características

◎ No require procesos de minado

◎ Desarrollos amigables
◎ Contratos Inteligentes en Chaincode
◎ Privacidad y Confidencialidad
Modularidad

Fabric es de arquitectura modular, puede tener consenso

pluggable, protocolos de gestión de identidad pluggable,
protocolos de gestión de llave o bibliotecas criptográficas, con
la finalidad de cumplir los diversos requisitos en casos de uso
empresariales.
Componentes Modulares

◎ Pluggable ordering service establece un

consenso sobre el orden de las transacciones y
posteriormente transmite los bloques a los
peers.
◎ Pluggable membership service provider
responsible de asociar entidades en la red con
elementos criptográficos.
Componentes Modulares

◎ Un opcional peer-to-peer gossip service

difunde la salida de los bloques solicitando el
servicio a otros peers.
◎ Smart contracts chaincode se ejecuta dentro de
un entorno de contenedor (como Docker) para
el aislamiento. Se puede escribir en lenguajes
estándar pero no tienen acceso directo al ledger
principal.
Componentes Modulares

◎ El ledger se puede configurar para soportar una

variedad de Bases de Datos Distribuidas.
◎ Una aplicación de política de aprobación y
validación pluggable que se puede configurar de
forma independiente por aplicación.
Ventajas de ser Permissioned

Un blockchain permisionado proporciona una forma de asegurar

las interacciones entre un grupo de entidades que tienen un
objetivo común pero que pueden no confiar plenamente entre
sí. Al depender de las identidades de los participantes, se puede
usar protocolos de consenso basados en tolerancia a fallos que
no requieren minería costosa.
Ventajas de ser Permissioned

En un contexto permisionado, se reduce el riesgo de que un

participante introduzca intencionalmente un código malicioso a
través de un contrato inteligente. Primero, los participantes se
conocen entre sí y todas las acciones, como enviar transacciones
de aplicaciones, modificar configuración de la red o implementar
contratos inteligentes. En lugar de anonimato, se puede
identificar fácilmente a la parte culpable y manejar incidentes
con base en políticas establecidas en el modelo de gobierno de
la red.
Contratos Inteligentes

Un contrato inteligente es un conjunto de código y datos (en

ocasiones denominados funciones y estado) que se implementa
mediante transacciones firmadas criptográficamente en la red
blockchain. El contrato inteligente es ejecutado por nodos
dentro de la red blockchain, todos los nodos que ejecutan el
contrato inteligente deben obtener los mismos resultados de la
ejecución, y los resultados de la ejecución se registran en la
blockchain.
Contratos Inteligentes

Puede:

◎ Proporcionar acceso controlado al ledger.

◎ Permiten que los participantes ejecuten ciertos aspectos de
las transacciones automáticamente.
◎ Pueden estipular el costo de envío de un artículo donde el
cargo de envío cambia dependiendo que tan rápido llegue el
artículo.
Contratos Inteligentes en Fabric

En Fabric se llama chaincode, funciona como una aplicación

distribuida confiable que obtiene su seguridad/confianza de la
blockchain y el consenso subyacente entre los pares.
Puntos clave para aplicación de
contratos inteligentes

◎ Muchos contratos inteligentes se ejecutan simultáneamente

en la red.
◎ Se pueden implementar de forma dinámica (en muchos
casos por cualquier persona)
◎ El código de la aplicación debe tratarse como no confiable,
incluso como malicioso.
Arquitectura order-execute

La mayoría de las plataformas en blockchain compatibles con

contratos inteligentes existentes siguen arquitectura tipo order-
execuite en la que el protocolo de consenso:
◎ Valida y ordena transacciones y luego las propaga a todos los
nodos pares,
◎ Cada nodo luego ejecuta las transacciones secuencialmente.
Arquitectura execute-order-
validate

Fabric introduce la arquitectura para transacciones execute-

order-validate. Atiende los desafíos de resiliencia, flexibilidad,
escalabilidad, rendimiento y confidencialidad que enfrenta el
modelo de ejecución de órdenes separando el flujo de
transacciones en tres pasos.
Tres pasos

◎ Execute se ejecuta una transacción y se verifica su

corrección, avalándola,
◎ Order se ordenan transacciones a través de un protocolo de
consenso (pluggable), y
◎ Validate se validan transacciones contra una política de
aprobación específica de la aplicación antes de colocarlas en
el ledger.
Privacidad y confidencialidad
Al ser una plataforma permisionada, permite la confidencialidad
a través de su arquitectura de canales y función de datos
privados. En los canales, los participantes en una red Fabric
establecen una subred donde cada miembro tiene visibilidad de
un conjunto particular de transacciones. Así, solo aquellos nodos
que participan en un canal tienen acceso al contrato inteligente
(chaincode) y a los datos acordados, preservando la privacidad y
confidencialidad de ambos. Los datos privados permiten las
recopilaciones entre los miembros de un canal, lo que brinda la
misma protección que los canales sin la sobrecarga de
mantenimiento de crear y mantener un canal separado.
Ledger compartido
Su ledger tiene un subsistema que consta de dos componentes:
world state y el transaction log. Cada participante tiene una
copia del ledger de cada red de Fabric a la que pertenece.
El componente world state describe el estado del ledger en un
momento determinado. Funge como base de datos del ledger.
El transaction log registra todas las transacciones que dieron
como resultado el valor actual del world state, es el historial de
actualizaciones del world state. El ledger, entonces, es una
combinación de la base de datos del world state y el historial del
transaction log.
Modelo de Fabric

◎ Assets – Las definiciones de activos permiten el intercambio

de casi cualquier cosa con valor monetario a través de la red.
◎ Chaincode – La ejecución de chaincode se separa del pedido
de transacciones, lo que limita los niveles requeridos de
confianza y verificación entre los tipos de nodos y optimiza
la escalabilidad y el rendimiento de la red.
Modelo de Fabric

◎ Características del Ledger – El ledger inmutable y

compartido codifica el historial completo de transacciones
para cada canal e incluye la capacidad de consultas similares
a SQL para una auditoría y resolución de disputas de forma
eficiente.
◎ Privacidad – Los canales y las recopilaciones de datos
privados permiten transacciones multilaterales privadas y
confidenciales que normalmente requieren empresas
competidoras e industrias reguladas que intercambian
activos en redes comunes.
Modelo de Fabric

◎ Servicios de seguridad y membresía – La membresía

permisionada proporciona una red blockchain confiable,
donde los participantes saben que todas las transacciones
pueden ser detectadas y rastreadas por reguladores y
auditores autorizados.
◎ Consenso – Un enfoque único al consenso permite la
flexibilidad y escalabilidad necesarias para la empresa.
Identidad
Proveedor de Servicio de
Membresía
Nodos
Ledger
Servicio de Peticiones
Redes Fabric

◎ Organizaciones
◎ Canales
◎ Servicio de pedidos
◎ Aplicaciones
◎ Chaincode
◎ Configuraciones
Estructura de una red Fabric
Inicio de la red
Se unen nodos al canal
Chaincode
Usando una aplicación al canal
Múltiples canales
Adición de componentes al canal
Casos de Uso

◎ Voto electrónico
◎ Manejo de identidad
◎ IoT
◎ Cadena de Suministros
◎ Manejo de bienes raíces
◎ Servicios públicos
Instalación

◎ Prerequisitos
◎ Ejemplos de Fabric
◎ API para Contratos
◎ API para Aplicaciones
◎ Aplicación
Git

◎ Instalación: sudo apt-get install git

cURL

◎ Instalación: sudo apt-get install curl

Docker

◎ Instalación: sudo apt-get –y install docker-compose

◎ Verificación: docker --versión | docker-compose --versión
◎ Inicio de servicio: sudo systemctl start docker
Go

◎ Instalación GO: https://go.dev/doc/install

Práctica en
Fabric
Instalación de Go

◎ Se descarga el binario.
◎ Desde la carpeta donde se encuentra el binario se hace: rm -
rf /usr/local/go && tar -C /usr/local -xzf go1.19.4.linux-
amd64.tar.gz
◎ Se añade la variable de entorno: export
PATH=$PATH:/usr/local/go/bin
◎ Se verifica la instalación: go version
Instalación de jq

◎ Mediante repositorio: sudo apt-get install jq

Carpeta para Go

◎ mkdir -p $HOME/go/src/github.com/<tu_github_userid>
◎ cd $HOME/go/src/github.com/<tu_github_userid>
Instalación de script

◎ curl -sSLO
https://raw.githubusercontent.com/hyperledger/fabric/main
/scripts/install-fabric.sh && chmod +x install-fabric.sh
Ejecución de script

◎ ./install-fabric.sh
Alta de la red

◎ cd fabric-samples/test-network
◎ ./network.sh down
◎ ./network.sh up
◎ docker ps -a
Creación de canal

◎ ./network.sh createChannel
◎ ./network.sh createChannel -c channel1
◎ ./network.sh up createChannel
Despliegue de chaincode

◎ ./network.sh deployCC -ccn basic -ccp ../asset-transfer-

basic/chaincode-go -ccl go
Interacción con la red
◎ export PATH=${PWD}/../bin:$PATH
◎ export FABRIC_CFG_PATH=$PWD/../config/
◎ export CORE_PEER_TLS_ENABLED=true
◎ export CORE_PEER_LOCALMSPID="Org1MSP"
◎ export
CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/p
eerOrganizations/org1.example.com/peers/peer0.org1.exam
ple.com/tls/ca.crt
◎ export
CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peer
Organizations/org1.example.com/users/[email protected]
le.com/msp
◎ export CORE_PEER_ADDRESS=localhost:7051
Iniciar ledger con activos
◎ peer chaincode invoke -o localhost:7050 --
ordererTLSHostnameOverride orderer.example.com --tls --
cafile
"${PWD}/organizations/ordererOrganizations/example.com/
orderers/orderer.example.com/msp/tlscacerts/tlsca.exampl
e.com-cert.pem" -C mychannel -n basic --peerAddresses
localhost:7051 --tlsRootCertFiles
"${PWD}/organizations/peerOrganizations/org1.example.co
m/peers/peer0.org1.example.com/tls/ca.crt" --
peerAddresses localhost:9051 --tlsRootCertFiles
"${PWD}/organizations/peerOrganizations/org2.example.co
m/peers/peer0.org2.example.com/tls/ca.crt" -c
'{"function":"InitLedger","Args":[]}'
Visualización de activos

◎ peer chaincode query -C mychannel -n basic -c

'{"Args":["GetAllAssets"]}'
Transferencia de activos
◎ peer chaincode invoke -o localhost:7050 --
ordererTLSHostnameOverride orderer.example.com --tls --
cafile
"${PWD}/organizations/ordererOrganizations/example.com/
orderers/orderer.example.com/msp/tlscacerts/tlsca.exampl
e.com-cert.pem" -C mychannel -n basic --peerAddresses
localhost:7051 --tlsRootCertFiles
"${PWD}/organizations/peerOrganizations/org1.example.co
m/peers/peer0.org1.example.com/tls/ca.crt" --
peerAddresses localhost:9051 --tlsRootCertFiles
"${PWD}/organizations/peerOrganizations/org2.example.co
m/peers/peer0.org2.example.com/tls/ca.crt" -c
'{"function":"TransferAsset","Args":["asset6","Christopher"
]}'
Interacción con la red
◎ export PATH=${PWD}/../bin:$PATH
◎ export FABRIC_CFG_PATH=$PWD/../config/
◎ export CORE_PEER_TLS_ENABLED=true
◎ export CORE_PEER_LOCALMSPID="Org2MSP"
◎ export
CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/p
eerOrganizations/org2.example.com/peers/peer0.org2.exa
mple.com/tls/ca.crt
◎ export
CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peer
Organizations/org2.example.com/users/[email protected]
ple.com/msp
◎ export CORE_PEER_ADDRESS=localhost:9051
Transferencia de activos

◎ peer chaincode query -C mychannel -n basic -c

'{"Args":["ReadAsset","asset6"]}'
Baja de la red

◎ ./network.sh down
Pasos posteriores...

◎ https://hyperledger-
fabric.readthedocs.io/en/latest/test_network.html
◎ https://hyperledger-
fabric.readthedocs.io/en/latest/tutorials.html
◎ https://hyperledger-
fabric.readthedocs.io/en/latest/deployment_guide_overvie
w.html
◎ https://hyperledger-
fabric.readthedocs.io/en/latest/ops_guide.html
Algorand
Recordando conceptos…
Ejemplo
Comparativa…
Cadena
Por tanto…
Comparativa…
Beneficios de Blockchain
¿Porqué Algorand?

En el ecosistema se tiene la siguiente filosofía:

◎ Es importante investigar y elegir el Blockchain en la que se
pueda confiar todas las propiedades que promete
Blockchain.
◎ Se posee la visión de democratizar las finanzas y cumplir la
promesa de funcionamiento de Blockchain.
El protocolo de consenso

El problema de muchos Blockchain es que se sacrifica al menos

una de las siguientes propiedades:
◎ Escalabilidad
◎ Seguridad
◎ Descentralización

La solución que ofrece Algorand es Pure Proof of Stake.

PPoS - Descripción
Este protocolo de consenso funciona mediante la selección de
un proponente de bloque y un conjunto de comités de votación
en cada ronda de bloque, con el fin de proponer un bloque y
validar la propuesta, respectivamente. El proponente y los
comités se eligen al azar del grupo de todos los poseedores de
tokens (cuentas que poseen algos), y la probabilidad de ser
elegido es proporcional a participación de la cuenta en la red (es
decir, cuántos algos tiene en relación con el total). Hay varios
algoritmos criptográficos realmente buenos que intervienen en
este proceso, con nombres elegantes como “funciones
aleatorias verificables” y “clasificación criptográfica” para
garantizar que la votación sea justa, que nadie pueda coludirse y
que el sistema en general sea muy seguro.
Proof of Stake vs Proof of Work
Proof of Stake vs Proof of Work
Moneda nativa
Cada criptomoneda tiene su propia moneda nativa que juega un
papel fundamental para incentivar el buen comportamiento de
su red blockchain. En Algorand la moneda se llama Algo.
Si se posee Algos, se puede hacer registro para participar en
consenso, lo que significa que se participará en el proceso de
propuesta y votación de nuevos bloques.
El Algo actúa como un token de utilidad. Cuando se está
creando una aplicación, se necesitan algoritmos para pagar las
tarifas de transacción y para servir como depósitos de saldo
mínimo si se tiene deseo de almacenar datos en la cadena de
bloques. El costo de las tarifas y saldos mínimos es muy bajo,
fracciones de un centavo en la mayoría de los casos.
Tarifas

Las tarifas se calculan según el tamaño de la transacción y un

usuario puede optar por aumentar una tarifa para ayudar a
priorizar la aceptación en un bloque cuando el tráfico de la red
es alto y los bloques están constantemente llenos. No existe el
concepto de tarifas de gas en Algorand.
La tarifa mínima para una transacción es de 1000 microAlgos o
0,001 Algos.
Apertura

En el ejemplo del inicio se comparó un ledger de un blockchain

con un ledger tradicional centralizado. Técnicamente, un ledger
de una blockchain podría ser propiedad de unas pocas entidades
y operarlo, pero esto no sería una blockchain muy buena, ya que
un conjunto de nodos tan centralizados podría manipular
fácilmente el estado de la blockchain.
La redes en Algorand son completamente abiertas y públicas,
cualquiera en cualquier parte del mundo, que sea propietario de
Algos puede participar en el consenso.
Descentralización y
Transparencia

◎ Descentralización: El protocolo que se usa es abierto y

público, los nodos pueden existir y existen en todo el mundo.
◎ Transparencia: El código del protocolo central es de código
abierto. Cualquiera puede revisarlo y hacerle contribuciones.
Carencia de Bifurcación
(Forking)
La bifurcación es cuando una blockchain diverge en dos caminos
separados. A veces, esa bifurcación es intencional, por ejemplo
cuando una parte importante de la comunidad quiere cambiar
los fundamentos del protocolo. Otras veces la bifurcación es
accidental y ocurre cuando dos mineros encuentran un bloque
casi al mismo tiempo. Eventualmente, una de las rutas será
abandonada, lo que significa que todas las transacciones que
ocurrieron desde esa bifurcación en la ruta abandonada no
serán válidas.
En Algorand se usa un mecanismo de votación para validar
bloques, la bifurcación es imposible. En el peor caso si el comité
tarda más en llegar a acuerdos, la blockchain se aletarga o se
detiene temporal.
Desempeño
La velocidad a la que se producen los bloques, la cantidad de
transacciones que caben en un bloque y la validación de las
transacciones se consideran fundamentales para elegir una
blockchain. En Algorand el rendimiento está dado:
◎ Rendimiento: los bloques son producidos cada 3.9 segundos
con capacidad de hasta 25,000 transacciones, lo que se
traduce en alrededor de 6,000 transacciones por segundo.
◎ Finalidad: un rendimiento de 6,000 TPS se traduce en 6,000
transacciones finalizadas por segundo.
Características adicionales
◎ Principales: Algorand facilita la tokenización, la transferencia
y la programación de condiciones en cualquier instrumento
de valor.
◎ Herramienta de desarrollo: Se puede escribir contratos
inteligentes en Python o Reach y se puede usar Python, JS,
Go, Java para conectar con la cadena de activos o
aplicaciones, además de poseer herramientas para IDEs,
monitoreo.
◎ Ecosistema: Es abierto a todo tipo de desarrollador o
investigador.
◎ Gobierno: Algorand MainNet gobierna la red Algorand con el
porpósito de expansión y constante descentralización.
El futuro es ahora, ¿oíste viejo?...
Aplicaciones
Descentralizadas
Ejemplo de ecosistema
Ejemplo de modelado de
problema
Modelo de Subasta - Problema

Alice generalmente vende sus obras de arte a través de

conexiones personales y, a veces, mediante publicidad en las
redes sociales. Una de sus piezas de arte digital se vende por
$100, en promedio, utilizando sus técnicas de venta actuales.
Cree que podría ganar mucho más si pudiera escalar y llegar a un
público más amplio.
Modelo de Subasta - Objetivos
Alice considera las propiedades importantes para su caso de
uso:
◎ Eficiencia: Alice pasa mucho tiempo tratando de encontrar
comprador y, en última instancia, no llega a una audiencia lo
suficientemente amplia.
◎ Confianza/transparencia: Quiere llegar a un público más
amplio, pero todavía está construyendo su reputación y
necesita una manera para que tanto ella como los
compradores potenciales sepan que no son estafados.
◎ Costo: Si desea escalar a un sitio e-commerce sabe que
tendrá que renunciar a buena parte de su ganancia en tarifas.
Propuesta

Nombramos 4 propiedades de blockchain que podrían ayudar a

Alice y su caso de uso. Alice y Bob hacen una lluvia de ideas
considerando los objetivos principales de Alice y las propiedades
para las que quiere optimizar. Se les ocurre la siguiente idea:
Propuesta
Planean tokenizar la obra de arte de Alice como NFT en la BC.
Esto les da un punto de entrada al ecosistema de la cadena de
bloques y la capacidad de programar lo que quieren hacer a
continuación. Luego, construirán una dApp de subasta en la
cadena de bloques que permitirá a Alice vender su obra de arte
por un precio establecido por el mercado. La subasta se
programará en la cadena de bloques para que todos la vean y la
verifiquen de forma independiente…
Propuesta
Alice puede garantizar a sus compradores que no serán
estafados y viceversa sin necesidad de conocerlos
personalmente (confianza/transparencia). Dado que eliminan la
necesidad de que un tercero garantice el comercio, pueden
reducir sustancialmente las tarifas y Alice puede ganar más
dinero (bajo costo). Alice puede concentrarse en publicitar su
trabajo a una audiencia tan amplia como quiera a través de sus
cuentas de redes sociales o en cualquier otro lugar sin necesidad
de reunirse individualmente y generar confianza con
compradores potenciales (eficiencia).
Componentes
Sandbox

Sandbox permite a los desarrolladores crear redes privadas

locales. Además, puede eliminar rápidamente una red,
restablecer su estado o activar una nueva red. El único requisito
para usar el entorno limitado de Algorand es instalar Docker y
Docker-Compose. Además, puede optar por conectarse a una
red real y el sandbox se encargará de ponerse al día con la
última ronda.
Instalación de Sandbox
# Clonar desde GitHub
git clone https://github.com/algorand/sandbox.git

# Posicionarse en el directorio
cd sandbox

# Ejecutando Sandbox
./sandbox up
Primera
Transacción
Instalación de Sandbox
# Clonar desde GitHub
git clone https://github.com/algorand/sandbox.git

# Posicionarse en el directorio
cd sandbox

# Ejecutando Sandbox
./sandbox up testnet
Instalación de PythonSDK

-m pip3 install py-algorand-sdk

Paso 1 – Se crea cuenta
from algosdk import account, mnemonic

def generate_algorand_keypair():
private_key, address = account.generate_account()
print("My address: {}".format(address))
print("My private key: {}".format(private_key))
print("My passphrase:
{}".format(mnemonic.from_private_key(private_key)))

generate_algorand_keypair()
Paso 2 – Conexión
from algosdk.v2client import algod

def first_transaction_example(private_key, my_address):

algod_address = "http://localhost:4001"
algod_token =
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaa"
algod_client = algod.AlgodClient(algod_token,
algod_address)
Paso 2 – Revisión de balance
account_info = algod_client.account_info(my_address)
print("Account balance: {}
microAlgos".format(account_info.get('amount')) + "\n")
Paso 3 – Construcción de
transacción
from algosdk.future import transaction
from algosdk import constants

params = algod_client.suggested_params()
params.flat_fee = True
params.fee = constants.MIN_TXN_FEE
receiver =
"HZ57J3K46JIJXILONBBZOHX6BKPXEM2VVXNRFSUED6DKFD5Z
D24PMJ3MVA"
note = "Hello World".encode()
amount = 1000000
unsigned_txn = transaction.PaymentTxn(my_address, params,
receiver, amount, None, note)
Paso 3 – Firmando transacción
# sign transaction
signed_txn = unsigned_txn.sign(private_key)
Paso 4 – Subir transacción
import json
import base64
txid = algod_client.send_transaction(signed_txn)
print("Successfully sent transaction with txID:
{}".format(txid))
try:
confirmed_txn =
transaction.wait_for_confirmation(algod_client, txid, 4)
except Exception as err:
print(err)
return
Paso 4 – Subir transacción
print("Transaction information: {}".format(
json.dumps(confirmed_txn, indent=4)))
print("Decoded note: {}".format(base64.b64decode(
confirmed_txn["txn"]["txn"]["note"]).decode()))
print("Starting Account balance: {}
microAlgos".format(account_info.get('amount')) )
print("Amount transfered: {} microAlgos".format(amount) )
print("Fee: {} microAlgos".format(params.fee) )

account_info = algod_client.account_info(my_address)
print("Final Account balance: {}
microAlgos".format(account_info.get('amount')) + "\n")
Desarrollo de
DApp
Ejemplo de aplicación
Modelo de Subasta - Problema

Alice generalmente vende sus obras de arte a través de

conexiones personales y, a veces, mediante publicidad en las
redes sociales. Una de sus piezas de arte digital se vende por
$100, en promedio, utilizando sus técnicas de venta actuales.
Cree que podría ganar mucho más si pudiera escalar y llegar a un
público más amplio.
Modelo de Subasta - Objetivos
Alice considera las propiedades importantes para su caso de
uso:
◎ Eficiencia: Alice pasa mucho tiempo tratando de encontrar
comprador y, en última instancia, no llega a una audiencia lo
suficientemente amplia.
◎ Confianza/transparencia: Quiere llegar a un público más
amplio, pero todavía está construyendo su reputación y
necesita una manera para que tanto ella como los
compradores potenciales sepan que no son estafados.
◎ Costo: Si desea escalar a un sitio e-commerce sabe que
tendrá que renunciar a buena parte de su ganancia en tarifas.
Propuesta

Nombramos 4 propiedades de blockchain que podrían ayudar a

Alice y su caso de uso. Alice y Bob hacen una lluvia de ideas
considerando los objetivos principales de Alice y las propiedades
para las que quiere optimizar. Se les ocurre la siguiente idea:
Propuesta
Planean tokenizar la obra de arte de Alice como NFT en la BC.
Esto les da un punto de entrada al ecosistema de la cadena de
bloques y la capacidad de programar lo que quieren hacer a
continuación. Luego, construirán una dApp de subasta en la
cadena de bloques que permitirá a Alice vender su obra de arte
por un precio establecido por el mercado. La subasta se
programará en la cadena de bloques para que todos la vean y la
verifiquen de forma independiente…
Propuesta
Alice puede garantizar a sus compradores que no serán
estafados y viceversa sin necesidad de conocerlos
personalmente (confianza/transparencia). Dado que eliminan la
necesidad de que un tercero garantice el comercio, pueden
reducir sustancialmente las tarifas y Alice puede ganar más
dinero (bajo costo). Alice puede concentrarse en publicitar su
trabajo a una audiencia tan amplia como quiera a través de sus
cuentas de redes sociales o en cualquier otro lugar sin necesidad
de reunirse individualmente y generar confianza con
compradores potenciales (eficiencia).
Contratos Inteligentes

Los contratos inteligentes son programas lógicos en cadena que

pueden implementar condiciones de transferencia altamente
personalizadas. Se pueden componer con todas las demás
funciones de capa 1 (incluidos Algos, NFT, tokens fungibles) para
producir aplicaciones descentralizadas potentes y sofisticadas.
Aplicando SC en ejemplo
Volvamos al escenario de licitación de subastas y usemos
contratos inteligentes para implementar licitaciones en cadena.
Lo que esto significa es que en lugar de enviar ofertas a una
cuenta controlada por una entidad centralizada, sujeta a
ataques y puntos únicos de falla, podemos enviar esas ofertas a
un contrato inteligente, regido por código, que es abierto y
verificable públicamente por cualquier persona. Y ese código no
cambiará inesperadamente. Eso no significa que no pueda
cambiar, pero si lo hace, será público y evidente para los
usuarios. Y si no le gusta la idea de que pueda cambiar, incluso
puede programarlo desde el principio para restringir ciertos
cambios o rechazar todos los cambios en el contrato.
Smart Contracts
En resumen, se pasa de confiar en una entidad y esperar que
haga lo que prometió, a confiar en el código y saber que hará lo
que prometió, independientemente de los diferentes actores
involucrados y las diferentes motivaciones que puedan tener.

Una barra lateral importante aquí es que es fundamental que el

código de contrato inteligente sea revisado y auditado en busca
de fallas de seguridad. El código mal escrito que no tiene en
cuenta todos los posibles vectores de ataque, por supuesto, no
protegerá nada.
¿Cómo escribo SC?

◎ PyTeal: Biblioteca en Python para diseñar Smart Contracts.

◎ Beaker: Framework para desarrollo de SC en una capa
encima de PyTeal.
Diseño de Subasta
Alice y Bob analizan las características de su dApp. Enumeran los siguientes
requisitos:
1. Los vendedores deben poder crear una nueva subasta para cada obra
de arte. La obra de arte debe ser retenida por el contrato después de
que comience la subasta y hasta que cierre la subasta.
2. La subasta se puede cerrar antes de que comience, en cuyo caso la obra
de arte se devolverá al vendedor.
3. Los vendedores pueden especificar un precio de reserva que, si no se
cumple, les devolverá la obra de arte.
4. Para cada oferta, si la nueva oferta es más alta que la oferta anterior, la
oferta anterior se reembolsará al postor anterior y la nueva oferta se
registrará y mantendrá en el contrato.
5. Al final de una subasta exitosa, donde se alcanzó el precio de reserva, el
mejor postor recibirá la obra de arte y el vendedor recibirá el monto
total de la oferta.
Requisitos para ejemplo
# Clonar desde GitHub
git clone https://github.com/algorand/auction-demo

# Posicionarse en el directorio
cd auction-demo

# Ejecutando Sandbox
./sandbox down
./sandbox clean
./sandbox up
Instalación del entorno
# Python Environment
python3 -m venv venv

# Activando venv en bash

. venv/bin/activate

# Instalación de requisitos adicionales

pip3 install -r requirements.txt
Ejecución del ejemplo
# Desde Python
python3 example.py

#Cierre de Red
./sandbox down
Panorama – Método uno
Panorama – Método dos
Panorama – Método tres
Panorama – Método cuatro
Pasos posteriores...

◎ https://developer.algorand.org/
◎ https://developer.algorand.org/docs/
Bibliografia:
desarrolloactivo.com (sin fecha) Desarrolloactivo.com. Disponible en: https://desarrolloactivo.com/blog/centralized-
decentralized-distributed-p2p/ (Consultado: el 7 de junio de 2021).
Preukschat, A. (2019) Bitcoin o ‘blockchain’: ¿descentralizado o distribuido?, EL PAÍS. Disponible en:
https://retina.elpais.com/retina/2019/02/07/innovacion/1549541572_507813.html (Consultado: el 7 de junio de 2021).
Bases de Datos Distribuidas: Popularidad, Uso y Tipos (sin fecha) Tecnologias-informacion.com. Disponible en:
https://www.tecnologias-informacion.com/distribuidas.html (Consultado: el 7 de junio de 2021).
(Sin fecha) Wordpress.com. Disponible en: https://lihectortorres.files.wordpress.com/2010/09/base_de_datos_distribuidas.pdf
(Consultado: el 7 de junio de 2021).
(Sin fecha b) Unam.mx. Disponible en: http://profesores.fi-b.unam.mx/pilarang/docencia/Notas-BDDistribuidas.pdf
(Consultado: el 7 de junio de 2021).
1&1 IONOS Inc. (2019) NTP: el protocolo de sincronización para sistemas de TI, Ionos.mx. 1&1 IONOS Inc. Disponible en:
https://www.ionos.mx/digitalguide/servidores/know-how/que-es-el-ntp/ (Consultado: el 7 de junio de 2021).
F. de A. López Fuentes, “Sistemas Distribuidos” pp. 15-19, 40, 58-59, 71-72, e2015, Uam.mx. Disponible en:
http://hermes.cua.uam.mx/libros/archivos/03IXStream_sistemas_distribuidos.pdf (Consultado: el 7 de junio de 2021).
G. Kunz Arrache, presentó Diciembre 1998, “Administrador de Bases de Datos Distribuidas”, tesis de maestría, otorgada por el
Instituto Tecnológico y de Estudios Superiores de Monterrey. Disponible en: https://repositorio.tec.mx/handle/11285/628096
(Consultado: el 7 de junio de 2021)
Bibliografia:
kexugit (no date) Blockchain Fundamentals, Microsoft.com. Available at: https://docs.microsoft.com/en-us/archive/msdn-
magazine/2018/march/blockchain-blockchain-fundamentals (Accessed: June 7, 2021).
(No date)Deloitte’s 2019 Global Blockchain Survey, Deloitte.com. Available at:
https://www2.deloitte.com/content/dam/Deloitte/se/Documents/risk/DI_2019-global-blockchain-survey.pdf (Accessed: June
7, 2021).
International Journal of Scientific Research and Technology IJSRSET (no date) “Blockchain Evolution -A Survey Paper.”
Available at: https://www.academia.edu/37082843/Blockchain_Evolution_A_Survey_Paper (Accessed: June 7, 2021).
DOLADEL Retamal, Bel, Muñoz,” LA BLOCKCHAIN: FUNDAMENTOS, APLICACIONES Y RELACIÓN CON OTRAS TECNOLOGÍAS
DISRUPTIVAS” Universidad Politécnica de Catalunya, Gob.es. Available at:
https://www.mincotur.gob.es/Publicaciones/Publicacionesperiodicas/EconomiaIndustrial/RevistaEconomiaIndustrial/405/DO
LADER,%20BEL%20Y%20MU%C3%91OZ.pdf (Accessed: June 7, 2021).
Casino, F., Dasaklis, T. K. and Patsakis, C. (2019) “A systematic literature review of blockchain-based applications: Current
status, classification and open issues,” Telematics and informatics, 36, pp. 55–81.
Bibliografia:
Yaga, D. et al. (2018) Blockchain technology overview. Gaithersburg, MD: National Institute of Standards and Technology.
Available at: https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf (Accessed: June 7, 2021).
Blockchain: Elementos básicos y avanzados, Abb.com. Available at:
https://search.abb.com/library/Download.aspx?DocumentID=9AKK107046A1240&LanguageCode=es&DocumentPartId=&Actio
n=Launch (Accessed: June 7, 2021).
PKI y certificados (no date) Attachmate.com. Available at: https://www.attachmate.com/es-es/documentation/reflection-
desktop-v16/rdesktop-guide/data/t_1339.htm (Accessed: June 8, 2021).
[9] A. J. Sabolansky, presentó Septiembre 2010, “Utilizando Software Libre para un servicio de Sellado Digital
de Tiempo” pp 14-18, tesis de Licenciatura, otorgada por la Universidad Nacional De La Plata, Facultad de Ingeniería.
Disponible en: http://sedici.unlp.edu.ar/bitstream/handle/10915/4025/Tesis_.pdf?sequence=3
Bibliografia:
Maldonado J., “Protocolos de Consenso - Pilar en la Seguridad de Blockchain” sitio consultado el xx de xxx de 2021 en:
https://www.bitcobie.com/protocolos-de-consenso-pilar-en-la-seguridad-blockchain/
Kramer M., “What are Consensus Protocols” artículo digital consultado el xx de xxx de 2021 en:
https://decrypt.co/resources/consensus-protocols-what-are-they-guide-how-to-explainer
Learn, B. (2020) “Explained: What is proof of Work (PoW) in blockchain?”, Bybit.com. Bybit Learn, 8 diciembre. Disponible en:
https://learn.bybit.com/blockchain/what-is-proof-of-work-in-blockchain/ (Consultado: el 14 de junio de 2021).
Proof of Work y Proof of Stake: ¿Cuáles Son Las Diferencias? (sin fecha) Criptomonedaz.com. Disponible en:
https://criptomonedaz.com/proof-of-work-vs-proof-of-stake/ (Consultado: el 15 de junio de 2021).
What is Proof of Stake and How Does it Work? (2021) Easycrypto.ai. Disponible en: https://learn.easycrypto.ai/what-is-proof-of-
stake-and-how-does-it-work/ (Consultado: el 15 de junio de 2021).
Wood, P. (2019) “Staking: Pros and cons of Proof of Stake (PoS) as a passive income tool”, Cryptogeek.info. Patricia Wood, 19
noviembre. Disponible en: https://cryptogeek.info/en/blog/staking-pros-and-cons-of-proof-of-stake-pos-as-a-passive-income-
tool (Consultado: el 15 de junio de 2021).
Lindsey, N. (2018) Proof of Stake (PoS): What is it and how does it work?, Blocklr.com. Disponible en:
https://blocklr.com/guides/proof-of-stake-pos/ (Consultado: el 15 de junio de 2021).
Rhodes, D. (2020) What is delegated Proof of Stake? An overview of DPoS blockchains, Komodoplatform.com. Komodo
Platform Blog | En. Disponible en: https://komodoplatform.com/en/blog/delegated-proof-of-stake/ (Consultado: el 15 de junio
de 2021).
Bibliografia:
What is Proof of Authority (PoA)? (2018) Insidecryptocoins.com. Disponible en: https://www.insidecryptocoins.com/what-is-
proof-of-authority-poa/ (Consultado: el 15 de junio de 2021).
Bit2Me Academy (2019) ¿Qué es PoA (Proof of Authority - Prueba de Autoridad)?, Bit2me.com. Disponible en:
https://academy.bit2me.com/que-es-proof-of-authority-poa/ (Consultado: el 15 de junio de 2021).
What is practical byzantine fault tolerance (pBFT)? - crush crypto (2018) Crushcrypto.com. Disponible en:
https://crushcrypto.com/what-is-practical-byzantine-fault-tolerance/ (Consultado: el 21 de junio de 2021).
Malviya, H. (2017) practical byzantine fault tolerance algorithm (PBFT Consensus), Itsblockchain.com. Disponible en:
https://itsblockchain.com/practical-byzantine-fault-tolerance-algorithm-pbft-consensus/ (Consultado: el 21 de junio de 2021).
Raft Consensus Algorithm (sin fecha) Github.io. Disponible en: https://raft.github.io/ (Consultado: el 12 de julio de 2021).
Raft Consensus Algorithm - GeeksforGeeks (2018) Geeksforgeeks.org. Disponible en: https://www.geeksforgeeks.org/raft-
consensus-algorithm/ (Consultado: el 12 de julio de 2021).
No title (sin fecha) Webopedia.com. Disponible en: https://www.webopedia.com/definitions/raft-consensus-algorithm/
(Consultado: el 12 de julio de 2021).
Pérez-Solá C., Herrera-Joancomartí J., “Bitcoins y el problema de los generales bizantinos” artículo digital encontrado en
Studylib.es. Disponible en: https://studylib.es/doc/5180485/bitcoins-y-el-problema-de-los-generales-bizantinos (Consultado:
el 12 de julio de 2021).
Credits

◎ Plantilla de la presentacion: SlidesCarnival

◎ Iconos Unsplash