25437

Vista previa del material en texto

Evaluación cuantitativa de mineŕıa de
criptomonedas en la Universidad de los Andes
Juan David Serrano Mugica
Ph.D Harold Enrique Castro Barrera
Noviembre 2021
Proyecto de grado presentado como postulación para el t́ıtulo de Ingeniero de
Sistemas y Computación
Departamento de Ingenieŕıa de Sistemas y Computación
Universidad de los Andes
Colombia
1
Contents
1 Contexto 3
1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Utilización actual de recursos . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Suposiciones y Restricciones . . . . . . . . . . . . . . . . . 4
2 Minado de Criptomonedas 5
2.1 Criptomonedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Algoritmos de consenso y prueba de esfuerzo . . . . . . . . . . . 6
2.4 Unidades de procesamiento gráfico (GPU) . . . . . . . . . . . . . 7
2.5 Centralización de la red . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 ASIC y FPGA . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2 Fondos de mineŕıa . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Algoritmos basados en prueba de esfuerzo duros en memoria . . 10
2.7 Protocolos de consenso basados en prueba de X . . . . . . . . . . 11
3 Alternativas 12
3.0.1 Compatibilidad del software de mineŕıa con anti-virus . . 12
3.0.2 Mineŕıa con CPU . . . . . . . . . . . . . . . . . . . . . . . 13
3.0.3 Tamaño de scratchpad . . . . . . . . . . . . . . . . . . . . 13
3.0.4 Virtualización y GPU Passthrough . . . . . . . . . . . . . 14
4 Propuesta 14
4.1 Arquitectura y contexto . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Monitor de recursos computacionales y desempeño . . . . . . . . 16
4.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Consumo regular de recursos y ajuste de resultados . . . . . . . . 21
4.5 Calculo de rentabilidad . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Conclusiones 24
2
1 Contexto
1.1 Introducción
La Universidad de los Andes y el Departamento de Ingenieŕıa de Sistemas
y Computación cuentan con una cantidad considerable de recursos computa-
cionales. Gran parte de estos recursos son usados por los estudiantes y docentes
en labores académicas y de investigación. Sin embargo, gran parte del tiempo
estos equipos no son utilizados y, cuando lo son, solo se utiliza una pequeña
fracción de sus capacidades [12]. El auge de las criptomonedas en años recientes
ha mostrado ser un mercado lucrativo donde se invierten en recursos computa-
cionales con el fin de minar alguna divisa digital. Teniendo esto en cuenta, surge
la duda de si para una institución como la universidad seŕıa rentable explotar
sus recursos computacionales, cuando estos no están siendo utilizados, para mi-
nar criptomonedas y tener una fuente de ingresos adicional. El propósito de este
proyecto es justificar de forma cuantitativa por qué seŕıa o no rentable para la
universidad realizar estas actividades.
1.2 Utilización actual de recursos
En la universidad se invierte en infraestructura tecnológica con el objetivo de
proveer a los estudiantes y profesores con equipos en los que puedan realizar
sus actividades. Estos equipos deben poseer un alto poder computacional para
que las tareas se lleven a cabo de forma eficiente y deben de estar disponibles
la mayor cantidad de tiempo. La disponibilidad es un atributo de calidad dif́ıcil
de cumplir porque suele ser costoso. Gran parte de las técnicas para alcanzar
una alta disponibilidad llevan a introducir redundancia al sistema. Con esto en
mente, la universidad ha logrado ofrecer servicios de tecnoloǵıa con un alto poder
computacional a una alta disponibilidad a costa de tener una baja utilización de
la mayoŕıa de sus equipos. Esto se puede demostrar gracias a estudios previos
donde se llegaron a estas conclusiones tomando medidas sobre el consumo de
recursos en las salas de computación. En la imagen 1 se hace evidente que el
consumo de CPU a lo largo de un d́ıa cualquiera en una de estas salas no supera
el 10% de su capacidad. Más aún, estos datos se tomaron durante el d́ıa en
horarios hábiles, por lo que si se tienen en cuenta las horas de la noche cuando
la universidad esta cerrada el consumo podŕıa llegar a ser aún más bajo.
Aśı mismo, se monitoreó el consumo de memoria en las salas Waira como se
puede ver en la figura 2. Nuevamente, el uso de memoria promedio no supera
el 30%, lo que implica, que este recurso también es sub-utilizado.
1.2.1 Objetivos
Ciertamente, la razón por la que la universidad invierte en equipos de com-
puto es para soportar las labores académicas que se llevan a cabo. Sin em-
bargo, dado que los recursos son sub-utilizados es de interés encontrar formas
de rentabilizar su utilización. Por esta razón, el objetivo principal del proyecto
3
Figure 1: Consumo promedio de CPU en salas Waira y Turing. Tomado de [30]
Figure 2: Consumo promedio de memoria en sub-salas Waira. Tomado de [12]
es descubrir si para la Universidad de los Andes seŕıa rentable, desde un punto
de vista económico y técnico, utilizar sus recursos computacionales para minar
criptomonedas. Adicionalmente, como objetivo secundario, se quiere que los
conocimientos adquiridos durante el desarrollo del proyecto sienten las bases
para propuestas de investigación sobre el minado de criptomonedas.
1.2.2 Suposiciones y Restricciones
El supuesto más importante para el desarrollo de este proyecto fue que se teńıa
acceso a los recursos computacionales del Departamento de Ingenieŕıa de Sis-
temas y Computación. Una parte del proyecto consistió de identificar qué recur-
sos computacionales cumpĺıan con los requisitos necesarios para poder realizar
el minado de criptomonedas. Como se verá más adelante, fue importante tener
alternativas sobre la infraestructura para llevar a cabo estas pruebas ya que no
todos los componentes cumpĺıan con los requisitos. Otro supuesto importante
para llevar a cabo el proyecto fue tener las herramientas para el monitoreo de
potencia de las máquinas. Finalmente, es importante resaltar que aunque el
4
proyecto trata de un análisis de rentabilidad sobre el minado de criptomonedas,
este con base en la infraestructura computacional y no a las fluctuaciones de
precio a las cuales están sujetos estos activos. En ningún momento a lo largo
del proyecto se intentará predecir el precio futuro de las criptomonedas, solo se
usaran los precios históricos.
2 Minado de Criptomonedas
Una parte importante del tiempo que se invirtió para realizar este proyecto
se usó para investigar sobre las convenciones y prácticas para el minado de
criptomonedas. El minado de criptomonedas posee un componente práctico im-
portante con el que se deb́ıa familiarizar. A diferencia de otras áreas de investi-
gación, estos temas no solamente son abordaos en publicaciones académicas de
revistas de renombre, también gran parte de los avances son publicados por or-
ganizaciones o grupos que buscan promocionar sus nuevas tecnoloǵıas en canales
no académicos y ¨white papers¨. [14]
2.1 Criptomonedas
Para empezar, las criptomonedas son divisas digitales que hacen uso de teoŕıa
criptográfica para validar las transacciones que se realizan con ellas. Las crip-
tomonedas en su mayoŕıa se caracterizan por cumplir tres propiedades. En
primer lugar,el anonimato; un usuario que realiza transacciones con la crip-
tomoneda tiene acceso a los recursos asignados a su cuenta, sin embargo, mien-
tras que él no divulgue su identidad podrá conservar un cierto grado de anon-
imato. En segundo lugar, no debe depender de una autoridad central. Las
criptomonedas son, en su mayoŕıa, sistemas distribuidos donde el historial de
las transacciones es de acceso publico, lo que permite que cualquier individuo
o persona pueda verificar la validez de las transacciones sinrequerir del per-
miso de una autoridad central. Finalmente, la tercera caracteŕıstica de una
criptomoneda es que posee un protocolo de consenso que define los lineamientos
para corroborar la validez de cualquier transacción [25] e identificar posibles
inconsistencias. Hasta 2008 uno de los mayores problemas a los que se enfrenta-
ban las criptomonedas era poder detectar cuando un usuario incurŕıa en un
doble gasto [28]. Sin embargo, esto fue resuelto con la aparición de Bitcoin y
el protocolo de consenso propuesto [20]. Bitcoin fue la primera criptomoneda
en popularizarse y en base a ella es que los protocolos y mecanismos de otras
criptomonedas surgieron. Por esta razón, se toma a Bitcoin como caso base
para explicar los conceptos de las criptomonedas en general.
2.2 Blockchain
Blockchain es un almacén de datos transparente, descentralizado, replicado y
resiliente [14]. Existen dos tipos de blockchain: los privados y los públicos. En
los blockchain privados, también conocidos como permitidos, las identidades
5
de todos los nodos son conocidas y se consideran de confianza. Además, las
transacciones que entran al registro deben ser validadas por una autoridad cen-
tral [14]. Por otro lado, los blockchain públicos permiten a cualquier nodo entrar
y salir de la red a su disposición [20] y sin que este deba revelar su identidad.
Además, es por consenso de la red que se aprueban las transacciones que entran
al registro. En el caso de las criptomonedas estas usualmente usan del esquema
público para validar las transacciones. De ahora en adelante cada vez que se
mencione blockchain se dará por sentado que se refiere al caso publico.
Blockchain tiene la estructura de una lista enlazada donde los datos (e.g.
transacciones) son agrupados y guardados en bloques. Esto bloques luego son
añadidos a la lista uno tras otro. Cada bloque lleva una referencia al bloque
inmediatamente anterior por medio de su hash criptográfico lo cual le permite
a cualquier nodo en la red corroborar la validez de la cadena. Cualquier intento
de alterar el orden de los bloques será detectado. Uno de los propósitos de
blockchain es no depender de una autoridad central. En consecuencia, para que
un nodo de la red logre añadir un nuevo bloque a la cadena debe cumplir con
ciertos requisitos que pueden ser validados por los otros nodos. Una vez otros
nodos aprueben el nuevo bloque y esto ocurra con todos los nodos de la red el
bloque es añadido [14]. Al conjunto de condiciones y el proceso de validación
para añadir nuevos bloques se le conoce como el algoritmo de consenso.
2.3 Algoritmos de consenso y prueba de esfuerzo
El algoritmo de consenso es lo que le permite a los blockchain públicos operar sin
necesidad de una autoridad central. En 2008 se publicó el white paper de Bitcoin
por un autor bajo del seudónimo de Satoshi Nakamoto (hasta el momento aun
se desconoce de la identidad verdadera del autor) [20]. Aunque para la época
ya hab́ıan estudios sobre algoritmos de consenso y sus aplicaciones, lo que hizo
de este trabajo una propuesta innovadora fue el uso de prueba de esfuerzo, o
PoW por sus siglas en inglés, como algoritmo de consenso. Originalmente PoW
fue propuesto en 1993 como un medio para combatir los correos no deseados.
Este consist́ıa en solicitarle al remitente de los correos resolver un rompecabezas
criptográfico que le diera cierta validez al correo para que fuera admitido por el
destinatario [22]. Más en detalle, el remitente deb́ıa calcular el hash para una
cadena de caracteres compuesta del encabezado del correo, la fecha de env́ıo y
un número aleatorio llamado nonce. El remitente deb́ıa variar el nonce hasta
que se encontrara un hash con un cierto número de ceros al principio [14]. En
consecuencia, se deb́ıan probar todas las posibles combinaciones de nonce hasta
hallar aquella que generara el hash deseado.
A partir de esto, se propuso un algoritmo de consenso basado en PoW con
algunas variaciones. La primera diferencia fue que en vez de usar SHA-1 como
función de hashing se deb́ıan realizar dos operaciones de SHA-2 consecutivas.
La segunda fue que en la cadena de caracteres sobre la cual se calculaba el hash
se remplazó el encabezado del correo por el encabezado de los bloques. Por
ultimo, la dificultad o número de 0’s deseado al principio de cada hash pasó de
ser una constate a un parámetro variable que se recalculaba cada 2016 bloques
6
con el fin de conservar una tasa constante a la cual se añad́ıan nuevos bloques
[14]. Idealmente, se deb́ıa de añadir un nuevo bloque cada 10 minutos. En
consecuencia, los nodos en la red que quisieran añadir un nuevo bloque deb́ıan
de resolver este rompecabezas criptográfico lo cual se conoce popularmente como
como minar; los nodos que minan se les conoce como mineros. Con el fin de
incentivar la mineŕıa, el algoritmo de consenso define cierta recompensa que le es
pagada al minero que logre añadir un nuevo bloque. Esta recompensa es incluida
al principio del bloque por añadir en forma de una transacción sin remitente y
con destinatario único al minero. Además, en algunos casos, las transacciones
pueden incentivar a los mineros para que las incluyan en el bloque que intentan
añadir por medio de comisiones. Todas las criptomonedas que utilizan algún
algoritmo de consenso basado en prueba de esfuerzo se les puede minar.
Uno de los parámetros que hace parte del encabezado de un nuevo bloque es
el hash del bloque anterior (el ultimo bloque de la cadena aceptado) es por
esta razón que cualquier intento de modificar la cadena es detectado. Aśı
mismo, también es la razón por la cual cuando un minero logra añadir un
nuevo bloque antes que otros mineros estos últimos deben de iniciar desde cero
el rompecabezas, ya que el hash que deben incluir en su encabezado cambió. Sin
embargo, debido a que las actualizaciones en la red no se propagan de forma in-
mediata pueden llegar a presentarse inconsistencias. Una de ellas ocurre cuando
dos o más mineros logran generar nuevos bloques en simultáneo y la red se divide
entre los nodos que aceptan uno u otro de estos nuevos bloques como último de la
cadena. Para solucionar esta inconsistencia temporal en la red, los nodos deben
guardar ambas ramificaciones, o forks, generadas hasta que una de las ramas sea
mucho más larga que la otra. Se conserva la cadena más larga porque en esta
se invirtió un mayor poder computacional. Esta estrategia permite solucionar
tanto la situación donde varios nodos honestos generan bloques en simultaneo
como cuando un nodo deshonesto intenta añadir un bloque corrupto a la red
como se vera mas adelante [22, 16].
2.4 Unidades de procesamiento gráfico (GPU)
Las unidades de procesamiento gráfico o GPU en un principio se consideraban
como hardware especializado en la labor de renderizado de imágenes 3D [24].
Sin embargo, con el tiempo su uso se extendió a otras áreas ya que era posible
programar en ellas. Es importante conocer la diferencia entre una GPU dedicada
y una GPU integrada. Las iGPU o GPUs integradas se caracterizan por estar
incluidas dentro del empaquetado de las CPU. Su capacidad es limitada, sin
embargo su consumo de potencia es bajo. Por lo tanto, son componentes de
hardware atractivos cuando las tareas de procesamiento gráfico realizadas son
de baja intensidad. Por otro lado, las GPUs dedicadas o discretas suelen tener
su propio circuito impreso, sistema de refrigeración y se conectan por medio de
un puerto PCI-E. Estas últimas son usadas para tareas mucho más exigentes y
sus capacidades no se limitan únicamente a tareas de renderizado ya que suelen
ser programables. De aqúı en adelante cuando se hable de GPUs nos referiremos
a las dedicadas [24].
7
A diferencia de las unidades centrales de procesamiento (CPU), que se iden-
tifican por tener un alto rendimiento por núcleo y una baja latencia, las GPU
se caracterizan por su throuhgput ya que son capaces llevar a cabo la ejecución
de múltiples tareas en simultáneo[12].Esto se debe a que las GPU poseen un
gran numero de núcleos simples, ideales para paralelizar tareas. Actualmente,
las GPU son usadas no solamente para tareas de renderizado pero también para
aprendizaje profundo y minado de criptomonedas [23].
2.5 Centralización de la red
Una de las bases sobre las cuales opera blockchain es que es una red descentral-
izada. Esto implica, en primer lugar, que el registro/secuencia de bloques sea
de libre acceso para los nodos en la red, lo que permite a los nodos validar y
verificar la consistencia de la cadena. En segundo lugar, implica que los nodos
realizan sus actividades de forma independiente entre ellos y que en ningún mo-
mento un mismo individuo o grupo de individuos logra controlar la mayoŕıa del
poder computacional de la red [28].
En el documento original de Bitcoin se asume que pueden existir nodos
maliciosos en la red, sin embargo se menciona que mientras que los nodos
honestos posean mas del 50% del poder computacional la red no podrá ser
engañada. Cuando algún nodo malicioso intente insertar un bloque corrupto
a la red sucederán las siguientes situaciones. En primer lugar, los nodos hon-
estos van a rechazar el nuevo bloque cuando se den cuenta de la inconsistencia
presente en el bloque y trabajaran en generar otra(s) ramificación(es). En se-
gundo lugar, debido a que el atacante no posee mas del 50% del poder computa-
cional sus probabilidades de añadir un nuevo bloque sobre el corrupto que acaba
de generar decaerán exponencialmente [28]. Por último, debido a que los no-
dos honestos en conjunto son capaces de generar ramificaciones mas largas que
aquella que posee el bloque corrupto esta última sera descartada [28]. El caso
antes descrito muestra la razón por la que Bitcoin es resiliente a ataques. Sin
embargo, depende del supuesto de que los atacantes no controlan más de 50%
del poder computacional de red. Como se verá a continuación, este supuesto
debe ser tomado con cautela debido a la centralización del poder computacional
ocasionada por hardware especializada y prácticas realizadas por conjuntos de
mineros.
2.5.1 ASIC y FPGA
Con el tiempo se desarrollaron componentes de hardware aún más eficientes que
las GPU para el minado de criptomonedas. Los primeros fueron las FPGA o
matriz de puertas lógicas programable en campo. Estos dispositivos son pro-
gramables y eran capaces de minar Bitcoin, sin embargo no eran mucho más
veloces que las GPU a la hora de minar. Su ventaja se centraba en que teńıan
un consumo energético menor [8]. Sin embargo, son equipos que requieren de
cierto conocimiento técnico para lograr operar y programar.
8
En segundo lugar, aparecieron las ASIC o circuitos integrados de aplicación
espećıfica. A diferencia de las FPGA, las ASIC son componentes de hardware
especializado en minado que se crearon con este único objetivo. En contraste
con los procesadores de uso general y las FPGA los componentes de hardware
especializado son mucho más veloces en la ejecución de instrucciones y su con-
sumo energético es inferior por instrucción. Por ello, poseen una capacidad de
minado superior a un menor costo energético. Sin embargo, son máquinas de
una complejidad superior, lo que las hace más dif́ıciles de operar y construir.
Además, debido a que son de uso especifico, la mayoŕıa de personas no poseen
estas máquinas porque sirven únicamente para minar y su precio las hace poco
asequibles para el usuario común. Esto hizo que la capacidad de minado se
concentrara en aquellos individuos con los recursos económicos y capacidades
técnicas para minar con estas máquinas, lo cual ha puesto en riesgo la decen-
tralización de la red [14, 20].
2.5.2 Fondos de mineŕıa
Una segunda razón por la que se ha puesto en riesgo la decentralización de la
red ha sido la aparición de fondos de mineŕıa. La razón de su aparición fue
que con el tiempo la dificultad para hallar nuevos bloques aumentá a tal punto
que los mineros que no poséıan granjas de mineŕıa (gran conjunto de maquinas
enfocadas a realizar esta actividad) teńıan muy bajas probabilidades de lograrlo.
Debido a esto, los mineros, en un intento por aumentar sus probabilidades de
ganar el rompecabezas criptográfico, decidieron unirse para aumentar su poder
computacional de forma conjunta, a esto se le conoce como un fondo (pool).
En un fondo existen los mineros que poseen un cierto poder computacional
y el coordinador que se encarga de coordinarlos y repartir las ganancias. En
principio, todos los mineros operan en pro del fondo y a este se le reconoce
la recompensa por la operación de alguno de sus mineros [14]. Finalmente,
estas ganancias se distribuyen a los mineros en base al poder computacional
que aportaron al fondo para la resolución de los problemas y se les descuenta
una pequeña comisión de cerca del 1%-3% para pagar al coordinador [15].
La forma como los fondos operan es la siguiente. Los coordinadores le
reparten a los mineros un borrador del bloque que se intenta añadir a la ca-
dena y les piden que encuentren una solución al bloque que este por debajo
de cierta dificultad. Esta dificultad usualmente es inferior a la dificultad de la
red para que los mineros puedan subir soluciones parciales más rápidamente.
Una vez el minero sube una solución parcial válida se le reconoce el esfuerzo
invertido asignándole una acción válida (share), si la solución no lo es se le
asigna una acción inválida. Una vez el fondo logre añadir un bloque a la red
este reparte las ganancias en base a las acciones válidas que posea cada minero
e inicia una nueva ronda de minado donde todos los mineros inician sin acciones
válidas. Ahora, existen varios esquemas para repartir las ganancias en base a
las acciones válidas [29]. El primero de ellos es el esquema proporcional, este es
el más simple y consiste en asignarle a cada minero una ganancia proporcional
al porcentaje de acciones válidas que ganó durante la ronda de minado. El se-
9
gundo esquema se llama PPS (Pay per share), en este caso se calcula el número
estimado de acciones válidas que se esperan repartir para cuando se termine la
ronda de minado (se añada un bloque) y en base a eso se paga a los mineros
[2]. Este último esquema es riesgoso para el fondo ya que una variación en los
tiempos esperados puede hacer que el fondo le termine pagando a los mineros
una recompensa mayor a la obtenida una vez se acabo la ronda. Finalmente, el
tercer esquema, el cual es utilizado por Bitfly [15], se llama PPLNS (Pay Per
Last N Shares). Este esquema es semejante al proporcional pero, a diferencia de
este, el pago no se hace en base a todas las acciones válidas repartidas durante
la ronda de minado sino solamente sobre las asignadas en el último tramo, la
longitud del tramo es definido por el fondo (en el caso de Bitfly es la ultima
hora de la ronda [15]). Este último esquema busca privilegiar a los mineros que
participan en el fondo de forma continua, ya que bajo el esquema proporcional
suele ocurrir que grandes mineros durante una misma ronda de minado se pasan
entre diferentes fondos para recibir múltiples recompensas.
Los fondos de mineŕıa benefician especialmente a los mineros que poseen
un bajo poder computacional sin embargo su presencia pone en riesgo a la
decentralización porque concentra el poder de múltiples máquinas bajo el control
de una única entidad. Si el coordinador quisiese engañar a la red tendŕıa a su
disposición el poder computacional del fondo entero para intentar hacerlo [14] y
seŕıa capaz de generar forks más largos. Aunque esta práctica claramente pone
en riesgo la decentralización, hoy en d́ıa es muy poco usual que los pequeños
mineros logren generar ganancias si no participan en un fondo debido a que los
niveles de dificultad a los que se ha llegado en las diferentes plataformas es muy
alto.
2.6 Algoritmos basados en prueba de esfuerzo duros en
memoria
Con el objetivo de contra-restar el dominio de las ASIC, nuevas criptomonedas,posteriores a Bitcoin, han propuesto protocolos de consenso basados en prueba
de esfuerzo que poseen algunas alteraciones que permiten atacar esta prob-
lemática. A estos algoritmos se les conoce como basados en prueba de esfuerzo
duros en memoria. A ellos se les caracteriza porque deben realizar accesos a
memoria de forma regular. Estos algoritmos requieren tener cargado en memo-
ria un bloque de datos, llamado scratchpad, que se genera aleatoriamente a
partir de un nonce [22]. Sobre este scratchpad se realizan las operaciones de
lectura y/o escritura de forma aleatoria durante el proceso de minado. Estos
accesos aleatorios a memoria reducen la utilización del cache y hacen que las
operaciones de minado se vean limitadas en latencia, ancho de banda y tamaño
de la memoria. En el caso especifico de las FPGA y ASIC estos poseen una
ventaja a la hora de minar criptomonedas cuando estas poseen algoritmos de
consenso basados únicamente en prueba de esfuerzo por su velocidad a la hora
de ejecutar instrucciones. Sin embargo, pierden esta ventaja cuando la limitante
pasa a ser el acceso a la memoria [22].
Algunos de los algoritmos que pertenecen a esta familia de protocolos de con-
10
senso son: Ethash (Ether), CryptoNight (CryoptoNote), Cockoo Cycle, Scrypt,
etc [20, 22]. Claramente, estos algoritmos pueden ser diferentes entre ellos, sin
embargo todos se caracterizan porque imponen limitantes sobre el acceso a la
memoria y/o su capacidad. Por ejemplo, Ethash, en su versión original (actual-
mente Ethereum está migrando a un algoritmo de consenso basado en prueba
de participación [19]), no solamente teńıa un ciclo intensivo de lecturas aleato-
rias sobre el scratchpad este también ocupaba cerca de 1GB (actualmente el
scratchpad ocupa más de 4GB [27]). Es importante recalcar, que aunque estas
limitantes buscan impedir el dominio de las ASIC sobre las plataformas, el crec-
imiento del scratchpad, como ocurre con Ethereum, también es una limitante
para procesadores de uso general, especialmente las GPUs, ya que a estos com-
ponentes de hardware poseen una memoria propia de tamaño fijo. Esto será
de importancia al momento de analizar el hardware disponible para realizar las
pruebas en la universidad.
2.7 Protocolos de consenso basados en prueba de X
El protocolo de consenso sugerido por Bitcoin fue el primero en permitir que
una criptomoneda fuera admitida como medio de pago de forma global. Sin
embargo, este y los protocolo de consenso basados en prueba de esfuerzo tienen
otros inconvenientes, uno de los cuales es el alto consumo energético [19]. Por
esta razón, se han propuesto otros protocolos para llegar al consenso a los cuales
se les ha denominado como ”prueba de X” (proof-of-X) o PoX [14]. Al interior
de esta familia de protocolos para llegar el consenso hay multiples variaciones
pero todas intentan atacar las debilidades energéticas que presenta PoW.
El primer conjunto de protocolos de la familia PoX son aquellos que op-
eran en base a una prueba de participación (Proof of stake o PoS). Este grupo
de protocolos de consenso se caracteriza porque los participantes realizan una
votación para decidir qué nuevo bloque es añadido a la cadena. El voto de un
nodo es ponderado con respecto a su participación en la red, lo cual se puede
medir en términos del número de monedas que posea. Para definir cuál bloque
es añadido a la red se elige entre todos los participantes a un ĺıder aleatorio y
él es quién lo decide [14].
El segundo conjunto de protocolos se le conoce como prueba de capacidad
(Proof of Capacity) o PoC. En PoC los participantes votan por nuevos bloques
de forma similar a PoS sin embargo no lo hacen en forma proporcional a su
participación de la red sino en términos de su capacidad para alojar información
no trivial en sus dispositivos de almacenamiento. Para elegir al ĺıder quien decide
cual es el bloque sobre el que se debe votar se deben almacenar segmentos de
archivos de tamaños grandes [14].
Existen otros conjuntos de protocolos como prueba de tiempo (PoT) o in-
cluso esquemas h́ıbridos. Sin embargo, todos buscan realizar la misma cosa:
remplazar los algoritmos de consenso basados en PoW por otras alternativas
que tengan menores requisitos sobre el poder computacional y permitan llegar
al consenso. Esto con el objetivo de reducir el consumo de enerǵıa asociado
regularmente al minado de criptomonedas [14].
11
3 Alternativas
A lo largo del desarrollo del proyecto se analizaron diferentes escenarios para
realizar las pruebas de minado. En un principio, se pensó en usar la infraestruc-
tura de las salas Turing y Waira para realizar las pruebas. Sin embargo, debido a
ciertas limitantes, fue necesario realizar algunas modificaciones. A continuación,
se relatan las decisiones de diseño que se tomaron a lo largo del desarrollo para
escoger el escenario de pruebas final.
3.0.1 Compatibilidad del software de mineŕıa con anti-virus
Durante el desarrollo del proyecto se pensó inicialmente en la posibilidad de usar
las máquinas de las salas de cómputo Waira o Turing para realizar las pruebas
de minado. En la tabla 1 se pueden ver las especificaciones de los computadores
en estas salas.
Waira Turing
Procesador Intel (R) Core (TM) i7-7700
CPU @ 3.60Hz [ 8 core(s)
x64]
TM) i7-7700 CPU
@4.20GHz [ 8 core(s)
x64]
Memoria 32 GB DDR4 @1.20 GHz 64 GB DDR4 @1.20 GHz
Almacenamiento HDD 1TB HDD 1TB
Tarjeta de v́ıdeo Intel (R) HD Graphics 630
(iGPU)
Nvidia Quadro P600
Tarjeta de red Intel(R) (2) I219-LM Giga-
bit Network Connection 1
Gb/s
Intel(R) (2) I219-LM Giga-
bit Network Connection 1
Gb/s
Sistema Opera-
tivo
Microsoft Windows 10 En-
terprise
Microsoft Windows 10 En-
terprise
Table 1: Especificaciones computadores salas Waira y Turing
El primer inconveniente con el que nos encontramos fue que los programas
usados para minar criptomonedas suelen ser señalados como programas peli-
grosos por los antivirus de Windows [21]. La razón por la que esto ocurre es
que los ciber-delincuentes suelen instalar software malicioso con el fin de ro-
bar el poder computacional de usuarios, sin que ellos se percaten, para minar
criptomonedas; a esta práctica se le conoce como Cryptojacking [26]. Aunque
ciertos antivirus han construido gúıas para distinguir aquellos programas de
minado de aquellos que realizan Cryptojacking [13], por seguridad continúan
marcando los programas como peligrosos para solicitar autorización expĺıcita
de los usuarios que desean correrlos. Por otro lado, algunos antivirus justi-
fican bloquear por defecto cualquier programa de minado justificando que la
mayoŕıa son programas de código abierto, lo que implica que ningún individuo
o entidad es responsable su uso y mantenimiento. Esto los hace potencialmente
peligrosos ya que aunque no realicen Cryptojacking ahora, en un futuro puede
12
que śı [26]. A causa de esto se descartó la posibilidad de usar los equipos de
la universidad de forma directa. Por seguridad se optó por tomar un equipo y
montarle una imagen de Ubuntu 20.04, ya que la mayoŕıa de software de mineŕıa
posee implementaciones exclusivamente para Linux. La única excepción a esto
era NiceHash, sin embargo se pensó en probarlo usando una máquina virtual y
realizarle GPU passthrough [12].
3.0.2 Mineŕıa con CPU
El segundo inconveniente con el que nos encontramos fue que, actualmente, para
la mayoŕıa de criptomonedas no es rentable minarlas con CPU. El desempeño
de un componente de hardware para minado se mide en términos del número
de hashes que puede realizar por segundo, generalmente medido en kilo hashes
(kH/s) o mega hashes (MH/s) por segundo, y su consumo de potencia. Además,
la rentabilidad también depende de forma inversamente proporcional a la ca-
pacidad de minado de la red entera para la criptomoneda en cuestión. Aunque
la CPU es la unidad de procesamiento más versátil y popular, su capacidad
para distribuir tareas usando paralelismo es limitada. Por el contrario, las GPU
tienen una capacidadmucho mayor de paralelizar tareas, lo que les permite
tener una tasa de cálculo de hashes por segundo mucho más alta [20] con un
consumo de potencia similar.
Debido a que los usuarios que minan criptomonedas con algoritmos de con-
senso duros en memoria lo hacen generalmente con GPU, la capacidad com-
putacional de la red ha crecido al punto donde no es rentable minar con CPU.
Ciertamente, existen CPU modernas con números de núcleos que rondan en los
32, 64 e incluso 128 que podŕıan llegar a ser un poco rentables, sin embargo,
estos equipos son usados por centros de datos y servidores por lo que no repre-
sentan el tipo de equipos que posee la universidad. A esto se le suma el hecho
de que no hay implementaciones de software recientes para minado con CPU.
Debido a esto, se descartó usar los equipos de la sala Waira ya que estos no
poseen GPU dedicada.
3.0.3 Tamaño de scratchpad
El tercer inconveniente con el que nos encontramos fue descubrir que la mayoŕıa
de las criptomonedas con protocolos de consenso basadas en algoritmos de
prueba de esfuerzo duros en memoria tienen scratchpads que superan los 2GB
de memoria, algunos incluso superan los 4GB. A causa de esto, las GPUs
disponibles en la sala Turing no eran capaces de llevar a cabo las operaciones de
minado ya que las Nvidia Quadro P600 solo poseen 2GB de memoria dedicada.
Sin embargo, al revisar el inventario de las máquinas disponibles se hallaron
tarjetas gráficas Nvidia Qaudro K2200 las cuales eran algunas generaciones
pasadas que las P600 pero nos permit́ıan realizar las operaciones de minado
ya que poseen 4GB de memoria dedicada. En la tabla 2 se puede detallar el
tamaño de memoria para algunas criptomonedas.
13
Criptomonedas/Plataformas bios flashbackTamaño Scratchpad (GB)
Ethereum 4.55
Ethereum Classic 2.82
Ravencoin 3.11
Ergo 2.10
Table 2: Tamaño de scratchpad para criptomonedas [7]
3.0.4 Virtualización y GPU Passthrough
Finalmente, dado que se buscaba analizar todas las opciones para rentabilizar
los recursos computacionales de la universidad por medio de minado, se investigó
sobre una esquema de renta propuesto por una compañ́ıa llamada NiceHash. A
diferencia del t́ıpico software de minado de criptomonedas, NiceHash es una
plataforma que ofrece varios programas de minado que en vez de minar para
el usuario de la máquina lo que hacen es rentar su poder computacional. Los
mineros rentan las máquinas donde corren estos programas, los dueños de las
máquinas reciben un pago y NiceHash se lleva una comisión por orquestar el
préstamo. El único inconveniente era que NiceHash es uno de los pocos software
de mineŕıa que corren sobre Windows 10.
Para solucionar esto se pensó en crear una máquina virtual Windows 10
sobre la máquina de pruebas que corŕıa Ubuntu 20.04. Sin embargo, para lo-
grarlo, se deb́ıa de realizar una operación llamada GPU passthrough sobre el
sistema operativo anfitrión (Ubuntu 20.04) para cederle el control de la GPU
al sistema operativo invitado (Windows 10). Para lograr esto, se llevo a cabó
el procedimiento sugerido por [3]. Si se desea consultar en más detalle qué her-
ramientas y tecnoloǵıas se requieren para lograr esto, se puede consultar a [12]
donde se realiza un análisis más detallado. Una vez se logró realizar el paso de
la GPU a Windows 10, se instalaron los componentes de software requeridos.
Lamentablemente, al momento de correr NiceHash Miner o QuickMiner (pro-
gramas de minado sugeridos por NiceHash) estos no reconocieron la presencia
de la GPU. Las causas de esto fueron que QuickMiner y NiceHash Miner re-
queŕıan que la GPU soportara CUDA 5.2 (plataforma de computación paralela
soportada por GPUs Nvidia) y tuviera 6 GB de memoria dedicada respectiva-
mente [6]. La GPU Nvidia Quadro K2200 solo soporta hasta CUDA 5.0 y solo
posee 4GB de memoria dedicada en consecuencia no fue posible minar usando
este esquema.
4 Propuesta
Una vez fueron identificados los requisitos del equipo para llevar a cabo las la-
bores de mineŕıa se construyó un conjunto de pruebas y se definieron algunos es-
cenarios para realizarlas. Inicialmente se queŕıa minar cerca de 8 criptomonedas
14
pero debido a algunas limitantes, como el tamaño del scratchpad, no fue posible
y se eligieron solo 4. Solo en el caso de una de las criptomonedas que se eligieron
fue posible correr el software de minado aun cuando el scratchpad no cab́ıa en
memoria, sin embargo esto fue a costa de una reducción significativa de poder
de cómputo.
4.1 Arquitectura y contexto
La arquitectura del computador elegida para realizar las operaciones de minado
fue el siguiente:
Sistema Operativo Ubuntu 20.04.3 LTS
CPU Intel Core i7-4790 3.60GHz 4 Núcleos/8 Hilos
iGPU Intel HD Graphics 4600
GPU Nvidia Quadro K2200 4 GB GDDR5
Almacenamiento 500.1 GB HDD
Memoria 32 GB DDR3 1600 MT/s (8GB x 4)
Tarjeta madre Dell 04BDY8-A00
Table 3: Arquitectura elegida para minado
Por otro lado, los software de mineŕıa elegidos para realizar las pruebas
fueron LolMiner [10], TRexMiner [11] y GMiner [9]. Estos se escogieron después
de realizar varias consultas a foros especializados en el tema donde los recomend-
aban por ofrecer una alta estabilidad, confianza de los usuarios y seguridad. Aśı
mismo, se eligieron las 4 criptomonedas sobre las cuales se realizaŕıan pruebas
de minado: Ether, Ethereum Classic, Ravencoin y Ergo. Estas 4 platafor-
mas/monedas se escogieron con base en que son relativamente populares, el
software de mineŕıa encontrado era capaz de minarlas y los recursos computa-
cionales a disposición también. Finalmente, por suerte, se encontró un conjunto
de fondos de mineŕıa para estas 4 criptomonedas que operaban bajo la misma
empresa, Bitfly [4]. Los nombres para cada uno de estos fondos eran: Ethermine,
Ethermine ETC, Flypool Ravencoin y Flypool Ergo, respectivamente. Se esco-
gieron estos fondos por dos razones. En primer lugar, todos ellos poséıan una
API gratuita que le permitió al monitor de recursos realizar llamados regular-
mente para conocer el hashrate del minero detectado por el fondo. La segunda
razón fue que estos fondos son unos de los más grandes del mundo y a causa de
esto tienen estad́ısticas de suerte que rondan alrededor del 100%. Lo que esto
quiere decir es que a causa de que el fondo es muy grande, el tiempo que le toma
añadir un nuevo bloque a la cadena suele estar alrededor del tiempo esperado,
cosa que para fondos pequeños o mineros solitarios no ocurre ya que hay una
variación mucho más alta en los tiempos de éxito.
15
4.2 Monitor de recursos computacionales y desempeño
Durante el minado de criptomonedas se queŕıa analizar el consumo de recursos
de la máquina. De antemano se sab́ıa que el componente que iba a experimentar
una mayor carga era la GPU, sin embargo, se queŕıa conocer si podŕıan llegar
a existir otros cuellos de botella para la operación. Por tal razón, se tuvieron
algunas consideraciones para simular el comportamiento que se tendŕıa al minar
en un equipo de una sala de la universidad. Durante todas las mediciones el
chasis estuvo cerrado y la pantalla conectada a la GPU integrada de la CPU
para evitar que se consumieran recursos computacionales de la GPU dedicada.
También se evitó al máximo correr programas distintos al de minado y al del
monitor de métricas de minado en el computador mientras que se llevaron a
cabo las pruebas. Ambos programas se corrieron directamente desde la consola.
El programa de monitoreo se escribió en Python 3.7 y se uso la libreŕıa pandas.
Las métricas se tomaron cada 10 segundos (limitante impuesta por la API de
Ethermine [4]) y cada 100 muestras, un equivalente a 17 minutos, las métricas
se guardaban en disco usando un hilo de ejecución secundario para evitar la
sobrecarga de la CPU y un consumo innecesario de memoria del dispositivo.
El monitor en cada toma revisaba las siguientes métricas: consumo de memo-
ria, consumo de memoria dedicada de la GPU, porcentaje de utilización de la
CPU, porcentajede utilización de la GPU, temperatura del empaquetado de
la CPU, temperatura de la GPU, hashrate reportado por la API del fondo de
mineŕıa utilizado y frecuencia de la CPU. Aśı mismo se tomaron datos sobre el
consumo usando un conector inteligente Emporia [18], las especificaciones sobre
este producto se pueden ver en la tabla 4.
Consumo de potencia 1W
Potencia máxima 1800W @ 120V
Máxima carga constante 10A
Tiempo entre mediciones 1 seg
Precisión 1 W
Table 4: Especificaciones de Conector Inteligente Emporia. Tomado de [17]
4.3 Resultados
A partir de estas especificaciones fue posible realizar las pruebas de minado y
se obtuvieron los siguientes resultados.
A primera vista, y tal como se esperaba, el recurso más utilizado es la GPU.
En definitiva los programas de minado, independiente del algoritmo o crip-
tomoneda que estén minando, utilizan al máximo este componente. Esto se
puede evidenciar en las figuras 4a y 5b donde para las 4 sesiones de minado se
usa el 100% de la GPU y una parte importante de la memoria dedicada, entre
el 50% y 100% de ella. A causa de esto la GPU llega a tener temperaturas
relativamente altas, alcanzando en el peor caso, Ravencoin, cerca de 80 gra-
16
(a) Carga sobre la CPU (b) Temperatura de la CPU
Figure 3: Desempeño de la CPU durante minado
(a) Carga sobre la GPU (b) Temperatura de la GPU
Figure 4: Desempeño de la GPU durante minado
dos cent́ıgrados. Además, si se comparan las figuras 4b y 3b el ascenso de la
temperatura de la GPU tiene un efecto sobre la temperatura de la CPU, aun
cuando la utilización de esta no aumentaba, llegando a elevarla entre 10 y 15
grados cent́ıgrados. Ciertamente, el recurso menos utilizado por las operaciones
de minado es la CPU que no llega tener una utilización regular mayor del 1%
y algunos picos esporádicos apenas llegan al 5%. De las pruebas realizadas la
única criptomoneda que parece estar utilizando ligeramente el poder computa-
cional de la CPU es Ethereum. Por el contrario, la memoria del computador
aunque no es utilizada por completo śı parece ser necesaria para realizar las
operaciones de minado, como se puede ver en la figura 5a donde siempre que se
empieza a minar se presenta un ligero incremento sobre el consumo en los cuatro
escenarios. Por otro lado, los datos sobre consumo de potencia se muestran en
la imagen 6
A diferencia de las otras métricas con las que solo se buscaba identificar la
utilización de recursos durante el minado, la potencia es un factor de mayor
17
(a) Consumo de memoria
(b) Consumo de memoria dedicada de la
GPU
Figure 5: Consumo de memoria durante minado
Figure 6: Consumo de potencia
importancia ya que afecta de forma directa la rentabilidad sobre el minado de
criptomonedas. Ciertamente, los resultados que se muestran en la figura 6 nos
llevan a concluir que el consumo parece ser bastante similar entre las diferentes
criptomonedas. A excepción de Ergo donde la gráfica muestra fluctuaciones im-
portantes durante el consumo, las operaciones de minado con esta GPU parecen
18
consumir entre 32 y 55 vatios adicionales. Con el fin de tener un análisis mas de-
tallado se realizaron los siguientes cálculos sobre el consumo de potencia durante
el minado para las diferentes criptomonedas (tabla 5).
Promedio Desv.
Estándar
Mediana
Ethereum 80.57W 2.88W 80.4W
Ethereum
Classic
73.18W 1.14W 73.8W
Ravencoin 87.71W 1.09W 87.9
Ergo 76.69W 7.25W 73.6W
Table 5: Datos sobre consumo de potencia durante minado
Como era de esperarse la criptomoneda que tuvo un consumo más irregular
fue Ergo aśı como la que tuvo un rango de consumo más amplio. Sin embargo, al
comparar la mediana con el promedio podemos ver que solo hay una diferencia de
menos de 3W entre ambas. En consecuencia el promedio es un buen estimativo
para el consumo de potencia de la GPU para esta moneda. Por otro lado, el
resto de criptomonedas parecen tener comportamientos mucho más estables,
siendo Ravencoin la moneda de mayor consumo durante minado con un valor
promedio de 87.71W.
Finalmente, la última variable que se monitoreó durante el minado fue el
hashrate alcanzado por la GPU. A diferencia de las otras métricas, esta hab́ıa
que analizarla con un poco más de detalle. Generalmente, los programas de
mineŕıa reportan el hashrate alcanzado por los componentes de hardware, sin
embargo, este valor puede ser diferente al hashrate percibido por el fondo de
mineŕıa. El hashrate percibido por el fondo se calcula en base al número de
acciones válidas recibidas por un minero y la dificultad solicitada por el fondo
durante una fracción de tiempo. Si se minara un tiempo suficiente, el hashrate
percibido por el fondo y el reportado por el programa se debeŕıan igualar [1].
Sin embargo, para realizar un análisis más detallado, por medio de la API
de los fondos de Bitify, se monitoreó el hashrate percibido además del hashrate
reportado. A continuación en las imágenes 7 y 8 se pueden revisar los resultados
de estas métricas.
A primera vista, el hallazgo más importante sobre el hashrate fue que teńıa
un valor de 0 al minar Ether (tanto el reportado por el programa como el de-
tectado por el fondo). Técnicamente, la GPU utilizada no debeŕıa de poder
minar esta criptomoneda ya que el tamaño del scratchpad (tabla 2) supera el
tamaño de la memoria dedicada. Sin embargo, en LolMiner 1.21 fue habilitado
un modo de minado conocido como ”modo zombie”. El modo zombie le permite
minar Ether a GPUs con memorias dedicadas de menor tamaño al scratchpad
a costa de una reducción en el hashrate. La forma de operar de este ”modo
zombie” simplemente consiste en repartir el scratchpad entre la memoria dedi-
cada y la memoria RAM del computador. Esto implica que debe de haber una
comunicación constante a través del canal PCI-E por el cual está conectada la
19
(a) Hashrate Ethereum (b) Hashrate Ethereum Classic
Figure 7: Hashrate sesiones de minado 1
(a) Hashrate Ravencoin (b) Hashrate Ergo
Figure 8: Hashrate sesiones de minado 2
GPU y la latencia generada por esta comunicación es la razón de que se reduzca
el hashrate [5]. Esto explica por qué el uso de la CPU y el incremento en la
utilización de la memoria fue mayor al minar Ethereum. Lamentablemente para
el caso de la Nvidia Quadro K2200 el poder computacional es tan reducido que,
aunque que se logre correr el programa, el hashrate alcanzado es prácticamente
nulo.
Respecto a las otras criptomonedas, fue evidente cuan distintos pod́ıan lle-
gar a ser el hashrate reportado por el programa con respecto al detectado por
el fondo. Estas discrepancias ocurren justamente porque el minero no siempre
encuentra las soluciones a la dificultad indicada por el fondo en el tiempo esper-
ado. En caso de que se tarde más en encontrar las soluciones, recibirá menos
acciones válidas y en consecuencia el hashrate reportado será inferior. Por otro
lado, si tiene suerte y se tarda menos en encontrar las soluciones, recibirá más
acciones válidas y en consecuencia reportará un hashrate superior al que indica
el programa de mineŕıa. A partir de los datos obtenidos se sacaron las siguientes
20
estad́ısticas para cada criptomoneda acerca del hashrate reportado por el fondo
y el reportado por el programa de mineŕıa.
Promedio
Minero
(MH/s)
Desv.
Estándar
Minero
(MH/s)
Promedio
Fondo
(MH/s)
Desv.
Estándar
Fondo
(MH/s)
Ethereum N/A N/A N/A N/A
Ethereum
Classic
1.3700 0 2.3868 0.7098
Ravencoin 1.2500 0 1.0055 0.5136
Ergo 3.2000 0 2.5024 0.8008
Table 6: Estad́ısticas para Hashrates reportados
Debido a las diferencias entre ambas mediciones el cálculo de rentabilidad
se hará para ambas. Sin embargo, se reitera que para sesiones de minado su-
ficientemente largas, el promedio de ambas métricas se debeŕıa igualar, razón
por la cual seŕıa de más valor el análisis hecho con el hashrate reportado por el
minero. Ahora, si las sesiones de minado no pueden ser tan largas, el análisis
hecho con el hashrate reportado por algunas horas es un buen estimativo.4.4 Consumo regular de recursos y ajuste de resultados
Aunque los datos sobre el consumo de potencia durante el minado permiten
sacar un estimativo de la rentabilidad, es importante tener ciertas considera-
ciones. La universidad, a diferencia de un individuo que desea empezar a minar
desde cero, ya posee estos equipos y, además, ellos consumen potencia regular-
mente tanto cuando hay una persona utilizándolos como cuando no. Es por ello
que la universidad no necesariamente tiene que justificar el costo de los equipos
y de su consumo en base a la rentabilidad del minado ya que son utilizados
principalmente para realizar otras labores. A causa de esto, se debe realizar un
ajuste al consumo de potencia detectado para descartar del consumo regular
del equipo tanto para el caso cuando se encuentra en reposo como cuando hay
un usuario usándolo. En la universidad, por disposición del departamento, los
equipos cuando están en ”reposo” en realidad solo apagan la salida de v́ıdeo, no
entran en estado suspendido, razón por la cual esa fue la configuración usada
para realizar las mediciones de consumo regular en reposo. Por otro lado, para
recrear una situación de uso regular se utilizó el equipo para realizar tareas de
edición de documentos y se navegó en internet por un periodo de dos horas. Los
resultados se pueden ver en la figura 9.
A partir de esto fue posible calcular el consumo promedio de potencia del
equipo tanto en periodos de reposo como en periodos de uso los cuales se mues-
tran en la tabla 9.
Teniendo esto en cuenta y asumiendo que tanto las variables sobre el con-
sumo en estado estable como durante el minado siguen una distribución nor-
21
Figure 9: Consumo de potencia regular
Promedio Desv.
Estándar
Mediana
Uso 49.10W 8.10W 46.5W
Reposo 38.25W 2.64W 37.7W
Table 7: Datos sobre consumo de potencia durante minado
mal, se calculó la diferencia entre ambos y el consumo real asociado al minado.
También se asumió que el consumo de minado era independiente del consumo
del computador por uso regular o reposo.
4.5 Calculo de rentabilidad
Con base en el ajuste realizado se procedió a realizar el cálculo de rentabilidad.
Este cálculo se hace con base en diferentes tipos de variables. Por un lado, están
las variables externas como el poder computacional neto de la red de minado,
el tiempo medio entre bloques, la recompensa por bloque minado, la comisión
tomada por el fondo de mineŕıa y el precio de la criptomoneda minada. Por
otro lado, las variables especificas sobre el componente de minado son su poder
computacional, el consumo de potencia medio y el precio de la potencia del
lugar de minado. Con base en estas variables se puede calcular la rentabilidad
22
Promedio Desv.
Estándar
Promedio
(Uso)
Desv.
Estándar
(Uso)
Promedio
(Reposo)
Desv.
Estándar
(Reposo)
Ethereum 80.57W 2.88W 31.47W 8.60W 42.32W 3.91W
Ethereum
Classic
73.18W 1.14W 24.08W 8.17W 34.83W 2.88W
Ravencoin 87.71W 1.09W 38.61W 8.17W 49.36W 2.86W
Ergo 76.69W 7.25W 27.59W 10.87W 38.34W 7.72W
Table 8: Datos sobre consumo de potencia durante minado con ajuste
asociada a un periodo h (en horas) de minado de la siguiente forma.
R(h) =
HRm
HRm +HRn
∗ 60
2 ∗ h
TP
∗RB ∗ (1−PF ) ∗PC −h ∗CP ∗CE−CI (1)
HRm ∼ Hashrate mineŕıa (Hash/s)
HRn ∼ Hashrate neto (Hash/s)
TP ∼ Tiempo promedio por bloque (segundos)
RB ∼ Recompensa por bloque (criptomoneda)
PF ∼ Comisión fondo mineŕıa (%)
PC ∼ Precio criptomoneda (USD)
CP ∼ Consumo de potencia (kW)
CE ∼ Costo de enerǵıa (USD/kW)
CI ∼ Costo de inicial (USD)
Generalmente, es importante tener en cuenta el costo inicial porque permite
saber cuál es el tiempo esperado para recuperar la inversión en caso que se
compren los equipos exclusivamente para minar. Sin embargo, para el caso
de la universidad estos equipos se compran con propósitos académicos y no de
minado, en consecuencia este valor se asume como 0. Para realizar los cálculos
se asumieron constantes los siguientes valores en las tablas 9 y 10.
Finalmente, con base en los datos recopilados sobre consumo de potencia y
poder computacional (hashrate) del equipo de pruebas se construyó la tabla 11
de rentabilidad para un periodo de minado de 24 horas.
El análisis de rentabilidad confirmó lo esperado. Solo bajo 4 escenarios de los
18 analizados (3 criptomonedas, 3 formas de consumo de potencia y 2 hashrates
posibles) seŕıa rentable minar criptomonedas para la universidad. Ahora, es
importante tomar esta afirmación con cautela. De los 4 escenarios, 2 de ellos
fueron rentables usando el hashrate medido por el fondo para Ethereum Classic.
Ethereum Classic tuvo un hashrate medido por el fondo mayor al reportado por
el programa, esto implica que a la hora de correr las pruebas tuvo suerte y pudo
generar un número mayor de soluciones al esperado. Por lo tanto, si se llegara
a correr por un tiempo prolongado de minado seguramente habŕıan perdidas
como ocurre para el caso del otro hashrate. Además, los 4 escenarios se dieron
23
Ravencoin Ethereum Clas-
sic
Ergo
Hashrate Neto
(TH/s)
7.8221 25.0739 17.1779
Tiempo prome-
dio por bloque
(seg)
58.1392 13.0745 120.1668
Recompensa
por bloque
5000 3.2 67.5000
Precio crip-
tomoneda
(USD)
0.1092 48.7910 7.0300
Table 9: Variables externas especificas criptomonedas
Comisión fondo mineŕıa 1%
Costo de enerǵıa 0.10973 USD (405.28 COP
∼ 3693.36 TDP 2020)
Table 10: Variables constantes
únicamente cuando se descontó el consumo asociado al uso o reposo de los
equipos. En ningún escenario que se usó el consumo base habŕıa ganancias. Por
ende, con minar en alguno de estos escenarios la universidad no estaŕıa del todo
ganando dinero sino mas bien cubriendo parte del consumo de la potencia que
ya se pierde por tener los equipos prendidos de forma constante. A esto hay que
sumarle el hecho que los 3 escenarios que generan ganancias cuando los equipos
están en uso solo aplicaŕıan bajo la condición de que el usuario usando los
equipos no estuviera utilizando la GPU dedicada y esta fuera utilizada solo para
las operaciones de minado. Aun sin tener en cuenta todas estas consideraciones
las ganancias seŕıan muy bajas. En el mejor caso, por 24 horas de minado solo
se ganaŕıan 3.38 centavos de dólar. En el caso hipotético que se minara por
365 d́ıas de forma continua y las otras variables continuaran constantes, solo se
ganaŕıan poco mas de 12 dólares por equipo. Esta cifra no justifica el minado de
las criptomonedas y todo lo que conlleva: la degradación acelerada del equipo,
aumento en el consumo de potencia, aumento de la temperatura en las salas de
computo, contaminación ambiental por el consumo de potencia, etc.
5 Conclusiones
Para finalizar, los resultados del proyecto mostraron claramente que desde una
perspectiva exclusivamente económica no seŕıa rentable para la universidad usar
sus equipos para minar criptomonedas. En primer lugar, la mayor parte de los
equipos de la salas de cómputo no son viables para el minado de criptomonedas,
24
Criptomoneda Consumo Po-
tencia
Hashrate
(Minero)
Hashrate
(Fondo)
Ravencoin
Base -0.1026 -0.1277
Uso 0.0267 0.0016
Reposo -0.0016 -0.0267
Ethereum
Classic
Base -0.1369 -0.0954
Uso -0.0076 0.0338
Reposo -0.0359 0.0055
Ergo
Base -0.1390 -0.1528
Uso -0.0097 -0.0235
Reposo -0.0380 -0.0518
Table 11: Rentabilidad calculada a 24 horas de minado (USD)
ya sea porque no poseen los componentes necesarios para minar o porque los
componentes no cumplen con los requisitos técnicos. En segundo lugar, los
pocos equipos que llegaŕıan a ser capaces de minar criptomonedas son muy
antiguos y su capacidad computacional es limitada. Además, al momento de
minar criptomonedas, en la mayoŕıa de escenarios, se perdeŕıa más dinero del
que se ganaŕıa debido al consumo energético. Finalmente, en los pocos esce-
narios que śı seŕıa rentable minar, bajo algunos supuestos, las ganancias seŕıan
demasiado bajas como para asumir los costos a largo plazo ocasionados por el
uso constante de los equipos.La única manera en que para la universidad seŕıa
rentable minar criptomonedas, seŕıa si se invirtiera en equipos capaces de llevar
acabo estas labores. Posiblemente se tendŕıan que comprar GPUs de un alto
poder computacional y con suficiente memoria dedicada como para soportar
operaciones de minado a largo plazo.
También hay que tener en cuenta otras perspectivas a la hora de justificar una
compra de equipos para minado de criptomonedas. Por un lado, está el hecho de
que el sobre uso puede desgastar los componentes computacionales y reducir el
tiempo de vida esperado de los equipos. Especialmente, cuando los equipos son
sujetos a operaciones prolongadas a altas temperaturas, cosa que ocurre para
operaciones de minado. Por otro lado, están las razones medio ambientales. No
solo el minado de criptomonedas fomenta el consumo excesivo de enerǵıa, el cual
dependiendo del origen puede implicar la quema de combustibles fósiles, sino
también tiene un efecto sobre factores de convivencia. Tener equipos minando
en salas de computadores de la universidad afecta el ambiente de las salas pues
aumenta la disipación de calor y la contaminación auditiva, lo cual puede llevar
a un detrimento en las condiciones de trabajo.
Por último, es importante recalcar que el mercado de criptomonedas está
buscando alternativas a los protocolos basados en prueba de esfuerzo para
reducir las afectaciones medioambientales. Por ejemplo, este es el caso de
Ethereum donde la plataforma está migrando a un algoritmo de consenso basado
en prueba de participación con el fin de reducir el gasto energético y los requer-
imientos computacionales, entre otros [19]. Para la universidad entrar a invertir
25
en la infraestructura necesaria para llevar a cabo tareas de minado tradicional
cuando las tendencias recientes buscan alternativas a este esquema, podŕıa hacer
que se incurrieran en perdidas económicas y en una sub-utilización de recursos
aun mayor.
References
[1] Current vs reported hashrate · issue 1008 · ethereum-mining/ethminer.
URL: https://github.com/ethereum-mining/ethminer/issues/1008.
[2] Eligiendo un pool para participar en la mineria de bitcoins. — by
marvin g. soto — medium. URL: https://marvin-soto.medium.com/
eligiendo-un-pool-para-participar-en-la-mineria-de-bitcoins-510766b2daf0.
[3] Gpu passthrough guide for ubuntu 20.04 - youtube.
https://www.youtube.com/watch?v=tDMoEvf8Q18&t=1s.
[4] Home - ethermine - ethereum (eth) mining pool. https://ethermine.org/.
[5] How does zombie mode work? : Ethermining. URL: https://www.reddit.
com/r/EtherMining/comments/las51e/how_does_zombie_mode_work/.
[6] Is my hardware supported. https://www.nicehash.com/support/mining-
help/general-help/is-my-hardware-supported.
[7] Minerstat. https://minerstat.com/.
[8] Mineŕıa de bitcoin: Fpga, asic, cpu, gpu y pools — by marvin g.
soto — medium. URL: https://marvin-soto.medium.com/miner\%C3\
%ADa-de-bitcoin-fpga-asic-cpu-gpu-y-pools-1fa2bf5085dd.
[9] Releases · develsoftware/gminerrelease. https://github.com/develsoftware/GMinerRelease/releases.
[10] Releases · lolliedieb/lolminer-releases. https://github.com/Lolliedieb/lolMiner-
releases/releases.
[11] T-rex is a simple in use and highly optimized mining software. https://trex-
miner.com/.
[12] Gregorio Ospina Arango. Propuesta para el aprovechamiento de los recursos
computacionales en la sala alan turing. 2021. URL: http://hdl.handle.
net/1992/53010.
[13] Avast. Avast threat labs - cryptomining behavior guidelines —
avast. https://support.avast.com/en-eu/article/Threat-Lab-cryptomining-
behavior-guideline/.
[14] Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick
McCorry, Sarah Meiklejohn, and George Danezis. Consensus in the age of
blockchains. 11 2017. URL: http://arxiv.org/abs/1711.03936.
26
[15] Bitfly. GENERAL TERMS OF OPERATION, 2021. URL: https:
//bitfly.at/GTO_v1.6.pdf.
[16] Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind Narayanan,
Joshua A. Kroll, and Edward W. Felten. Sok: Research perspectives
and challenges for bitcoin and cryptocurrencies. volume 2015-July, pages
104–121. Institute of Electrical and Electronics Engineers Inc., 7 2015.
https://doi.org/10.1109/SP.2015.14 doi:10.1109/SP.2015.14.
[17] Emporia. Emporia smart plug spec sheet. URL: https:
//uploads-ssl.webflow.com/5fff2b7694451e66ba2f5a3d/
615cbc47de12bb99cf99da22_Smart20Plug20Technical20Specs.pdf.
[18] Emporia. How the emporia smart plug works.
https://www.emporiaenergy.com/emporia-smart-plug.
[19] Ethereum. Proof-of-stake (pos) — ethereum.org.
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/.
[20] Zonghao Feng and Qiong Luo. Evaluating memory-hard proof-of-work algo-
rithms on three processors. volume 13, pages 898–911. VLDB Endowment,
2020. https://doi.org/10.14778/3380750.3380759 doi:10.14778/3380750.
3380759.
[21] Coin Guides. Mining software getting blocked and removed by anti-virus.
https://coinguides.org/miner-detected-virus/.
[22] Runchao Han, Nikos Foutris, and Christos Kotselidis. Demystifying
crypto-mining: Analysis and optimizations of memory-hard pow algo-
rithms. pages 22–33. Institute of Electrical and Electronics Engineers Inc., 4
2019. https://doi.org/10.1109/ISPASS.2019.00011 doi:10.1109/ISPASS.
2019.00011.
[23] Intel. Cpu vs gpu: ¿cuál es la diferencia?
https://www.intel.la/content/www/xl/es/products/docs/processors/cpu-
vs-gpu.html.
[24] Intel. What is a gpu? graphics processing units defined.
https://www.intel.la/content/www/xl/es/products/docs/processors/what-
is-a-gpu.html.
[25] Jan Lansky. Possible state approaches to cryptocurrencies. Journal of
Systems Integration, 9:19–31, 1 2018. https://doi.org/10.20470/jsi.v9i1.335
doi:10.20470/jsi.v9i1.335.
[26] McAfee. Why coin miners go bad & how to protect your tech when they do
— mcafee blogs. https://www.mcafee.com/blogs/internet-security/why-
coin-miners-go-bad-how-to-protect-your-tech-when-they-do/.
27
[27] MinerStat. Calendario y calculadora del tamaño de dag — minerstat.
https://minerstat.com/dag-size-calculator?lang=es.
[28] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
URL: www.bitcoin.org.
[29] Matteo Romiti, Aljosha Judmayer, Alexei Zamyatin, and Bernhard Hasl-
hofer. A deep dive into bitcoin mining pools: An empirical analysis of
mining shares. 5 2019. URL: https://arxiv.org/abs/1905.05999v1.
[30] Arthur Alejandro Oviedo Urazmetov. Unacloud msa - plataforma basada
en unacloud para la generación y análisis de alineamientos múltiples de
secuencias. instname:Universidad de los Andes, 2011. URL: http://hdl.
handle.net/1992/14748.
28