An
´
alisis de la capacidad de la placa ESP32
para integrar sistemas IoT descentralizados
Analysis of the ESP32 board to integrate decentralized IoT systems
Ciro Edgardo Romero
†1
, and Alejandro Elustondo
∗2
†
Dpto. de I + D + i, C&S Informatica S.A.
Buenos Aires, Argentina
1
cromero@cys.com.ar
∗
XDK2MAM for IOTA Foundation
Buenos Aires, Argentina
2
alejandro.elustondo@ext.iota.org
Abstract—Some years ago, articles and commercial
products started using ESP32 as its core. This tendency
has helped cyber-physic systems to start evolving into
more complex models. Among them, one can quote those
used in distributed computing models. Nevertheless,
those kinds of systems face the difficulties of software
development and also the uncertainty caused by the use
of new technologies. In this article one can read the
experience of developing a system capable of collecting
environmental variables integrated to decentralized
network. The objectives proposed in this article are:
to develop a proof of concept where one can see the
problems that may appear when integrating a project
of this nature with a decentralized network; to use
different open-source technologies that are enabled for
decentralized environments and to analyse the viability
for productive developments.
Keywords: ESP32; IOTA; Internet of things; Blockchain.
Resumen— En los ´ultimos a ˜nos comenzaron a verse
art´ıculos y productos comerciales que emplean la placa
ESP32 como n ´ucleo. Esta tendencia ha servido para que los
sistemas ciber-f´ısicos comiencen a evolucionar a modelos
m´as complejos. Dentro de estos, se hallan los utilizados
en el modelo de la computaci ´on distribuida. No obstante,
este tipo de sistemas poseen problem´aticas propias del
desarrollo de software, sumadas a la incertidumbre
deveniente del uso de las nuevas tecnolog´ıas. En este
trabajo se detalla la experiencia al desarrollar un sistema
capaz de recolectar variables ambientales integrado con
una red descentralizada. Los objetivos del mismo son:
realizar una prueba de concepto donde se vean las
problem´aticas a resolver al momento de integrar un
proyecto de la naturaleza descripta anteriormente en una
red descentralizada; utilizar las diferentes tecnolog´ıas
abiertas, disponibles para entornos descentralizados, y
analizar la viabilidad para desarrollos productivos.
Palabras clave: ESP32; IOTA; Internet of things;
Blockchain.
I. Introducci
´
on
Los sistemas ciber-f
´
ısicos se vieron favorecidos por
el avance en el poder de c
´
omputo, la miniaturizaci
´
on
electr
´
onica y las interconexiones de redes, en un am-
plio espectro de nuevas capacidades que antes no eran
posibles [1]. Estos sistemas, utilizan componentes in-
form
´
aticos digitales que interact
´
uan directamente con
el mundo a su alrededor. En este tipo de desarrollos
la arquitectura del sistema define la ruta a trav
´
es de la
cual un dispositivo se conecta a otro; a su vez, esta ruta
determina cu
´
an flexible puede ser el sistema, al mismo
tiempo que establece cu
´
an receptivo y confiable puede
llegar a ser [2]. Desde hace algunos a
˜
nos, apareci
´
o
un concepto conocido como Internet de las Cosas o
IoT (por sus siglas en ingl
´
es, Internet of Things) que
utiliza las tecnolog
´
ıas que se ven involucradas en los
sistemas de esta naturaleza. Un sistema IoT involucra
elementos electr
´
onicos que interact
´
uan con servicios
inform
´
aticos. Este sistema puede ser planteado como
una arquitectura cliente-servidor con el prop
´
osito de
que los profesionales especializados en cada elemento,
pueden centrar esfuerzos en su campo de expertise. No
obstante, la arquitectura centralizada enfrenta varios
problemas.
A. Caso de estudio y propuesta de solucion
En el presente articulo, se plantea un sistema
m
´
ınimo que incursiona en la integraci
´
on de un dis-
positivo con conexi
´
on a internet (propio de los sis-
temas IoT) con una red descentralizada. Desde esta
experiencia se abordan algunas problem
´
aticas de las
antes mencionadas y se proponen soluciones para las
mismas. El objetivo principal de realizar este trabajo,
es dejar registro sobre el proceso de desarrollo de
un sistema de las caracter
´
ısticas citadas anteriormente,
como una base para implementaciones similares en
diversas aplicaciones.
II. Problem
´
atica de seguridad en sistemas
ciber-f
´
isicos
Seg
´
un MITRE ATT&CK, una de las problem
´
aticas
de los sistemas clientes-servidor es que, todas las
operaciones inform
´
aticas de cada elemento de la red se
llevan a cabo utilizando un
´
unico servidor. Esto crea un
punto cr
´
ıtico central donde una falla provoca que todo
el sistema est
´
e no disponible. Adem
´
as, la arquitectura
centralizada es un objetivo f
´
acil de varios tipos de
ataques de seguridad y privacidad, ya que todos los
datos de IoT recopilados desde diferentes dispositivos
Recibido: 26/02/22; Aceptado: 04/05/22
Creative Commons License - Attribution-NonCommercial-
NoDerivatives 4.0 International (CC BY-NC-ND 4.0)
https://doi.org/10.37537/rev.elektron.6.1.142.2022
Original Article
Revista elektron, Vol. 6, No. 1, pp. 41-45 (2022)
ISSN 2525-0159
41
est
´
an bajo la autoridad total de un
´
unico servidor [3].
Las debilidades y vulnerabilidades del IoT pueden
ser mitigadas utilizando tecnolog
´
ıa descentralizada,
tambi
´
en conocida como DLT (por sus siglas en ingles,
Distributed Ledger Technology).
A. Empleo de tecnolog´ıas descentralizada
Las tecnolog
´
ıas descentralizadas resuelven las l
´
ıneas
de fallas de seguridad presentes en los entornos
p
´
ublicos sin confianza, donde la mayor
´
ıa de los dis-
positivos IoT est
´
an conectados entre s
´
ı [4]. Dichos
entornos, representan las redes existentes a las cuales
los dispositivos se conectan para poder tener acceso a
internet. La capacidad de mantener la integridad de las
transacciones al descentralizar la comunicaci
´
on entre
los nodos participantes en la red, elimina la necesidad
de una autoridad central. Adem
´
as, su naturaleza dis-
tribuida peer-to-peer
1
puede abordar las deficiencias
de los modelos cliente-servidor en las soluciones de la
nube. Si bien la convergencia de IoT y DLT puede po-
tenciar las implementaciones sobre estas tecnolog
´
ıas.
Su adopci
´
on todav
´
ıa presenta varios problemas, tales
como la escalabilidad, algoritmos de consenso, pri-
vacidad de datos , eficiencia, disponibilidad, alma-
cenamiento, interoperabilidad, estandarizaci
´
on, entre
otros. Adem
´
as, no hay consenso hacia ning
´
un modelo
de referencia o mejores pr
´
acticas que especifiquen
c
´
omo se deben integrar las tecnolog
´
ıas correspondi-
entes a cada campo [5].
III. Entorno distribuido
Desde un punto de vista te
´
orico, un sistema ciber-
f
´
ısico podr
´
ıa integrar objetos inteligentes con seres
humanos de forma estandarizada. El paradigma IoT
buscar conectar entre s
´
ı a operadores humanos y/o
consumidores del sistema, a trav
´
es de un canal seguro
y confiable. Esto implica la implementaci
´
on de una red
distribuida que demuestre confianza en su dise
˜
no, al
mismo tiempo que pueda ser integrada a otras redes
[6]. En este punto, el salto tecnol
´
ogico necesario para
lograrlo es alcanzado por la tecnolog
´
ıa blockchain la
cual proporciona una red de registro
´
unico, consen-
suado y distribuido [7]. Los gestores que intervienen,
obran como agentes de confianza al verificar la iden-
tidad y las credenciales de la red. Dicha red utiliza el
formato de cadena de bloques, vinculados de manera
segura, para que la informaci
´
on pueda ser rastreada
[8].
El empleo de la tecnolog
´
ıa blockchain posee sus
propias problem
´
aticas al momento de su imple-
mentaci
´
on. El costo asociado para cada transacci
´
on es
un punto de an
´
alisis a tener en cuenta, ya que este
puede ser elevado seg
´
un el tr
´
afico que se necesite en
la red.
1
red en la que todos, o algunos, nodos funcionan sin clientes
ni servidores fijos; comport
´
andose igualitariamente entre s
´
ı. Ver:
AUTORES, VARIOS (2015). ”10.Peer-To-Peer”. Distributed Systems,
Concepts and Design (en ingl
´
es) (5ª edici
´
on). Pearson. pp. 423-461.
ISBN 978-01-3214-301-1
A. IOTA como red distribuida
En una red blockchain, cada nodo tiene la necesidad
de que se llegue a un consenso, antes de lanzar un
nuevo bloque. Si no se mantiene esta sincronicidad,
obtenemos bloques ”hu
´
erfanos”, los cuales comprom-
eten el rendimiento general de la red [9]. Esta prob-
lem
´
atica se ve resuelta con la propuesta innovadora de
IOTA Foundation, de utilizar una arquitectura propia
conocida como The Tangle. La misma est
´
a basada en
un concepto matem
´
atico llamado Grafo Ac
´
ıclico Di-
rigido (DAG). Dicha arquitectura es un libro mayor
distribuido abierto, gratuito y escalable, dise
˜
nado para
admitir la transferencia de datos y valor sin proble-
mas. En esta estructura, los bloques ”hu
´
erfanos” se
tienen presentes por ser una consecuencia inevitable
de una alta tasa de transacciones. A diferencia de los
sistemas blockchain, estos se fusionan nuevamente en
el sistema, sin generar desperdicios [10]. Todas las
transacciones en blockchain deben esperar hasta que
se incluyan en un bloque. Debido a las limitaciones
en el tama
˜
no del bloque y al tiempo de producci
´
on
de este, se crea congesti
´
on y tiempos de espera para
las transacciones. En el caso de The Tangle esto no
ocurre, ya que al ser un grafo ac
´
ıclico dirigido, cada
transacci
´
on se adjunta a dos transacciones anteriores,
es por esto que el protocolo puede procesar varias
cantidades de transacciones en paralelo. En la figura
1 se muestra la comparativa del cuello de botella
del tr
´
afico de bloques producido por una arquitectura
blockchain y por la arquitectura Tangle
Fig. 1. Cuello de botella de Blockchain vs Tangle
2
.
2
Imagen tomada de https://commons.wikimedia.org/wiki/File:
Blockchain vs tangle bottleneck.png
Revista elektron, Vol. 6, No. 1, pp. 41-45 (2022)
ISSN 2525-0159
42
http://elektron.fi.uba.ar
En esta red no hay bloques y no existen los
mineros. Cuando una transacci
´
on es enviada, valida
simult
´
aneamente otras dos transacciones. Esto permite
que IOTA supere las limitaciones de costo y escala-
bilidad de blockchain sumado a que garantiza que la
informaci
´
on sea confiable y no pueda ser manipulada
ni destruida. La IOTA Foundation, describe su red
como una tecnolog
´
ıa de registro de datos distribuida
y de c
´
odigo abierto que permite de forma segura el
intercambio de informaci
´
on y valor, dado que soporta
micro-transacciones gratuitas con bajos recursos de
hardware [11].
IV. Adquisici
´
on de datos de forma distribuida
El esquema de un sistema ciber-f
´
ısico, de arquitec-
tura distribuida, supone una interacci
´
on de diferentes
elementos comunic
´
andose entre s
´
ı de manera indepen-
diente [12]. Basado en este concepto, se puede interpre-
tar que existir
´
an dispositivos que realicen mediciones
y las env
´
ıen a una base de consulta colectiva. Por
otro lado, habr
´
a dispositivos que funcionar
´
an como
actuadores, y que realizar
´
an acciones sobre el sistema
basados en la mediciones anteriores. En la figura 2
se muestra un esquema de posibles elementos que
formar
´
ıan parte de un sistema distribuido.
Fig. 2. Ejemplo de sistema distribuido
A. Sistemas IoT con ESP32
En nuestra experiencia, la placa ESP32 es una buena
alternativa para el desarrollo y mantenimiento de sis-
temas. La misma es autor
´
ıa de la empresa Espressif
Systems, y representa una serie de microcontroladores
de bajo costo. Se adec
´
ua a diversos tipos de imple-
mentaciones por su bajo consumo de energ
´
ıa, sus
m
´
ultiples entornos de c
´
odigo abierto y sus bibliote-
cas [13]. Al mismo tiempo, posee una extensa docu-
mentaci
´
on y varias comunidades activas con ejemplos
para programarla en lenguaje C/C++ y Python, entre
otros.
V. Desarrollo de prueba de concepto
Al plantear un entorno distribuido se pueden pre-
sentar diversos elementos que conforman la totalidad
del sistema de una manera compleja. Desde este punto,
es interesante realizar una prueba de concepto simpli-
ficando la interacci
´
on que existir
´
a en el sistema uti-
lizando dispositivos que tendr
´
an un comportamiento
elemental. El entorno distribuido puede ser descripto
como un sistema IOT, desde su entendimiento m
´
as
sencillo. Sobre esta idea, se tienen que abordar las
problem
´
aticas de:
• Complejidad del sistema general
• Capacidades limitadas en los dispositivos
• Diversidad de tecnolog
´
ıas coexistiendo
• Seguridad inform
´
atica
• Costos
• Falta de rigurosidad en el tratamiento de datos
• Decisiones que comprometen la eficiencia
Desde el Departamento de Investigaci
´
on, Desarrollo
e Innovaci
´
on de la empresa C & S Inform
´
atica S.A,
se realiz
´
o una prueba de concepto como experiencia
para abordar algunas de las problem
´
aticas anteriores
[14]. Sobre estas pruebas se logra la comunicaci
´
on
entre un nodo sensor con una red distribuida. Los
datos recolectados por un nodo basado en la placa
ESP32, son enviados a la red IOTA (elegida como red
distribuida), con la intenci
´
on de simular la comuni-
caci
´
on t
´
ıpica de un sensor inteligente dentro de un
sistema no centralizado. Al mismo tiempo, se intenta
desarrollar un programa f
´
acil de mantener desde la
perspectiva del dispositivo, a trav
´
es de un lenguaje de
programaci
´
on de f
´
acil lectura.
A. C´odigo bare-metal
Seg
´
un Tollervey, autor del libro Programming with
MicroPython, Python es un lenguaje de programaci
´
on
de c
´
odigo interpretado f
´
acil de aprender y legible
[15]. Este lenguaje multiparadigma es capaz de sopor-
tar programaci
´
on imperativa, programaci
´
on funcional
y, parcialmente, orientada a objetos. Adem
´
as, es un
lenguaje din
´
amico y compatible con diversas platafor-
mas. Basado en el mismo lenguaje existe Micropy-
thon, que es una implementaci
´
on sencilla y eficiente
con todas las funciones del Python 3, salvo algunas
excepciones. Incluye un subconjunto peque
˜
no de la
biblioteca est
´
andar, reimplementada y optimizada para
ejecutarse en microcontroladores. Micropython se eje-
cuta de tal forma que las operaciones y servicios sean
manejados como sistema operativo [16].
B. Nodo sensor basado en ESP32
El trabajo descrito en este articulo utiliz
´
o un dis-
positivo que funciona como un nodo recolectar de
variables ambientales. El nodo cuenta con un m
´
odulo
BMP180 [17], basado en el sensor hom
´
onimo, para
medir presi
´
on, temperatura y humedad de la placa de
desarrollo. Dicha placa, ejecuta la configuraci
´
on propia
de sus componentes y los servicios desarrollados para
cada prop
´
osito. Tambi
´
en se conecta un LED tipo RGB y
se configuran diferentes colores, asociados al estado de
la placa. De esta manera se puede chequear la situaci
´
on
del dispositivo una vez desconectado de la PC.
Revista elektron, Vol. 6, No. 1, pp. 41-45 (2022)
ISSN 2525-0159
43
http://elektron.fi.uba.ar
En la figura 3 se muestran los componentes del nodo
sensor basado en la ESP32
Fig. 3. Elementos que componen el nodo sensor
El dispositivo se conecta a internet y realiza una
configuraci
´
on del reloj interno, realizado una petici
´
on
a un servidor p
´
ublico NTP
3
. El comportamiento gen-
eral comienza cuando se comunica con el sensor para
realizar la medici
´
on. Los datos de esta, se guardan en
un objeto dentro del programa ejecutado en la ESP32.
A este objeto, se le suman el UUID (identificador
´
unico de dispositivo), hora y fecha de la medici
´
on (en
formato UNIX timestamp). Antes de enviar la infor-
maci
´
on, esta debe comprimirse a trav
´
es de una funci
´
on
criptogr
´
afica hash; o simplemente conocida como hash.
Este es un algoritmo que transforma cualquier bloque
de datos en una nueva serie de caracteres con una
longitud fija. Independientemente de la longitud de
los datos de entrada, el valor de salida tendr
´
a siempre
la misma longitud [18]. Por ultimo, se realiza el env
´
ıo
de los datos en formato JSON a trav
´
es de una request.
Mediante de esta prueba de concepto, se recrea el
comportamiento b
´
asico de un sistema de recolecci
´
on y
distribuci
´
on de datos. Al tener un sensor que funcione
como nodo conectado a internet, se logra convertir una
variable f
´
ısica en una variable utilizable por un sistema
inform
´
atico. Posteriormente, este dato es enviado a la
red distribuida IOTA para que pueda ser consumido
por otros sistemas.
C. Red distribuida
Se busc
´
o generar una red de topolog
´
ıa colectiva,
donde los nodos se vinculen unos a otros de modo
que ninguno de ellos tenga poder de filtro sobre la
informaci
´
on que se transmite. En una primera versi
´
on,
para comunicarse con The Tangle se utiliz
´
o un nodo
IRI
4
. Esta versi
´
on tuvo que ser descartada por quedar
obsoleta. Siguiendo las propias recomendaciones de la
IOTA Foundation, se migr
´
o el desarrollo a IOTA 1.5,
el cual representa una evoluci
´
on del mismo protocolo.
Este nuevo protocolo brinda especificaciones especiales
3
Protocolo de tiempo de red , utilizado para sincronizar los
relojes de los dispositivos con alguna referencia de tiempo. Ver:
http://www.ntp.org/ntpfaq/NTP-s-def.htm
4
Ver: https://github.com/iotaledger/iri
que dicta c
´
omo deben comportarse los nodos de IOTA.
Desde este concepto se desprende Hornet, una imple-
mentaci
´
on escrita en Go, que proporciona capacidades
de nodo e incluye el soporte completo de la actual-
izaci
´
on de la red [19]. Los nodos se presentan como dos
interfaces para desarrollar e integrar las aplicaciones.
Estas funcionan como APIs de bajo nivel permitiendo
la comunicaci
´
on entre dos aplicaciones
• API REST: permite a los clientes interactuar con
The Tangle y comunicarse con los nodos. De esta
manera puede comunicarse con la red a trav
´
es de
mensajes (enviar y recibir) y realizar pruebas de
trabajo.
• Eventos de la API: permite a los clientes sondear
nodos en busca de nuevos mensajes y otros even-
tos. Este tipo de API es
´
util para crear aplicaciones
como billeteras digitales (conocidas como wallets)
que necesitan monitorear The Tangle para actual-
izaciones de los saldos de ciertas direcciones.
VI. Comunicaci
´
on en la red
Cada nodo se puede identificar de forma individ-
ual mediante un identificador
´
unico (del ingl
´
es peer
identity), tambi
´
en llamado PeerId. Las conexiones con
un nodo IOTA, se establecen a trav
´
es de un protocolo
conocido como peer discovery que se utiliza para ex-
poner una interfaz que proporcione una lista de nodos
verificados. La implementaci
´
on del protocolo propor-
ciona una lista codificada y confiable, administrada
por la IOTA Foundation y sus colaborares [20] . Estos
protocolos se identifican de manera
´
unica, y autentican
los paquetes enviados, utilizando criptograf
´
ıa basada
en clave p
´
ublica, o PKC (por sus siglas en ingl
´
es, public
Key-based cryptography). En esta versi
´
on del proyecto, se
utiliz
´
o un nodo p
´
ublico provisto por la misma comu-
nidad de IOTA
5
. Los dispositivos se comunicaban con
el nodo, enviando requests a la ruta /api/v1/messages,
con la informaci
´
on recolectada a trav
´
es de sus sensores.
Esta era enviada en formato JSON con la siguiente
estructura de ejemplo:
{
”networkId ” : ”94668224127 63346725” ,
” parentMessageIds ” : [
”222 e88a63e5aca8ef4 ( . . . ) ” ,
” a22137ebe61435c6d0 ( . . . ) ” ,
”a6db9d0b3ecb274d90 ( . . . ) ” ,
” fd31d9c926b5d97ae0 ( . . . ) ”
] ,
”payload ” : {
” type ” : 2 ,
” index ” : ”68656 c6 c 6f 2 077 6 f7 2 6 c6 4 ” ,
” data ” : ”5370616 d66 ( . . . ) ”
} ,
”nonce ” : ”2102864”
}
Al enviar el mensaje, el nodo intentar
´
a autocomple-
tar los campos networkId, parentMessageIds y nonce si
5
Ver lista de nodos. Link: https://thetangle.org/nodes
Revista elektron, Vol. 6, No. 1, pp. 41-45 (2022)
ISSN 2525-0159
44
http://elektron.fi.uba.ar
estos faltasen. Si la comunicaci
´
on es exitosa, el mensaje
se almacenar
´
a en The Tangle. Este punto final devolver
´
a
el identificador del mensaje creado. Si faltara payload, el
mensaje se generar
´
a igualmente pero vac
´
ıo. Cuando la
transacci
´
on es exitosa, se devuelve un hash de referen-
cia que representa el identificador de la transacci
´
on.
Este ser
´
a utilizado por otros elementos dentro del
sistema para localizar y decodificar la informaci
´
on
insertada.
En la figura 4 se muestra un diagrama para ilustrar
el esquema de comunicaci
´
on.
Fig. 4. Comunicaci
´
on entre elementos del sistema
VII. Conclusiones
La curva de aprendizaje de Micropython fue un
factor clave para el desarrollo de la prueba de con-
cepto. Sumado a esto, la practicidad para adquirir la
placa ESP32 en el mercado, vuelve a este conjunto de
opciones una buena alternativa para el desarrollo de
diversos sistemas embebidos.
En la implementaci
´
on de proyectos cr
´
ıticos, integrar
servicios para la transferencia y encriptaci
´
on de datos
provee una capa de seguridad interesante. Adicional-
mente, los sistemas ciber-f
´
ısicos pueden ver mejorada
la confianza en sus agentes intervinientes. Por otro
lado, la red IOTA reduce significativamente los costos
asociados a la implementaci
´
on de una red. Todo esto
favorece a los usuarios de placas como la ESP32 y otras
de similares prestaciones.
El c
´
odigo para comunicarse con la red descen-
tralizada puede ser integrado con un sistema de
medici
´
on inteligente de cualquier naturaleza. Sus
m
´
etodos pueden ser perfectamente migrados a otros
lenguajes propios de otros microprocesadores. Es decir,
podr
´
ıa descentralizarse un sistema productivo, ya in-
stalado, realizando peque
˜
nas incorporaciones de hard-
ware y software.
El resultado final del trabajo realizado es un sistema
m
´
ınimo perfectamente funcional, capaz de ser escalado
en una implementaci
´
on que requiera una medici
´
on
ambiental, sin depender de un servidor central.
VIII. Trabajo futuro
Al momento de escribir este art
´
ıculo Espressif lanz
´
o
la versi
´
on ESP32-S3 mejorada. Este nuevo kit de de-
sarrollo muestra m
´
as y mejores prestaciones que sus
predecesores. Seg
´
un el fabricante, es un microcontro-
lador ideal para aplicaciones IoT. Por otra parte, la
IOTA Foundation se encuentra en proceso de lanzar una
actualizaci
´
on de la red para mejorar la integraci
´
on. Sin
embargo, hasta el momento la misma se encuentra en
una etapa experimental y ninguno de los par
´
ametros
est
´
a finalizado. Por tal motivo, se seguir
´
an realizando
experimentos para generar soluciones con la
´
ultima
versi
´
on de todos sus elementos y componentes.
References
[1] K. Rose, S. Eldridge, and L. Chapin, “The internet of things: An
overview,” The internet society (ISOC), vol. 80, pp. 1–50, 2015.
[2] C. Rowland, E. Goodman, M. Charlier, A. Light, and A. Lui,
Designing connected products: UX for the consumer Internet of
Things. ” O Reilly Media, Inc.”, 2015.
[3] M. ATT&CK, “Mitre att&ck,” URL: https://attack. mitre. org, 2021.
[4] B. Farahani, F. Firouzi, and M. Luecking, “The convergence
of iot and distributed ledger technologies (dlt): Opportunities,
challenges, and solutions,” Journal of Network and Computer
Applications, vol. 177, p. 102936, 2021.
[5] H. F. Atlam and G. B. Wills, “Intersections between iot and
distributed ledger,” in Advances in Computers. Elsevier, 2019,
vol. 115, pp. 73–113.
[6] R. Buyya and A. V. Dastjerdi, Internet of Things: Principles and
paradigms. Elsevier, 2016.
[7] J. Kehrli, “Blockchain explained,” Netguardians [en l´ınia].[Data
de consulta: 25 de juny de 2017]¡ https://www. netguardians.
ch/news/2016/11/17/blockchain-explained-part-1, 2016.
[8] V. Gisbert Soler and A. I. P
´
erez Molina, “Blockchain vs iso 9001:
2015,” 3C Tecnolog´ıa, vol. 8, no. 2, pp. 37–48, 2019.
[9] I. Fundation, “Coordinator. part 2: Iota is a
dag, not a blockchain,” https://blog.iota.org/
coordinator-part-2-iota-is-a-dag-not-a-blockchain-2df8ec85200f/,
11 2018.
[10] ——, “The transparency compendium,” https://blog.iota.org/
the-transparency-compendium-26aa5bb8e260/, 06 2017.
[11] W. F. Silvano and R. Marcelino, “Iota tangle: A cryptocur-
rency to communicate internet-of-things data,” Future Gener-
ation Computer Systems, vol. 112, pp. 307–319, 2020.
[12] R. Hadidi, J. Cao, M. S. Ryoo, and H. Kim, “Robustly executing
dnns in iot systems using coded distributed computing,” in
Proceedings of the 56th Annual Design Automation Conference 2019,
2019, pp. 1–2.
[13] A. Maier, A. Sharp, and Y. Vagapov, “Comparative analysis and
practical implementation of the esp32 microcontroller module
for the internet of things,” in 2017 Internet Technologies and
Applications (ITA). IEEE, 2017, pp. 143–148.
[14] C. E. Romero, A. M. Elustondo, R. K. Der Boghosian, and M. C.
Fontela, “Nodo experimental de registro e inmutabilidad de
variables ambientales,” in III Simposio Argentino de Inform´atica
Industrial e Investigaci´on Operativa (SIIIO 2020)-JAIIO 49 (Modal-
idad virtual), 2020.
[15] V. Frittelli, D. Serrano, R. Teicher, F. Steffolani, M. Tartabini,
J. Fern
´
andez, and G. Bett, “Uso de python como lenguaje inicial
en asignaturas de programaci
´
on,” Editor Responsable, vol. 132,
2013.
[16] N. H. Tollervey, Programming with MicroPython: embedded pro-
gramming with microcontrollers and Python. ” O’Reilly Media,
Inc.”, 2017.
[17] Bosch, “Bmp180,” https://ae-bst.resource.bosch.com/media/
tech/media/product flyer/BST-BMP180-FL000.pdf, 04 2013.
[18] B. Preneel, “Cryptographic hash functions,” European Transac-
tions on Telecommunications, vol. 5, no. 4, pp. 431–448, 1994.
[19] I. Fundation, “Hornet. community driven iota node,” https://
wiki.iota.org/hornet/welcome, 11 2021.
[20] T. Neudecker and H. Hartenstein, “Network layer aspects of
permissionless blockchains,” IEEE Communications Surveys &
Tutorials, vol. 21, no. 1, pp. 838–857, 2018.
Revista elektron, Vol. 6, No. 1, pp. 41-45 (2022)
ISSN 2525-0159
45
http://elektron.fi.uba.ar
Enlaces de Referencia
- Por el momento, no existen enlaces de referencia
Copyright (c) 2022 Ciro Edgardo Romero, Alejandro Elustondo
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Revista elektron, ISSN-L 2525-0159
Facultad de Ingeniería. Universidad de Buenos Aires
Paseo Colón 850, 3er piso
C1063ACV - Buenos Aires - Argentina
revista.elektron@fi.uba.ar
+54 (11) 528-50889