46493

Vista previa del material en texto

Universidad de Costa Rica
Facultad de Ingenieŕıa
Escuela de Ingenieŕıa Eléctrica
Fundamentos para la aplicación del concepto de
blockchain en el Sistema Eléctrico Nacional
Por:
Ing. Daniel Fuentes Soto
Ing. Ricardo Bejarano Viachica
Ing. Sebastian Blanco Arias
Ciudad Universitaria “Rodrigo Facio”, Costa Rica
Noviembre 2021
UNlVERSJDAD DE E I E Escuela de 
COSTA RICA · . . Ingeniería Eléctrica 
ACTA Nº 002-2022 
PRESENTACIÓN 
TRABAJO FINAL DE GRADUACIÓN: SEMINARIO DE GRADUACIÓN 
FECHA: Míércoles 16 de marzo de 2022 
HORA: 6:30 P.M. 
LUGAR: Defensa Pública Virtual 
TITULO DEL TRABAJO: "Fundamentos para la aplicación del concepto de blockchain en 
el Sistema Eléctrico Nacional". 
ESTUDIANTES: CARNÉ CALIFICACIÓN 
ING. HERMAN BEJARANO VIACHICA 800870 9,2 
1 
ING. DANIEL FUENTES SOTO 1332699 9,4 
ING. SEBASTIAN BLANCO ARIAS 841005 9,4! 
T1RIBUNAL EXAMINADOR FUNCIÓN 
M.Sc. TEODORO WILLINK CASTRO REPRESENTANTE 
M.Sc. PABLO FERNANDEZ PORRAS 
Ph . D. JAIRO QUIROS TORTOS 
M.B.A.CHRISTIAN ROJAS RODRIGUEZ 
M. Se. ALEX VASQUEZ CASTILLO 
Observaciones: 
DIRECTOR DE LA 
ESCUELA 
MIEMBRO DEL 
TRIBUNAL 
DIRECTOR 
COMITÉ ASESOR 
MIEMBRO 
COMITÉ ASESOR 
MIEMBRO 
COMITÉ ASESOR 
FIRMA 
FIRMA 
Firmado digitalmente 
por TEODORO JOSE 
L.Í- IA./.A<.k. ~:~~~~CASTRO 
Fecha: 2022.04.25 
08:16:35 -06'00' 
JA1 RO Digitally sign~d by JAIRO 
HUMBERTO HUMBERTOQUIROS 
TORTOS (FIRMA) 
QUI ROS TORTOS oateo2omi•.is 
(FIRMA) 09"'2•47 ·06'00' 
CHRISTIAN Firmitdodi<;iítalm~tepor 
ROLANDO ROJAS CHRISTJA.N~NOOROJAS 
R~GUEZ (FIRMA) 
RODRIGUEZ F..:n.:2022.os.041s:02:04 
(FIRMA) -06'00' 
Ya. José David RQjas. Director de la Escuela de lngeni1erLa Eléctrjca . urmiWo 
, . ·. ·.. fi . . . .. . díg1talmente por 
;,::~::::::=~=:~=~~:~,, PEE' 
1rma d1g1tal en este momento no.43'59 06'00 ' 
Escuela de Ingeniería Eléctrica, Código Postal 2060, San José, Costa Rica 
Teléfono: 2511-2600 Fax: 2511-261 O Web: eie.ucr.ac.cr Correo electrónico: rece pcion.eie@ucr.ac .cr 
Fundamentos para la aplicación del concepto de 
blockchain en el Sistema Eléctrico Nacional 
Por: 
Ing. Daniel Fuentes Soto 
Ing. Ricardo Bejarano Viachica 
Ing. Sebastian Blanco Arias 
Sometido a la Escuela de Ingeniería Eléctrica de la Facultad de 
Ingeniería de la Universidad de Costa Rica, como requisito parcial para 
optar por el grado de: 
LICENCIADO EN INGENIERÍA ELÉCTRICA 
Aprobado por el Tribunal: 
Ing. Teodoro Willink Castro, MSc. 
Representante del Director, Escuela de Ingeniería Eléctrica 
Ing. Jairo Quirós-Tortós, PhD. 
Tutor, Comité Asesor 
Ing. Christian Rojas Rodríguez, MBA 
Lector, Comité Asesor 
Ing. Al ex V ásquez Castillo, MSc. 
Lector, Comité Asesor 
Ing. José Pablo Fernández Porras, MSc. 
lVIiembro del Tribunal 
Índice general
Índice de figuras vii
Índice de cuadros ix
Nomenclatura xi
1 Introducción 1
1.1 Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Planeamiento del Problema . . . . . . . . . . . . . . . . . . . . 3
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Metodoloǵıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Estado del arte 7
2.1 Definición General . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Estructura de una Cadena de Bloques . . . . . . . . . . . . . . 8
2.3 Accesibilidad de una cadena de bloques: Públicas, Privados y
Consorcios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Protocolos de consenso . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Contratos Inteligentes . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Seguridad y criptograf́ıa . . . . . . . . . . . . . . . . . . . . . . 21
3 Plataformas 25
3.1 Plataformas más usadas en el sector enerǵıa . . . . . . . . . . . 26
3.2 Implementaciones realizadas . . . . . . . . . . . . . . . . . . . . 30
3.3 Criterios de comparación . . . . . . . . . . . . . . . . . . . . . . 38
4 Marco Juŕıdico-Regulatorio 41
4.1 Legislación nacional referente a temas de enerǵıa eléctrica que
pueden interferir en tecnoloǵıas de Cadenas de Bloques . . . . . 41
4.2 Tendencias internacionales en regulación de Cadenas de Bloque 44
4.3 Modelos de Negocio . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Casos de estudio y aplicaciones en el sector enerǵıa 51
5.1 Posibles aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Iniciativas de implementación . . . . . . . . . . . . . . . . . . . 59
v
5.3 Implementaciones a pequeña escala . . . . . . . . . . . . . . . . 64
5.4 Condiciones Habilitadoras . . . . . . . . . . . . . . . . . . . . . 67
5.5 Posibles implementaciones de cadenas de bloques en el sector
enerǵıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.6 Consideraciones a nivel de mercado . . . . . . . . . . . . . . . . 79
6 Condiciones en Costa Rica y viabilidad 85
6.1 Despliegue de la tecnoloǵıa AMI . . . . . . . . . . . . . . . . . 85
6.2 Micro Red de Prueba (MRP) . . . . . . . . . . . . . . . . . . . 91
7 Conclusiones y Recomendaciones 109
7.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2 Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8 Anexos 117
8.1 Anexos (Link de Acceso) . . . . . . . . . . . . . . . . . . . . . . 117
Bibliograf́ıa 119
vi
Índice de figuras
2.1 Diagrama que ilustra como se registra una transacción en una ca-
dena de bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Estructura de 6 capas para una cadena de bloques, adaptado de
Yang et al. (2019) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Representación grafica del algoritmo PoW, extraido de Li et al.
(2020) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Descripción del proceso de activación de un contrato inteligente en
el caso de una venta par a par en generación distribuida . . . . . . 19
3.1 Registro de cuenta primaria en MetaMask. . . . . . . . . . . . . . 31
3.2 Cuenta primaria 0x5dB88a1286DC7D2E996461AFBdF3B7c91c0B5ec2
con la totalidad de los tokens. . . . . . . . . . . . . . . . . . . . . . 31
3.3 Cuenta secundaria 0xC8dE9fD765a973B2C985d58c4AfF452d79F522fc,
vaćıa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Transferencia de 10M TFGC hacia cuenta secundaria. . . . . . . . 32
3.5 Confirmación de transferencia. . . . . . . . . . . . . . . . . . . . . 33
3.6 Cuenta secundaria con 10M TFGC. . . . . . . . . . . . . . . . . . 34
3.7 Cuenta primaria después de haber transferido los TFGC a la cuenta
secundaria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1 Micro redes acopladas a la red de media tensión mediante una
plataforma BC que administra el módulo M; cada módulo M ad-
ministra un transformador de estado sólido (SST, por sus siglas en
inglés). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2 Micro red compuesta por fuentes de enerǵıa renovable y módulos
para almacenar enerǵıa; acoplados a la red de baja tensión me-
diante una plataforma BC que administra el módulo N. (F: fuente,
A: módulo para almacenar enerǵıa, FA: fuente más módulo para
almacenar enerǵıa) . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3 Provincia de Puntarenas: Extracto de Barrio Fray Casiano de Madrid 92
6.4 MR: Diagrama de interacción/comunicación. SCMS: front-end. . . 104
6.5 Diagrama de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . 107
vii
viii
Índice de cuadros
2.1 Cuadro comparativo entre tipos de cadenas de bloques según su
accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Cuadro comparativo sobre las plataformas de Blockchain utilizadas
en el sector enerǵıa . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 Proyectos e iniciativas Blockchain en el sector energético: Proyec-
tos relacionadosa: IoT y dispositivos inteligentes, descentralización
de mercados eléctricos. (información tomada de Alianza energética
entre México y Alemania (2020)) . . . . . . . . . . . . . . . . . . . 60
ix
Nomenclatura
AI Inteligencia Artificial (del ingles Artificial Intelligence)
ADMS Advance Distribution Management System
ATC Aspectos Técnicos Comunes
ATP Aspectos Técnicos Propios
ARESEP Autoridad Reguladora de Servicios Públicos
AMI Infraestructura de Medición Avanzada (del ingles Advan-
ced Meter Infraestructure)
BC Cadena de Bloques (del inglés Blockchain)
BOT Construcción-Operación-Transferencia (del inglés Build-
Operate-Tranfer)
CNFL Compañ́ıa Nacional de Fuerza y Luz S. A.
COOPEALFARORUIZR.L. Cooperativa de electrificación rural de
Alfaro Rúız
COOPEGUANACASTER.L. Cooperativa de electrificación rural de
Guanacaste
COOPELESCAR.L. Cooperativa de electrificación rural de San Car-
los
COOPESANTOSR.L. Cooperativa de electrificación rural de los San-
tos
CONELCTRICAS Consorcio Nacional de Empresas de Electrificación
de Costa Rica R. L.
DoS Denegación de Servicio (del inglés Denial of Service)
ESPH Empresa de Servicios Públicos de Heredia
EBX Energy Blockchain Exchange
EMTS Energy Managemente Trading System
xi
ERV E Estación de Recarga de Veh́ıculos Eléctricos
EWF Energy Web Foundation
FHC Factores Habilitadores Comunes
FHP Factores Habilitadores Propios
GD Generación Distribuida
ICE Instituto Costarricense de Electricidad
IoT Internet de las Cosas (del inglés Internet of Things)
JASEC Junta Administrativa del Servicio Eléctrico Municipal de
Cartago
MINAE Ministerio de Ambiente y Enerǵıa
MR Micro Red
MRP Micro Red de Prueba
PoW Prueba de Trabajo (del inglés Proof of Work)
PoS Prueba de Peso o Participación (del inglés Proof of Stake)
PoAu Prueba de Autoridad (del inglés Proof of Authority)
SIEPAC Sistema de Interconexión Eléctrica para Páıses de Amé-
rica Central
SENCR Sistema Eléctrico Nacional de Costa Rica
SCP Plataforma de Contratos Inteligentes (del inglés Smart
Contract Platform)
SCMS Sistema de Gestión de Contratos Inteligentes (del inglés
Smart Contract Management System)
SG Red Inteligente (del inglés Smart Grid)
SST Transformador de Estado Sólido (del inglés Solid State
Transformer)
TI Tecnoloǵıas de Información
TCO Costo Total de Propiedad (del inglés Total Cost of Ow-
nership)
xii
TFGC Trabajo Final de Graduación Coin
P2P De igual a igual (entre iguales) (del inglés Peer-to-Peer)
V E Veh́ıculo Eléctrico
V 2G Del Veh́ıculo a la red eléctrica (del inglés Vehicle to Grid)
V PP Planta de Enerǵıa Virtual (del ingles Virtual Power Plant)
xiii
1 Introducción
La cadena de bloques o blockchain (que abreviaremos como BC en este do-
cumento) es una tecnoloǵıa de información que se popularizó por primera vez
como la tecnoloǵıa detrás de la criptomoneda Bitcoin. Las cadenas de bloques
son registros cifrados que permiten transacciones sin la dependencia de un ente
centralizado. Además, su principio de funcionamiento permite transparentar
esta red de transacciones codependientes y, por tanto, alterar información en
ellas es dif́ıcil. La seguridad aumenta el nivel de confianza en las herramientas
que utilizan esta tecnoloǵıa.
Esta tecnoloǵıa se puede aplicar en distintas áreas más allá de su nacimien-
to en los servicios financieros, una de las aplicaciones con mayor potencial es
en los servicios de generación, transmisión y distribución de enerǵıa eléctrica,
aun aśı, la implementación de cadenas de bloques despierta muchas inquietu-
des entre los miembros participantes del Sistema Eléctrico Nacional de Costa
Rica (SENCR).
Este proyecto busca realizar un estudio sobre las condiciones habilitadoras
para la aplicación del concepto en el SENCR, basándose en cuatro aspectos
principalmente:
• Los componentes y caracteŕısticas técnicas del concepto de cadenas de
bloques (por ejemplo, tipos de blockchain, y mecanismos de consenso), y
cómo estas caracteŕısticas permiten la aplicación de la cadena de bloques
en las distintas etapas del sistema eléctrico (generación, transmisión y
distribución).
• Las diversas opciones de plataformas disponibles para implementar block-
chain, a través de análisis que permitan comparar el desempeño de las
diferentes opciones.
• Las experiencias internacionales con la implementación de blockchain en
sistemas eléctricos. Es fundamental reconocer las caracteŕısticas de estas
aplicaciones, y cuáles han sido sus aciertos y limitaciones.
• Las implicaciones técnicas, legales, regulatorias y financieras, a nivel
internacional, que estas aplicaciones tienen sobre los sistemas eléctricos,
los ambientes, legales y económicos que los componen.
1
2 1 Introducción
1.1 Justificación
El paradigma del mercado eléctrico ha empezado a experimentar grandes cam-
bios en los últimos años. La inserción de nuevas tecnoloǵıas como los paneles
solares, los veh́ıculos eléctricos (VEs) y los sistemas de almacenamiento han
modificado los patrones de generación y consumo. Además, los consumido-
res poseen un papel más activo en el mercado. Inclusive, se han introducido
conceptos como el de prosumidor, para clientes que instalan sistemas de ge-
neración distribuida en sus espacios de consumo.
Por tanto, ha existido un interés creciente por desarrollar mecanismos de
gestión que permitan un papel más dinámico de todos los participantes, que
generen un mayor beneficio económico, pero que no descuiden la seguridad
operativa del sistema y de las transacciones de electricidad que se ejecutan.
Estos requerimientos han generado expectativa y un aumento en la investi-
gación de herramientas de transacción basadas en el concepto de blockchain
(BC ), y de sus posibles aplicaciones en los sistemas eléctricos.
A pesar de la creciente cantidad de propuestas y aplicaciones de este con-
cepto en las transacciones del sistema eléctrico, la complejidad de su principio
de funcionamiento y la falta de documentación clara y agregada, podŕıa ge-
nerar dudas y escepticismo hacia su implementación por parte de diversos
miembros del SEN (Sistema Eléctrico Nacional). Por tanto, la recolección y
asimilación de la información pertinente a cadenas de bloques, es clave para
facilitar las discusiones y la toma de decisiones con respecto a su implemen-
tación.
Analizar y documentar las experiencias internacionales daŕıa luz sobre cuá-
les han sido los aspectos que han favorecido y obstaculizado estas aplicaciones.
Con ello seŕıa posible estudiar cómo la realidad del SEN y del marco legal,
reglamentario y financiero costarricense pueden permitir o dificultar la puesta
en marcha de estas aplicaciones dentro del páıs. La comparación de diversas
aplicaciones en los mismos sectores (por ejemplo, VEs o transacciones par-a-
par) permitiŕıa la elección de las mejores alternativas, en caso de que se desee
implementar alguna de ellas en Costa Rica.
Los efectos de aplicaciones basadas en cadenas de bloques a gran escala
sobre el SEN son una incógnita. La investigación del impacto de ellas en la
operación y el control de los sistemas eléctricos ha sido insuficiente. La mayo-
ŕıa de los estudios realizados ignora las restricciones de la red en la generación
de sus propuestas. Es fundamental reconocer cuáles son las consecuencias que
traeŕıa la introducción de este concepto en el SEN, y aśı aprovechar sus ven-
1.2. Planeamiento del Problema 3
tajas, sin comprometer la seguridad y confiabilidad del sistema.
Por otro lado, las aplicaciones con cadenas de bloques representan un reto
a nivel regulatorio. Las relaciones institucionales ICE-ARESEP-Distribuidoras
pueden ser ŕıgidas. Por lo tanto, se debe analizar como las aplicaciones exis-
tentes se ajustan a la normativa vigente e identificar cuáles deben ser las
actualizaciones necesarias a la regulación para obtener el máximo provecho de
ellas. El marco regulatorio y la legislación técnicadebe mantenerse al d́ıa para
poder seguir el paso a los avances tecnológicos, de lo contrario, esto represen-
taŕıa una limitación al avance o aún peor, la creación no intencional de vaćıos
legales que puedan provocar un daño a los ciudadanos o a las instituciones.
La dimensión económica también es sumamente importante. La implemen-
tación de nuevas tecnoloǵıas no sólo debe responder a los intereses y objetivos
institucionales, sino que deben ser utilizadas de forma que no afecten la salud
financiera de la organización, por el contrario, la innovación que incentive el
crecimiento económico es idónea. Un impacto económico positivo mejora la
capacidad financiera de las distintas empresas distribuidoras que operan en
territorio nacional (por ejemplo, ICE) y reduce la presión sobre las tarifas.
Aśı, es fundamental para las empresas eléctricas llevar la delantera en el
estudio de las posibles aplicaciones de cadenas de bloques en sus sistemas de
potencia, y los impactos de estas, para aśı estar preparadas ante las posibles
transformaciones del mercado eléctrico. Para los reguladores, es importante
comprender la tecnoloǵıa y los riesgos que puede generar. Todo esto razona
con la necesidad de generar investigación en el tema.
1.2 Planeamiento del Problema
El proyecto surge como una propuesta para los participantes y reguladores del
mercado eléctrico en Costa Rica, sobre cómo incorporar sistemas de cadenas
de bloques en sus estructuras de negocios. El problema a resolver, corresponde
en entender y definir los retos a superar para la incorporación del concepto
de cadenas de bloques en sistemas de potencia y/o enerǵıa dentro del merca-
do eléctrico nacional. El Sistema Eléctrico Nacional de Costa Rica (SENCR)
posee una regulación compleja, por lo tanto, es importante que el aparato es-
tatal se mantenga actualizado e incorpore las tecnoloǵıas, con prudencia, más
eficientes de forma regular.
4 1 Introducción
1.3 Objetivos
Objetivo General
Estudiar la posibilidad de implementación de las cadenas de bloques (Block-
chain) en el Sistema Eléctrico de Costa Rica.
Objetivos espećıficos
• Documentar las aplicaciones y los protocolos de consenso de las cadenas
de bloques en un sistema eléctrico.
• Comparar el rendimiento de las plataformas utilizadas para la imple-
mentación de las cadenas de bloques.
• Documentar las experiencias de implementación de las cadenas de blo-
ques en el sistema eléctrico.
• Definir las condiciones habilitadoras técnicas, legales, regulatorias y fi-
nancieras para la implementación de cadenas de bloques en el sistema
eléctrico de Costa Rica.
1.4 Alcance
Dentro de los alcances considerados en este proyecto se tiene lo siguiente:
• La comparación de las aplicaciones internacionales no corresponde a una
implementación completa de cada una de ellas en una plataforma infor-
mática. El análisis comparativo se realizará mayoritariamente a partir
de la información documentada disponible, y se realizarán pequeñas si-
mulaciones cuando se considere necesario para la comparación. En estas
simulaciones, el tamaño de las redes es a escala. No se considerarán cam-
bios en la red durante la operación. Es decir, apagones o modificaciones
de impedancias por temperatura son situaciones fuera del alcance de
este proyecto.
• El análisis financiero sólo contemplará el impacto asociado directamente
a las aplicaciones a implementar, por lo que no se plantea hacer un
análisis financiero institucional completo. Se parte del hecho de que todos
los aspectos económicos para el análisis son conocidos o proyectados con
algún sustento, en caso de que exista incertidumbre sobre algún elemento
y su incidencia en la investigación, no se incluirá.
1.5. Metodoloǵıa 5
• La identificación de condiciones regulatorias actuales y recomendaciones
futuras sólo se harán con respecto a las leyes, directrices y normativas
que sean de conocimiento público, cualquier elemento de control interno
o convenio de relación institucional que no sea público no podrá ser
contemplado en este análisis.
1.5 Metodoloǵıa
• Estudiar las experiencias internacionales con la implementación de apli-
caciones basadas en Blockchain.
• Documentar las condiciones habilitadoras, plataformas usadas y algorit-
mos de consenso en los casos de éxito.
• Definir los criterios de comparación para las plataformas de aplicacio-
nes de Blockchain en función de las caracteŕısticas de interés para su
implementación en el sistema eléctrico nacional.
• Realizar el análisis comparativo de plataformas para Blockchain.
• Analizar las combinaciones de plataforma y algoritmos de consenso idó-
neos para el caso nacional, con sus ventajas y desventajas respectivas.
• Identificar los retos técnicos, legales, regulatorios y financieros que el
mercado debe superar para poder habilitar la implementación de apli-
caciones basadas en Blockchain para el sector enerǵıa.
• Recomendar acciones para poder subsanar las carencias que impiden la
introducción de la tecnoloǵıa en el mercado nacional.
2 Estado del arte
2.1 Definición General
Según Mattila et al. (2016) podemos definir una cadena de bloques como una
estructura de datos digital, compartida y distribuida. En este sistema cada
transacción o registro de información debe ser validada por todos los partici-
pantes o nodos1 de la cadena; de modo que cada nuevo ingreso de información,
o cualquier cambio realizado en la cadena sólo se puede realizar si existe un
consenso entre los miembros, una vez existe el consenso el ingreso/cambio de
información se hace efectivo.
Las transacciones se agregan en formaciones más grandes, llamadas blo-
ques, que tienen una marca de tiempo y están, criptográficamente vinculados,
a bloques anteriores formando una cadena de registros que determina el orden
de secuenciación de eventos o la cadena de bloques. Además de describir la
propia estructura de datos, la terminoloǵıa también se usa ampliamente en
la literatura para representar arquitecturas de consenso digital, algoritmos o
dominios de aplicaciones construidos sobre tales arquitecturas.
Andoni et al. (2018) menciona que las cadenas de bloques pueden verse
como bases de datos que permiten a múltiples usuarios hacer cambios en un
registro central común simultáneamente. En lugar de gestionar el registro por
un único administrador confiable, cada miembro individual de la red tiene una
copia de los registros y sólo se realizan cambios si se llega a un consenso entre
los participantes.
La metodoloǵıa exacta de cómo se alcanza el consenso entre las partes
es un área de investigación en curso y puede diferir para adaptarse a una
amplia gama de aplicaciones y dominios. En una cadena de bloques, las nuevas
transacciones están vinculadas a transacciones anteriores por criptograf́ıa, a
este proceso criptográfico se le conoce como hash, el cual funciona cifrando
los datos de entrada y almacenando el resultado cifrado, esto hace que las
redes de cadenas de bloques sean resistentes y seguras. Cada usuario de la red
puede verificar por śı mismo si las transacciones son válidas, lo que proporciona
transparencia y registros confiables a prueba de manipulaciones.
1Un nodo puede ser cualquier tipo de dispositivo capaz de interactuar con alguna plata-
forma blockchain.
7
8 2 Estado del arte
“A” quiere hacer una 
transacción con “B”
La transacción se almacena 
en un bloque
Se les comunica a los 
participantes de la 
transacción
La transacción fue 
registrada correctamente
Los partricipantes validan la 
transacción
El bloque sellado y validado se 
añade a la cadena de bloques y 
se enlaza con los otros bloques
A
B
A B
1 3 5
2 4 6
Figura 2.1: Diagrama que ilustra como se registra una transacción en una
cadena de bloques
2.2 Estructura de una Cadena de Bloques
Las cadenas de bloques como una herramienta informativa, son más que un
programa o una aplicación, involucran una serie de procesos concatenadosentre śı, que interactúan en función de la aplicación final. Yang et al. (2019)
propone que la estructura de una cadena de bloques está dividida en seis capas:
la capa de datos, la capa de red, la capa de consenso, la capa de contratos y
la capa de aplicación. Shuai et al. (2018) amplia un poco sobre el significado
y propósito de las capas en la cadena de bloques.
2.2. Estructura de una Cadena de Bloques 9
• La capa de datos incluye los datos subyacentes que se utilizan en la ca-
dena, los bloques, mensajes cifrados relacionados y marca de tiempo,
entre otros. El contenido va a variar en función de la aplicación que se
esté utilizando. Una cadena de bloques para criptomonedas almacena-
rá datos de los nodos que realizan transacciones aśı como información
financiera relevante.
• La capa de red se refiere a como el sistema blockchain se comunica entre
sus nodos. Usualmente tiende usarse un protocolo P2P distribuido, en
la que todos o algunos aspectos funcionan sin clientes ni servidores fijos,
sino una serie de nodos que se comportan como iguales entre śı. Es decir,
actúan simultáneamente como clientes y servidores respecto a los demás
nodos de la red. Los nodos de la red en una cadena de bloques tienen las
caracteŕısticas de igualdad, autonomı́a y distribución. Todos los nodos
están conectados en una estructura topológica sin cualquier nodo central
autorizado o jerarqúıa.
• La capa de consenso contiene el algoritmo mediante el cual la cadena de
bloques agrega información a los bloques que la conforman, la cadena
de bloques descentralizada se gestiona conjuntamente entre múltiples
partes.
• La capa de incentivo u objetivo es la que determina cual va a ser el
propósito de que el sistema opere. Realizar transacciones, intercambiar
información, generar criptomonedas, entre otros. En un sistema descen-
tralizado el sistema está interesado en śı mismo. Por lo tanto, meca-
nismos compatibles con incentivos deben ser diseñados, de modo que el
comportamiento racional individual de los nodos de consenso, para ma-
ximizar sus propios beneficios, puede alinearse de manera incentivadora
con el objetivo general de garantizar la seguridad.
• La capa de contrato es donde se realizan los acuerdos entre los nodos
participantes de la cadena; estos contratados pueden aplicarse de forma
automatizada, predefiniendo las condiciones en las que se ejecuta una
transacción.
• La capa de aplicación se trata del objetivo final de implementación, es
donde se define como interactúa el usuario con la aplicación, donde se
ejecutan las funciones programadas para realizar el objetivo.
10 2 Estado del arte
Capa de
Aplicación
Capa de
Incentivos
Capa de
Consenso
Capa de
Comunicación
Capa de
Datos
Capa de 
Contratos
Divisa
de intercambio
Código Algoritmo
Contratos
Inteligentes
Funciones
Programables
Interfaz de
Usuario
Mecanismo de
Emisión
Mecanismo de
Distribuición
PoW PoS DPoS ....
Intercambios
Par-a-Par
Mecanismo de 
Entrega
Mecanismo de 
Verificación
Bloque de
Datos
Función
Hash
Estructura
de Cadena
Nodos
Estampa
Temporal
Encriptación
Asimétrica
Figura 2.2: Estructura de 6 capas para una cadena de bloques, adaptado de
Yang et al. (2019)
2.3. Accesibilidad de una cadena de bloques: Públicas, Privados y Consorcios11
2.3 Accesibilidad de una cadena de bloques: Públicas,
Privados y Consorcios
Una de las principales caracteŕısticas que definen una cadena de bloques es
quien puede participar en ellas, la mayoŕıa de aplicaciones se dividen en pú-
blicas, privadas y consorcio. La diferencia radica en la accesibilidad, cada tipo
tiene un nivel de apertura distinto como se muestra en la cuadro 2.1.
Zheng et al. (2017) menciona que en una cadena de bloques pública, todos
los registros son visible al público y todos pueden participar en el proceso de
consenso. De manera diferente, solo un grupo participante o nodos preselec-
cionados participaŕıa en el proceso de consenso de un consorcio. En el caso
de un sistema privado, solo aquellos nodos que provienen de una organización
espećıfica se les permitiŕıa unirse el proceso de consenso. Una cadena de blo-
ques privada es considerada como una red centralizada, ya que es totalmente
controlado por una organización. El consorcio se construye por varias organi-
zaciones y es parcialmente descentralizado, ya que solo una pequeña porción
de nodos seŕıa seleccionado para determinar el consenso.
Cada una de estas configuraciones poseen distintas ventajas y debilidades.
Una cadena de bloques pública puede tener problemas de velocidad en tran-
sacciones si crece demasiado, sin embargo, gracias a su arquitectura y número
de participantes, el BC público es altamente seguro.
Las cadenas de bloques privadas son, por definición, limitadas cuando se
trata de expansión. Esto porque los actores deben ser elegidos (o cumplir con
ciertas especificaciones) para ser agregados a la red. No obstante, debido a
que los socios son conocidos, las aplicaciones se desarrollan y usan de forma
rápida, a diferencia de una cadena pública.
Sin embargo, el alto nivel de eficiencia en las cadenas de bloques privadas
también significa que la cantidad de computadoras conectadas que deben ser
atacadas durante los intentos de manipulación es menor que en las cadenas de
bloques públicas. Establecer y operar cadenas de bloques privadas patentadas,
o modelos de licencia, también implica inversiones espećıficas con un riesgo fi-
nanciero correspondientemente mayor que el uso de soluciones existentes (de
código abierto).
Por otro lado, las cadenas de consorcio representan un compromiso entre
las cadenas de bloques públicas y privadas. Este tipo de BC enfocada a apli-
caciones que impliquen a varias organizaciones está limitada con respecto a la
12 2 Estado del arte
medida en que pueden ampliarse: tanto los participantes como las aplicaciones
autorizadas requieren la aprobación de todo el consorcio.
Cuadro 2.1: Cuadro comparativo entre tipos de cadenas de bloques según su
accesibilidad
Tipo Acceso Anonimato
Velocidad
de
Operación
Pública
Cualquier
participante
Śı
Lentas al tener
que validar
cambios entre todos
los participantes
Privada
Sólo participantes
de la
organización
que administre
la cadena
de bloques
Las identidades
de los
participantes
son conocidas
Más veloces al
ser más pequeñas y
centralizadas
Consorcio
Sólo participantes
que
pertenezcan
a las
organizaciones
del consorcio
Las identidades
de los
participantes
son conocidas
Más veloz que las
cadenas de
bloques públicas
pero más lentas
que las privadas,
dependiendo
del tamaño de
las cadenas de
bloque
Independientemente de si la cadena de bloques es pública o privada, de-
pendiendo de la aplicación puede ser práctico que los participantes pueden
tener distintos niveles de privilegios o permisos para realizar acciones dentro
del sistema, como menciona Mitani y Otsuka (2020). Si todos los nodos tienen
los mismos permisos, a este tipo de cadena se les conoce como permissionless.
Si una cadena de bloques tiene nodos participantes con diferentes permisos o
niveles de privilegio (por ejemplo: una cadena de bloques donde unos pueden
interactuar con la cadena, mientras otros sólo puedan leer la información) se
le conoce como permissioned.
Indistintamente del tipo o categoŕıa de la cadena de bloque, Morkunas
et al. (2019) indica que en todas ellas mantienen una serie de caracteŕısticas
2.3. Accesibilidad de una cadena de bloques: Públicas, Privados y Consorcios13
comunes:
• Son redes descentralizadas punto a punto, en que cada participante man-
tiene una réplica del registro de transacciones (la cadena);
• Estas replicas se mantienen sincronizadas a través de un protocolo de-
nominado consenso; y
• Brindan ciertas garant́ıas sobre la inmutabilidad del registro, incluso
cuando algunos de los propios participantes actúen de forma maliciosa.
14 2 Estado del arte
2.4 Protocolos de consenso
Un protocolode consenso es la metodoloǵıa o proceso que se utiliza en una
cadena de bloques para decidir si una acción en el sistema es válida. Distin-
tas investigaciones para varias aplicaciones, aplican una diversa variedad de
protocolos de consenso, incluso pueden generarse protocolos de consenso para
una aplicación particular. Cada protocolo posee una serie de beneficios par-
ticulares (como escalabilidad y velocidad) y debilidades. Para Andoni et al.
(2018) la metodoloǵıa utilizada para alcanzar el consenso en redes de cade-
nas de bloques determinan en gran medida el rendimiento, velocidad de la
transacción, seguridad y uso de recursos (como la electricidad). En términos
generales, siempre se requiere un procedimiento para generar y posteriormente
aceptar los bloques.
El proceso de agregar un bloque a la cadena, comienza cuando un partici-
pante o nodo del sistema busca generar o proponer un bloque, en este bloque
se codifica una serie de transacciones (por ejemplo, en un sistema de criptomo-
nedas, estas son transacciones monetarias entre diferentes cuentas). Una vez
que el bloque es creado, el siguiente paso clave para el bloque propuesto es ser
validado por los miembros de la red a través del protocolo de consenso. Una
vez que se valida un bloque, se convierte en parte de la cadena de bloques,
y los bloques recién creados son criptográficamente vinculados a la cadena.
Después de un tiempo (dependiendo del algoritmo de consenso utilizado), el
bloque se convierte en una parte permanente de la cadena de bloques, es decir,
llega a su estado final.
Algunos de los protocolos más relevantes se presentan a continuación.
• Proof of Work (PoW):
Los oŕıgenes de la prueba por trabajo (PoW) se presentan en Back (2002)
y es utilizado a menudo en criptomonedas. Fue desarrollado para limi-
tar el ataque de denegación de servicio (DoS, por sus siglas en inglés,
Denial of Service). En las cadena de bloques una vez que una serie de
transacciones se agrupan en bloques se deben agregar a la cadena o re-
gistro principal, sin embargo, cada bloque tiene vinculado un problema
criptográfico (hash) que debe ser resuelto para poder ser integrado con
el resto. Andoni et al. (2018) explica que los nodos mineros compiten
entre śı para agregar los nuevos bloques en la cadena existente. Cuando
se encuentra el hash correcto, el bloque se ingresa a la red, es aceptado
por otros nodos y el ciclo comienza de nuevo.
2.4. Protocolos de consenso 15
Procesar
el rompecabezas 
criptográfico
Verificar 
Solución
Verificar
Solución
Otros Nodos
Nodo C
Nodo B
Nodo A
Transmisión
Resolusión
del rompecabezas 
criptográfico
Creación 
de 
Bloque
Figura 2.3: Representación grafica del algoritmo PoW, extraido de Li et al.
(2020)
El algoritmo del PoW es descentralizado y es utilizado en cadenas de
bloques públicas; ya que los bloques agregados deben ser validados por
todos los nodos del sistema con facilidad y con un alto nivel de seguridad.
Sin embargo, este protocolo es muy demandante de recursos computacio-
nales por parte de sus miembros y no necesariamente es el más rápido
para implementar en una cadena donde existe cierto grado de confianza.
• Proof of Stakes (PoS):
La prueba por peso o participación (PoS) reemplaza el esfuerzo compu-
tacional por un proceso de selección aleatorio (por lo que es una alternati-
va más eficiente, en consumo energetico, que PoW), donde la posibilidad
de éxito de la mineŕıa con PoS se relaciona proporcionalmente al peso
que tiene un nodo en la cadena. Zheng et al. (2017) aclara que la proba-
bilidad de generar un bloque depende de lo que los nodos han invertido
en el sistema, es decir, entre mayor cantidad de transacciones o mayor
acumulación de la moneda de intercambio en la cadena de bloques, ma-
yor es la posibilidad de generar un bloque. Por ejemplo, un participante
con 5 ”monedas” tendrá cinco veces más probabilidades de ser elegido
16 2 Estado del arte
que alguien con 1 ”moneda”. Este enfoque aleatorio puede dar lugar a
una cadena más rápida y eficiente, pero la deja expuesta a que estos
actores de mayor peso controlen la cadena de forma inadecuada.
• Delegated Proof of Stakes (PoS):
La prueba de peso o participación delegada es una variación de la PoS
tradicional, desarrollada en 2014 por Daniel Larimer cofundador de bitsha-
res. En este algoritmo todos los participantes de la red pueden elegir los
delegados que van a participar en proceso de PoS tradicional, de esta
manera se logra mejorar la democratización del proceso. Este algoritmo
mejora algunos de los problemas de la centralización.
En el caso que describe BitShares (2019) hay un total de N delegados
quienes firman los bloques y son votados por aquellos que usan la red
con cada transacción que se realiza. En lugar de eliminar la necesidad
de confianza en conjunto, el DPOS transfiere esa confianza a un grupo
de delegados. De esta manera, cada bloque firmado debe tener una ve-
rificación de que el bloque anterior también debió ser firmado por un
nodo de confianza. El algoritmo DPOS elimina la necesidad de esperar
hasta que un cierto número de nodos no confiables hayan verificado una
transacción antes de que pueda confirmarse.
Al disminuir los requisitos para confirmar las transacciones se puede au-
mentar la velocidad en las mismas. Al colocar intencionalmente la con-
fianza con los firmantes potenciales más confiables, según lo decidido por
la red, no es necesario imponer un gravamen artificial para ralentizar el
proceso de firma de bloque ya que cada cliente en un sistema DPOS tie-
ne la capacidad de decidir en quién se conf́ıa en lugar de confiar quienes
tienen más recursos o peso en la cadena. Este sistema se aplica mediante
un proceso electoral justo en el que cualquiera podŕıa convertirse en un
representante delegado de la mayoŕıa de los usuarios. El DPOS permite
que se incluyan muchas más transacciones en un bloque que los sistemas
de prueba de trabajo o prueba de participación.
• Proof of Authority (PoAu):
La generación de bloques con prueba de autoridad (PoAu) requiere la
concesión de un permiso especial para uno o más miembros para realizar
cambios en la cadena de bloques. Por ejemplo, un miembro que tenga
una llave especial puede ser responsable de generar todos los bloques.
Para Andoni et al. (2018) el PoAu puede verse como un algoritmo PoS
2.4. Protocolos de consenso 17
modificado, donde los miembros de la red ponen su confianza en los
nodos autorizados y un bloque se acepta si la mayoŕıa de los nodos
autorizados firma el bloque. Este protocolo es especialmente útil cuando
el sistema casi no está expuesto al riesgo. Este método representa un
enfoque centralizado más apropiado para trabajar con gobiernos o entes
reguladores o regular. En la actualidad, también es popular entre las
empresas de servicios públicos en el sector energético.
18 2 Estado del arte
2.5 Contratos Inteligentes
El concepto de contratos inteligentes como se conoce en la actualidad fue pro-
puesto por Nick Szazo en 1994 y, generalmente, se refieren a acuerdos auto-
ejecutables entre una serie de participantes una vez que se cumplen ciertas
condiciones. Cong y He (2019) hace enfasis en que los contratos inteligentes
no son meros contratos digitales (muchos de los cuales necesitan confiar en
una autoridad para alcanzar el consenso y la ejecución) ni necesitan una inte-
ligencia artificial para crearlos.
Los contratos inteligentes tienen tres caracteŕısticas: autonomı́a, autosufi-
ciencia y descentralización. Autonomı́a significa que después de su lanzamien-
to y ejecución, los contratos y los agentes iniciadores no necesitan estar en
contacto adicional. En segundo lugar, el contrato inteligente puede ser au-
tosuficiente en su capacidad de recaudar fondos, proporcionando servicios y
gastarlos cuando sea necesario, por ejemplo, ganar poder de procesamiento o
almacenamiento. En tercer lugar, los contratos inteligentes son descentraliza-
dos ya que no subsisten enun solo servidor centralizado, se distribuyen y se
ejecutan automáticamente a través de los nodos de la red.
Wang et al. (2019) indica que si aplicamos los contratos inteligentes en
aplicaciones de cadenas de bloques descentralizados y distribuidos podemos
permitir que se realicen transacciones entre anónimos o partes no confiables
sin la necesidad de una autoridad central. Si los contratos inteligentes pueden
codificar cualquier regla predefinida y ejecutar las operaciones correspondien-
tes cuando se cumplen las condiciones de activación, podemos utilizarlo en
una variedad de aplicaciones.
En una red de distribución eléctrica un cliente con paneles solares puede
programar un contrato inteligente entre él mismo y la compañ́ıa dueña de la
red de distribución para que ejecute una venta de enerǵıa cada vez que tenga
un excedente de enerǵıa. Si integramos esta red de distribución en una ca-
dena de bloques, este contrato inteligente podŕıa plantearse sin la necesidad
de una intervención de la compañ́ıa dueña de la red, esta sólo actuaŕıa como
un medio de transporte y la transacción económica se daŕıa directamente en-
tre el generador distribuido y el consumidor. Un contrato inteligente podŕıa
activarse si un generador tiene un excedente y un consumidor necesita enerǵıa.
Para Zheng et al. (2020) si comparamos los contratos inteligentes con los
contratos convencionales, existen claras ventajas que ponen por delante el uso
de contratos inteligente, especialmente si se usan junto con las cadenas de
bloques:
2.5. Contratos Inteligentes 19
Generador/
Productor
Comprador Red de 
Distribuición
Contrato
Inteligente
Energía
Pago
Figura 2.4: Descripción del proceso de activación de un contrato inteligente
en el caso de una venta par a par en generación distribuida
• Reducción de riesgos: debido a la dificultad para cambiar el contenido de
una cadena de bloques, las transacciones que surjan de contratos inte-
ligentes ejecutados en la cadena no pueden modificarse arbitrariamente
una vez son emitidas. Además, debido a que cada uno de los nodos pue-
de consultar las transacciones y todos los datos que transcurren en la
cadena, los procesos realizados a través de contratos inteligentes en una
cadena de bloques son fácilmente auditables.
• Reducción de los costos de administración y servicio: Las cadenas de
bloques aseguran la confianza de todo el sistema mediante mecanismos
20 2 Estado del arte
de consenso distribuidos sin pasar por un mediador. Los contratos inte-
ligentes almacenados en blockchains se pueden activar automáticamente
de manera descentralizada. En consecuencia, los costos de administra-
ción y servicios debido a la intervención de terceros se pueden reducir
significativamente.
• Mejora de la eficiencia de los procesos de negocio: La eliminación de
la dependencia de un intermediario puede mejorar significativamente la
eficiencia de los procesos en un negocio. Completar un acuerdo predefi-
nido una vez se cumplen las condiciones de forma automática reduce el
tiempo de respuesta significativamente.
2.6. Seguridad y criptograf́ıa 21
2.6 Seguridad y criptograf́ıa
La mayoŕıa de las infraestructuras financieras modernas son de participación
centralizada, lo que implica la inclusión de un tercero que sea de confianza para
las partes. Este tercero es quien maneja cuentas, procesa pagos y brinda se-
guridad. Aitzhan y Svetinovic (2018) explica que un mercado completamente
sin confianza de sus participantes o con confianza moderada entre las par-
tes podŕıa proporcionar seguridad de transacción y privacidad de identidad,
sustituyendo la necesidad de un tercero al implementar técnicas criptográficas.
En los mercados de enerǵıa en donde el control de las transacciones es
centralizada se pueden presentar problemas de escalabilidad y seguridad. Los
puntos único de falla; donde el error de un intermediario conduce a una alte-
ración total de las actividades de autenticación y pago, o la falta de privacidad
asociada a la información que puede revelar el perfil t́ıpico de consumo por
tipo de cliente, obstruye la capacidad de proporcionar objetivos de seguridad,
disponibilidad y confiabilidad.
Criptograf́ıa de una cadena de bloques
Deligiannidis et al. (2014) menciona que las funciones criptográficas ’hash’
juegan un papel importante en la tecnoloǵıa moderna de comunicación. La
entrada de una función hash es un archivo o secuencia de cualquier tamaño y
la salida es una representación digital de tamaño fijo del archivo de entrada
que sirve como huella digital del archivo original (a menudo llamado resumen
del mensaje).
La idea detras del hash es que sea imposible reconstruir el archivo original
con solo la huella digital. De modo que cambiar un solo bit de información en
la entrada daŕıa como resultado una huella digital significativamente diferente.
Estos algoritmos están diseñados para evitar repetir huellas digitales, es decir,
es muy poco probable que dos mensajes, M y M’, produzcan la misma huella
digital utilizando una función hash dada.
Para Hassan y Hijazi (2017), la función hash criptográfica ideal tiene cuatro
principales propiedades:
• Es fácil calcular el valor hash para cualquier mensaje dado.
• Es casi imposible generar un mensaje desde un hash dado.
• Es imposible modificar un mensaje sin cambiar el hash.
• Es imposible encontrar dos mensajes diferentes con el mismo hash
22 2 Estado del arte
Posibles Vulnerabilidades de una Cadena de Bloques
Es normal que cualquier sistema tenga puntos débiles en su seguridad, aunque
las aplicaciones basadas en cadenas de bloques son caracterizadas justamente
por sus altos niveles de seguridad, es importante entender las posibles falencias
que poseen. Li et al. (2020) menciona algunas de las posibles debilidades o
vulnerabilidades de las que sufren los sistemas de cadenas de bloques:
Ataques del 51 % de la cadena
La cadena de bloques se basa en el mecanismo de consenso distribuido para
establecer confianza mutua entre todos los nodos que participan en la cadena,
Sin embargo, si un 51 % de los nodos alcanzan un consenso, pueden tomar
decisiones sobre toda la cadena, generando una vulnerabilidad, que puede ser
aprovechada por los atacantes para controlar toda la cadena de bloques. Más
precisamente, en PoW-based blockchains, si el poder de hashing de un solo
minero representa más del 50 % del poder de hashing total de toda la cadena
de bloques, entonces se puede lanzar el ataque del 51 %.
Llaves Criptográficas
De forma similar a los sistemas de firma digital, cuando se utilizan sistemas
basados en cadenas de bloques, la clave privada del usuario se considera como
la credencial de identidad y seguridad, que se genera y mantiene por el usuario
de forma segura. Un ejemplo de esto son las billeteras de bitcoin y sus accesos
a través de claves.
Si los delincuentes roban la clave privada de determinado usuario, la cuenta
blockchain correrá el riesgo de ser manipulada por otros. Dado que la cadena
de bloques no depende de algún tercer ente centralizado, si la clave privada
de un usuario es robada, es dif́ıcil rastrear el comportamiento del criminal y,
con ello, recuperar la cuenta.
Actividades Criminales
El anonimato y la privacidad que brindan las aplicaciones basadas en cadenas
de bloques traen consigo el riesgo de ser utilizadas para propósitos criminales.
Aśı por ejemplo, los usuarios de Bitcoin pueden tener múltiples direccio-
nes de Bitcoin sin ninguna relación con su identidad de la vida real, esto ha
provocado que distintas criptomonedas se utilicen como medios de pago para
actividades ilegales.
2.6. Seguridad y criptograf́ıa 23
A través de algunas plataformas de negociación de terceros que admiten
Bitcoin, los usuarios pueden comprar o vender cualquier producto. Dado que
el proceso es anónimo, es dif́ıcil rastrear el comportamiento de los usuarios y
mucho menos es posible sancionar actividades ilegales.
Fugas de Información en TransaccionesAunque no todas las aplicaciones lo requieren, uno de los principales beneficios
de las aplicaciones basadas en cadenas de bloques es la facilidad con la que se
puede brindar anonimato a los participantes. La transparencia y trazabilidad
presentes en estos sistemas provocan que sea indispensable tomar medidas pa-
ra garantizar la privacidad de las transacciones de cada usuario.
En el caso de las criptomonedas, Bitcoin y Zcash, usan cuentas únicas para
almacenar la criptomoneda recibida. Además, el usuario necesita asignar una
clave privada a cada transacción. De esta manera, el atacante no puede infe-
rir si la criptomoneda, en diferentes transacciones, es recibida por el mismo
usuario.
En el caso de un mercado de enerǵıa o cualquier otra aplicación donde
se requiere contar con los datos personales de los participantes, el riesgo de
exponer datos sensibles como direcciones, datos de consumo, correos de fac-
turación u otros, requiere que se tomen medidas para garantizar la seguridad
de la información de cada participante dentro de la cadena.
Vulnerabilidades de los contratos inteligentes
Como programas que se ejecutan de forma automática una vez que se cum-
plen una serie de condiciones predefinas entre los miembros de la cadena de
bloques, los contratos inteligentes pueden tener vulnerabilidades de seguridad
causadas por defectos del programa. Luu et al. (2016) desarrollaron una herra-
mienta para encontrar vulnerabilidades en contratos inteligentes de Ethereum
y encontraron 4 tipos de errores potenciales presentes en aplicaciones basadas
en cadenas de bloques (no sólo Ethereum): dependencia del orden en el que
se realizan las transacciones, dependencia de las marcas de tiempo en los blo-
ques, excepciones mal manejadas en el código de los contratos inteligentes, aśı
como vulnerabilidades de reentrada.
3 Plataformas
La arquitectura de BC ha sido revolucionaria en la última década, esto se ha
reflejado en el surgimiento de plataformas de BC que facilitan el desarrollo
de aplicaciones basadas en blockchain haciendo que el equipo de desarrollo se
concentre en otras partes técnicas de las aplicaciones. Lo que ha promovido
el uso de las plataformas más populares: Ethereum, HyperLedger y Energy
Web; por parte de múltiples iniciativas afines al sector eléctrico como los son
la generación distribuida, la movilidad eléctrica y los certificados verdes de
enerǵıa.
25
26 3 Plataformas
3.1 Plataformas más usadas en el sector enerǵıa
Ethereum
Ethereum (2021) consiste en una plataforma de Blockchain que posee su pro-
pia criptomoneta, el Ether. Sin embargo, a diferencia del Bitcoin y otras crip-
tomonedas, Ethereum cuenta con su propio lenguaje de programación para
contratos inteligentes llamado Solidity. Lo cual permite, a los usuarios de la
plataforma, crear sus propias aplicaciones y hacer uso de la red, para guardar
las transacciones de información utilizando el Ether como medio de pago.
Si bien, la versatilidad de esta plataforma ha incentivado el surgimiento de
múltiples iniciativas, en diversas áreas tecnológicas, que si bien una gran parte
todav́ıa se encuentran en etapas tempranas de exploración, existen aplicaciones
en áreas como finanzas, arte digital, video juegos y redes sociales, que han
adoptado Ethereum (2021) como parte de su infraestructura exitosamente.
Aplicaciones del sector energético basados en Ethereum
De acuerdo con Andoni et al. (2018), las siguientes son iniciativas en el sec-
tor eléctrico que adoptaron la infraestructura que provee blockchain usando
Ethereum como su plataforma principal.
• Distribución descentralizada de enerǵıa.
– Alva por parte de Alliander.
– Bitwatt.
– Cojule.
– CoSol.
– Divvi.
– Electrify.Asia.
– Energy Bazaar.
– Electron.
– Everty.
– Greeneum.
– Grid +.
– Hive Power.
– KEPCO.
– OneUp.
3.1. Plataformas más usadas en el sector enerǵıa 27
– Oursolargrid & ITP.
– Power Ledger.
– Slock.it.
– Vector Energy.
– Volts Markets.
• Movilidad eléctrica
– Charge Ledger por parte de Alliander.
– Oxygen Initiative.
– Power Ledger.
• Certificados verdes
– CarbonX.
– DAO IPCI (MITO).
– Power Ledger.
– Volts Markets.
– Veridium Labs.
HyperLedger
Similar que Ethereum, Gillis (2021) la describe como un conjunto de marcos
de trabajo, herramientas y bibliotecas con la finalidad de llevar a cabo imple-
mentaciones de Blockchain de nivel empresarial. Sin embargo, a diferencia de
Ethereum, que surge como una start-up iniciada por Vitalik Buterin, Hyper-
ledger es una comunidad de código abierto, tiene su origen como un proyecto
sombrilla, iniciado por The Linux Foundation y apoyado por gigantes de la
industria como Intel e IBM.
De acuerdo con Gillis (2021) y en conforme con las distintas aplicaciones
expuestas por Andoni et al. (2018), las dos plataformas de Hyperledger más
empleadas consisten en Hyperledger Fabric y Hyperledger Sawtooth.
Hyperledger (2021) define tanto a Fabric como a Sawtooth, como plata-
formas modulares para el desarrollo de aplicaciones basadas en BC, en donde
componentes como algoritmos de consenso y servicios de membreśıa, puedan
ser intercambiables. Sin embargo, según Hyperledger (2018), las principales
diferencias radican en que Fabric puede operar tanto como una red de consor-
cio o como una red privada, mientras que Sawtooth, únicamente puede operar
28 3 Plataformas
como una red de consorcio.
Por otra parte, sobre el algoritmo de consenso, Fabric permite al usuario
escoger entre varias opciones qué algoritmo utilizar; mientras que Sawtooth
únicamente permite el uso de prueba de tiempo transcurrido. Algunas de las
aplicaciones, en el sector eléctrico, definidas por Andoni et al. (2018), que
emplean Hyperledger, son mencionadas a continuación.
Aplicaciones del sector energético basados en Hyperledger
• Distribución descentralizada de enerǵıa.
– Tennet & Sonnen bajo Hyperledger Fabric.
– Tennet & Vandenbron bajo Hyperledger Fabric.
– Filament bajo Hyperledger Sawtooth.
• Movilidad eléctrica
– Car eWallet bajo Hyperledger Fabric.
• Certificados verdes
– Energy-Blockchain Lab & IBM bajo Hyperledger Fabric y Saw-
tooth.
EnergyWeb (EW)
Foundation (2021) se define a śı mismo, como una organización global sin fi-
nes de lucro; cuyo objetivo es acelerar el surgimiento de un sistema eléctrico
centrado en el cliente y con bajas emisiones de carbono, mediante el uso de
tecnoloǵıas de descentralización.
En 2019, EW lanzó Energy Web Chain, su plataforma BC (basada en
Ethereum) empresarial diseñada para el sector energético.
A partir del lanzamiento de Energy Web Chain, Energy Web se ha expan-
dido de gran manera, desarrollando el EW-DOS, que consiste en una serie de
aplicaciones y herramientas de desarrollo de software para facilitar la creación
de nuevas aplicaciones. A continuación, se presentan algunas de las aplicacio-
nes que utilizan Energy Web Chain como plataforma de BC, definidas por
Andoni et al. (2018).
3.1. Plataformas más usadas en el sector enerǵıa 29
Aplicaciones del sector energético basados en EnergyWeb
• Distribución descentralizada de enerǵıa.
– Electron.
– Green Running (Verv).
• Movilidad eléctrica.
– Slock.it
– Share&Charge.
• Certificados verdes.
– Grid Singularity
30 3 Plataformas
3.2 Implementaciones realizadas
La factibilidad de realizar un proyecto depende en gran parte de qué tan rápi-
damente se desarrolla; de manera que no se pierda la oportunidad de mercado.
Es por esto que es fundamental, la realización de pruebas de concepto. A conti-
nuación, se muestran las pruebas de concepto realizadas, para las plataformas
de BC.
Ethereum y EnergyWeb
Para la prueba de concepto, utilizando las plataformas BC de Ethereum y
EnergyWeb, se decide implementar la propuesta que inicialmente fue llevada
a cabo por Lasa (2021); la cual consiste en una aplicación web para la trans-
ferencia del token TFG Coin1; el cual, a su vez, está basado en el estándar
ERC20, propuesto por Fabian Vogelsteller(2019) para el intercambio entre
múltiples cuentas, utilizando la extensión de MetaMask como monedero. Para
el funcionamiento de la aplicación se usa Ganache, herramienta desarrollada
por Truffle (2021) para la generación de una cadena de bloques local basa-
da en Ethereum. Por otra parte, el mismo contrato también es desplegado la
red de prueba de EnergyWeb, Volta. En donde se realizan las mismas acciones.
A continuación, se muestran los resultados obtenidos, utilizando la prueba
de concepto.
Inicialmente, el contrato inteligente estipula que: la cuenta primaria posee
la totalidad de los tokens (21 millones de TFGC); mientras que, las cuentas
secundarias, se encuentran vaćıas.
• El primer paso, es registrar la cuenta primaria, en el monedero de Me-
tamask; pues esta es la que tiene la totalidad de tokens (ver Figura 3.1).
• Después de ingresar la clave privada en Metamask, se comprueba que la
cuenta inicial posee la totalidad de los tokens (Figura 3.2).
• Se verifica que una de las cuentas secundarias, a la cual se transferirán
TFGC, se encuentre vaćıa, según lo estipulado (ver Figura 3.2).
• Posteriormente, se realiza una transferencia, desde la cuenta primaria a
una de las cuentas secundarias (Figura 3.4).
1Para nuestro efecto, la abreviación TFGC hace referencia al nombre de la moneda
virtual utiliza en la prueba de concepto desarrollada; donde TFGC es Trabajo Final de
Graduación Coin
3.2. Implementaciones realizadas 31
Figura 3.1: Registro de cuenta primaria en MetaMask.
Figura 3.2: Cuenta primaria 0x5dB88a1286DC7D2E996461AFBdF3B7c91c0B5ec2
con la totalidad de los tokens.
32 3 Plataformas
Figura 3.3: Cuenta secundaria 0xC8dE9fD765a973B2C985d58c4AfF452d79F522fc,
vaćıa.
Figura 3.4: Transferencia de 10M TFGC hacia cuenta secundaria.
3.2. Implementaciones realizadas 33
• Una vez iniciada la transacción, es necesario confirmar la v́ıa MetaMask
(ver Figura 3.5).
Figura 3.5: Confirmación de transferencia.
• Posteriormente, se confirma que la cuenta secundaria haya recibido la
transacción (ver Figura 3.6).
• Finalmente, se confirma que la cuenta primaria haya efectuado la tran-
sacción (ver Figura 3.7).
34 3 Plataformas
Figura 3.6: Cuenta secundaria con 10M TFGC.
Figura 3.7: Cuenta primaria después de haber transferido los TFGC a la cuenta
secundaria.
3.2. Implementaciones realizadas 35
Hyperledger
Con la idea de tener un mejor entendimiento, sobre el funcionamiento de las
aplicaciones de BC, se busca utilizar los ejemplos disponibles en la documen-
tación de Hyperledger (2020).
A continuación, se detallan los pasos utilizados,
1. Descargar el repositorio con las imágenes y ejemplos de Hyperledger Fa-
bric.
1 curl -sSL https ://bit.ly/2 ysbOFE | bash -s -- 2.2.2
1.4.9
2. Navegar hasta el subdirectorio de la red de prueba y apagar cualquier
conexión existente, para correr la aplicación de prueba desde un ambiente
limpio.
1 cd fabric -samples/test -network
2 ./ network.sh down
3. Desplegar la red de pruebas.
1 ./ network.sh up createChannel -c mychannel -ca
4. Desplegar el equivalente al contrato inteligente en Hyperledger
1 ./ network.sh deployCC -ccn basic -ccp ../asset -transfer -
basic/chaincode -javascript/ -ccl javascript
5. Una vez desplegadas la red de pruebas se procede a ejecutar la aplicación
de ejemplo, para ello hay que navegar hasta el directorio de la aplicación
e instalar las dependencias.
1 cd asset -transfer -basic/application -javascript
2 npm install
6. Ejecución de la aplicación
1 node App.js
A continuación se describe el funcionamiento al correr la aplicación:
• Se agrega al administrador de la red de prueba:
36 3 Plataformas
1 /Users/sebastianblanco/Development/Blockchain/
hyperledger -fabric/fabric -samples/asset -
transfer -basic/application -javascript/wallet
2 Successfully enrolled admin user and imported it into the
wallet
• Se registra a un usuario de la aplicación:
1 Successfully registered and enrolled user appUser and
imported it into the wallet
• Se inicializa la red de pruebas con la siguiente información.
1 const assets = [
2 {
3 ID: ’asset1 ’,
4 Color: ’blue’,
5 Size: 5,
6 Owner: ’Tomoko ’,
7 AppraisedValue: 300,
8 },
9 {
10 ID: ’asset2 ’,
11 Color: ’red’,
12 Size: 5,
13 Owner: ’Brad’,
14 AppraisedValue: 400,
15 },
16 {
17 ID: ’asset3 ’,
18 Color: ’green’,
19 Size: 10,
20 Owner: ’Jin Soo’,
21 AppraisedValue: 500,
22 },
23 {
24 ID: ’asset4 ’,
25 Color: ’yellow ’,
26 Size: 10,
27 Owner: ’Max’,
28 AppraisedValue: 600,
29 },
30 {
31 ID: ’asset5 ’,
32 Color: ’black’,
33 Size: 15,
34 Owner: ’Adriana ’,
35 AppraisedValue: 700,
36 },
3.2. Implementaciones realizadas 37
37 {
38 ID: ’asset6 ’,
39 Color: ’white ’,
40 Size: 15,
41 Owner: ’Michel ’,
42 AppraisedValue: 800,
43 },
44 ];
• Se verifica que un elemento no exista en la red y se agrega a esta, en
este caso el elemento agregado es:
1 Result: {
2 "ID": "asset13",
3 "Color": "yellow",
4 "Size": "5",
5 "Owner": "Tom",
6 "AppraisedValue": "1300"
7 }
• Se actualiza el valor de uno de los elementos en la red:
1 Result: {
2 "ID": "asset1",
3 "Color": "blue",
4 "Size": "5",
5 "Owner": "Tom",
6 "AppraisedValue": "350"
7 }
38 3 Plataformas
3.3 Criterios de comparación
Para poder comparar las plataformas expuestas anteriormente es necesario
definir cuáles son los aspectos más importantes que pueden afectar la funcio-
nalidad de una aplicación durante su ciclo de vida. El Cuadro 3.1 reseña la
comparación de las plataformas de blockchain usadas en el sector enerǵıa.
Costos asociados
Quizá el factor más importante a la hora de empezar un proyecto nuevo ba-
sado en blockchain, es la viabilidad económica, para ello es importante tomar
los costos de mantener infraestructura, aśı como costos por transacciones son
fundamentales a la hora analizar el funcionamiento de un proyecto.
En lo que respecta a Ethereum, la mayor parte de los costos asociado se
ven reflejados en la implementación y mantenimiento de la aplicación como
tal, esto debido a que la infraestructura es mantenida gracias al monto que se
le cobra a los usuarios por cada transacción.
Por otra parte, tanto en Hyperledger como Energy Web, es necesario tomar
en cuenta que mantener las validaciones de las transacciones se suma a la
implementación y mantenimiento de la aplicación.
Escalabilidad
En general se puede describir la escalabilidad como la capacidad propia de un
sistema para adaptarse al aumento de determinadas condiciones en su medio,
tomando esto en cuenta BinanceAcademy (2021), define la escalabilidad de un
BC como la capacidad de incrementar el número de transacciones que pueden
gestionar. Debido a su naturaleza descentralizada, la escalabilidad del BC ha
representado un problema desde su incepción. Esto debido a que todos los
nodos deben mantenerse actualizados entre śı, lo cual no es tarea fácil.
En cuanto a Ethereum, el hecho de que su cadena principal todav́ıa funcio-
ne bajo el mecanismo de Proof of Work, hace que esta plataforma carezca de
escalabilidad, por lo que en momentos donde hay una cantidad considerable
de transacciones, se genere un cuello de botella para que estas sean validadas,
haciendo que el costo de la transacción aumente. Según Berkowitz (2021), para
solventar el problema de la escalabilidad Ethereum lleva planteándose desde
hace varios años su siguiente revisión, Ethereum2.0, en su caracteŕıstica más
importante será la implementación de Proof of Stake como método de consen-
3.3. Criterios de comparación 39
so.
Por su parte, tanto Hyperledger como Energy Web han sabido solventar
el problema de la escalabilidad, en el caso de Energy Web usando el consenso
de Proof of Authority y en el caso Hyperledger con diversos protocolos de
consenso distintos al Proof of Work.
Velocidad de transacciones
Por otra parte, la velocidad con la cual las plataformas registran las transac-
ciones dentro del BC es de suma importancia y debe ser capaz de ajustarsea
las necesidades de cada aplicación.
Como se mencionó anteriomente, la velocidad de las transacciones va de
la mano con la escalabilidad de la plataforma de BC, por lo que es de esperar
que tanto Hyperledger como Energy Web, cuenten con una mayor cantidad de
transacciones por segundo que Ethereum. Para ser más exactos, Iredale (2021)
menciona que Hyperledger logra procesar más de 2000 transacciones por se-
gundo, mientras que Ethereum soporta aproximadamente 20 transacciones por
segundo.
Facilidad de implementación
Por último, está la facilidad de implementación, en este caso este criterio es-
tará basado en las experiencias obtenidas al desarrollar pequeñas aplicaciones
basadas en BC.
Hay varios factores que pueden determinar la factibilidad de desarrollar
una plataforma, uno de ellos es la cantidad de información disponible en ĺı-
nea, y Ethereum se distingue por la cantidad recursos disponibles. La infor-
mación se logra encontrar con facilidad desde plataformas de cursos en ĺınea,
hasta blogs personales e incluso YouTube. Si bien también se puede encontrar
información sobre Hyperledger en los medios anteriormente mencionados, la
cantidad información es menor. En cuanto a EnergyWeb, dado que este usa
Solidity como lenguaje de programación en sus contratos, al igual que Ethe-
reum, la cantidad de información es abundante. Sin embargo, la cantidad de
recursos espećıficos sobre su plataforma son tan abundantes en comparación
con Ethereum y HyperLedger.
Otro aspecto importante es el de la infraestructura, si bien el hecho de que
Hyperledger tenga una infraestructura modular es una gran ventaja para su
escalabilidad, implica que quienes vayan a desarrollar la aplicación también
40 3 Plataformas
deben adquirir el conocimiento necesario sobre su infraestructura del BC, en
Ethereum, la mayoŕıa del enfoque radica en el desarrollo de la aplicación.
Por último, también es importante destacar que en Hyperledger, los con-
tratos inteligentes pueden ser implementados en distintos lenguajes de progra-
mación, como lo son, Go, JavaScript o Java, lenguajes populares de utilidad
general. Mientras que Ethereum usa Solidity, un lenguaje especialmente dise-
ñado para contratos inteligentes, lo cual requiere una curva aprendizaje extra.
Cuadro 3.1: Cuadro comparativo sobre las plataformas de Blockchain utiliza-
das en el sector enerǵıa
Criterio de comparación Ethereum Hyperledger EnergyWeb
Escalabilidad
Proof of Work
como algoritmo
de consenso.
Baja escalabilidad.
Múltiples algoritmos
de consenso.
Escalabilidad flexible.
Proof of Authority
como algoritmo
de consenso.
Alta escalabilidad.
Transacciones
por segundo
20 transacciones
por segundo.
>10000 transacciones
por segundo.
Mucho mayor a
Ethereum
Costos asociados Tarifa por transacción.
Mantenimiento de
infraestructura de BC.
Tarifas de transacción (dependiendo
de la implementación seleccionada)
Mantenimiento de
infraestructura
de BC y tarifas de transacción
Facilidad de
implementación
Posee la mayor
cantidad de
documentación
disponible.
Aprendizaje
de Solidity.
Alta cantidad de
documentación.
Requiere un mayor
entendimiento
sobre la estructura BC.
Uso de lenguajes
de programación
de uso general.
Poca cantidad de
documentación.
Información
desactualizada.
4 Marco Juŕıdico-Regulatorio
La seguridad juŕıdica es un elemento fundamental para el desarrollo de cual-
quier actividad, empresa o servicio. El reto que plantea cualquier tecnoloǵıa
que esté ingresando a un mercado es que la regulación debe crearse y adap-
tarse, conforme se van desarrollando nuevos avances. Finck (2018) menciona
la dificultad de regular actividades basadas en cadenas de bloques debido a
su complejidad, el estado inmaduro de la tecnoloǵıa, el enorme potencial que
posee y los efectos negativos que puede provocar un marco regulatorio inade-
cuado. La regulación puede ser un cuello de botella que evite la expansión y
limite el crecimiento de esta tecnoloǵıa en nuestro páıs.
4.1 Legislación nacional referente a temas de enerǵıa
eléctrica que pueden interferir en tecnoloǵıas de
Cadenas de Bloques
Para poder identificar cuales pueden ser las posibles limitaciones regulatorias,
para la implementaciones de aplicaciones basadas en BC para el sector enerǵıa,
debe tenerse claro cual es la legislación y normativa que regula el tema de la
enerǵıa eléctrica en Costa Rica. Según el conjunto de leyes actuales, existen
serias limitaciones, en la aplicación de servicios de enerǵıa basadas en BC;
a continuación, se describen las implicaciones, de las leyes que afectan los
servicios de enerǵıa y los negocios asociados:
Ley N◦7200 (1990) Generación Autónoma o Paralela
Esta ley regula la generación eléctrica de gran escala que no es proveniente del
ICE o de las empresas distribuidoras. En su art́ıculo 5, 7 y 20 (el enunciado de
cada art́ıculo se muestra en el cuadro 8.1, Sección 8.2) dicta las responsabili-
dades del Servicio Nacional de Electricidad (SNE)* (reformado bajo el nombre
de Autoridad Reguladora de Servicios Públicos (ARESEP) por el art́ıculo 2º
de la ley No.7508 del 9 de mayo de 1990) y del ICE en el proceso de compra
a generadores privados.
Esta ley es bajo las cuales se han creado plantas privadas de 20MW (Ley N◦
7200, cap I) y plantas privadas modelo build-operate-transfer (BOT) de 50MW
(Ley N◦ 7200, cap II). Esta ley limita al ICE a comprar enerǵıa de generadores
41
42 4 Marco Juŕıdico-Regulatorio
privados, sólo bajo estas modalidades; lo cual, generaŕıa un impedimento en
algunos modelos de negocio basados en BC, donde existe un mercado libre de
compra-venta.
Ley N◦7593 (1996) Autoridad Reguladora de los Servicios Públicos
(ARESEP)
La Autoridad Reguladora de los Servicios Públicos (ARESEP) es el ente re-
gulador de las tarifas de los servicios públicos en Costa Rica; sin embargo, su
rol es más complejo que simplemente asignar tarifas. Tal como se menciona
en el art́ıculo 5 de la ley N◦ 7593; en el cuadro 8.1, Sección 8.2, se muestra un
extracto de interés, en relación al enunciado de este art́ıculo.
Posteriormente, la ley 7593 define el rol del participante más importante en
el mercado de comercialización eléctrica, asignándole al ICE en el art́ıculo 22
la responsabilidad de ser el ente encargado de ”Suministro de enerǵıa eléctri-
ca en las etapas de generación, trasmisión, distribución y comercialización”;
el enunciado completo de este art́ıculo se muestra en el cuadro 8.1, Sección 8.2.
El art́ıculo 22 de la ley 7593 limitaŕıa por completo cualquier iniciativa de
aplicar servicios basados en BC, en el sector enerǵıa, que impliquen un cambio
en el modelo de negocio actual; sin embargo, el art́ıculo 13 de esta ley es bajo
el cual se ampara la intervención de las cooperativas de electrificación y las
empresas municipales, en el mercado de distribución eléctrica. Este art́ıculo
permitiŕıa la introducción de nuevos modelos de negocio, sin necesidad de
cambiar esta ley, siempre y cuando se justifique su beneficio. El enunciado
completo de los art́ıculos 22 y 13 de esta ley, se muestran en el cuadro 8.1,
Sección 8.2.
Ley N◦8345 (2003) Participación de las Cooperativas de Electrificación
Rural y de las Empresas de Servicios Públicos Municipales en el Desarrollo
Nacional
Esta ley regula la operación y el alcance de las Cooperativas de Electrificación
Rural y de las Empresas de Servicios Públicos Municipales, en el mercado
eléctrico, como se detalla en su primer art́ıculo (el enunciado de este art́ıculo
se muestra en el cuadro 8.1, Sección 8.2).
La venta de enerǵıa a los usuarios finales, se abre como una actividad en el
que el ICE no tiene monopolio sino que incorpora a las cooperativas y empre-
sas municipales, en el negocio de distribución; según se menciona en el art́ıculo
6 de esta ley (el enunciado de este art́ıculo se muestra en el cuadro 8.1, Sección
4.1. Legislación nacional referente a temas de enerǵıa eléctrica que puedeninterferir en tecnoloǵıas de Cadenas de Bloques 43
8.2).
Las cooperativas y empresas municipales, pueden generar electricidad para
consumo propio, dentro de sus redes de distribución, o comprar enerǵıa al ICE;
según se describe en el art́ıculo 9 de esta ley (el enunciado de este art́ıculo se
muestra en el cuadro 8.1, Sección 8.2).
Bajo la legislación actual, las cooperativas y empresas municipales, sólo
le pueden vender a los usuarios y comprarle enerǵıa al ICE, mientras que el
ICE sólo puede vender a las empresas distribuidoras y los usuarios finales, y
comprar sólo a generadores privados (y el intercambio de enerǵıa en el Sistema
de Interconexión Eléctrica para Páıses de América Central (SIEPAC)).
Distintas aplicaciones de BC necesitaŕıan habilitar nuevas direcciones de
venta de enerǵıa, no contempladas actualmente (usuario-distribuidor, distribuidor-
ICE); para ser completamente viables.
Decreto Ejecutivo N◦39220-MINAE (2015) Reglamento generación
distribuida para autoconsumo con fuentes renovables modelo de
contratación medición neta sencilla
En la Sección 8.2, en el cuadro 8.1, se adjunta el art́ıculo 44 de este regla-
mento; dicho art́ıculo regula la generación distribuida para autoconsumo; no
obstante, no contempla la venta de esa enerǵıa al sistema o a otros usuarios.
Las empresas distribuidoras le generan un ’saldo positivo’ a los prosumi-
dores que entregan más de lo que generan a la red eléctrica. Sin embargo,
no todos los usuarios pueden ser prosumidores, debido a que existen limita-
ciones en los circuitos de distribución en los que se puede instalar generación
distribuida.
Ley N◦10086 (2022) Promoción y regulación de recursos energéticos
distribuidos a partir de fuentes renovables
La Ley N◦10086 (2022) es una evolución del Decreto Ejecutivo N◦39220-
MINAE (2015) mencionado anteriormente. No sólo se abre la posibilidad de
la generación distribuida sino que permite una serie de alternativas más am-
plias: entrega de excedentes a la red, operación en isla, operación sin entrega
de excedentes a la red, almacenamiento, servicios auxiliares, entre otros.
La importancia de la ley es la legitimación de nuevos modelos de opera-
ción, estructuras de remuneración y pliegos tarifarios. La legislación integra
44 4 Marco Juŕıdico-Regulatorio
a los actores involucrados en el sector enerǵıa como ARESEP, MINAE y las
empresas distribuidoras para que definan los aspectos tarifarios, ambientales,
técnicos y económicos asociados a la nueva gama de servicios posibles. Esto
permite considerar las tecnoloǵıas basadas en cadenas de bloques como una
herramienta más a considerar para aportar soluciones técnicas.
4.2 Tendencias internacionales en regulación de Cadenas
de Bloque
A nivel internacional no existen aún estándares en todos los términos o con-
ceptos generales que describen la tecnoloǵıa, por lo tanto, a continuación se
presentan algunos elementos, conceptos, términos o información regulatoria
que se están implementando como referencias en el campo de las cadenas de
bloques:
Objetivos de la Regulación
Borg y Schembri (2019) exponen que si bien es innegable las regulaciones
están respaldadas por buenas intenciones, la realidad es que muchas directivas
y regulaciones son malas para los negocios: paralizan a las nuevas empresas y
limitan la innovación. Es importante lograr el equilibrio correcto y mantener
el enfoque en los objetivos regulatorios. Este último siempre debe constituir
la base de cualquier regulación. Por lo tanto, se plantea que los objetivos
regulatorios, en la base de cualquier forma de blockchain, deben ser:
1. La creación de estándares que permitan la interoperabilidad y protejan
a los usuarios finales;
2. Garantizar la protección de las personas vulnerables y protegerlas de los
delincuentes; y
3. Garantizar una buena gobernanza para proteger a los inversores y a los
usuarios finales del fraude, mala gestión y negligencia grave.
La naturaleza de código abierto de la mayoŕıa de los proyectos de cade-
nas de bloques está en śı misma logrando el objetivo de interoperabilidad. Sin
embargo, el término clave entre los objetivos regulatorios debe de ser ’protec-
ción’. Hay una ĺınea fina para los gobiernos y los reguladores entre proteger, y
sobre regular. Borg y Schembri (2019) propone que la mejor solución para la
protección es garantizar transparencia y proporcionar la información necesaria
para que cada persona tome su propia decisión.
4.2. Tendencias internacionales en regulación de Cadenas de Bloque 45
Clasificación de Cadenas de Bloques según su elemento de transacción
Debido a que no existe una definición clara de ”moneda virtual” y no hay
jurisprudencia asociada, la autoridad supervisora del mercado financiero suizo
(FINMA), en sus pautas sobre ofertas iniciales de monedas (ICO) Swiss Fi-
nancial Market Supervisory Authority (FINMA) (2018), definió tres categoŕıas
básicas de criptodivisas o tokens con distinto status:
• Tokens como medio de pago (moneda virtual pura): Los tokens de pa-
go (sinónimo de criptomonedas) son tokens que están destinados a ser
utilizados, ahora o en el futuro, como un medio de pago para adquirir
bienes o servicios o como un medio de transferencia de dinero o valor.
Las criptomonedas no generan reclamos sobre su emisor.
• Tokens como ’Utility ’: Los tokens de utilidad son tokens que están des-
tinados a proporcionar acceso digital a una aplicación o servicio a través
de una infraestructura basada en blockchain.
• Tokens como bienes: las fichas de activos representan activos como un
reclamo de deuda o capital sobre el emisor. Los tokens de activos ga-
rantizan, por ejemplo, una participación en las ganancias futuras de las
empresas o de capitales futuros. En términos de su función económica,
por lo tanto, estos tokens son análogos a las acciones, bonos o derivados.
Los tokens que permiten el intercambio de activos f́ısicos en la cadena
de bloques también entran en esta categoŕıa.
Las clasificaciones de tokens no son mutuamente excluyentes. Los tokens
de activos y utilidades también se pueden clasificar como tokens de pago (de-
nominados tokens h́ıbridos). En estos casos, los requisitos son acumulativos;
en otras palabras, los tokens se consideran valores y medios de pago al mismo
tiempo.
Estilos de marcos regulatorios
Los páıses pueden tomar distintos enfoques para regular las tecnoloǵıas basa-
das en cadenas de bloques. Desde una libertad completa hasta una regulación
estricta de uso espećıfico. En el caso del sector enerǵıa se debe comprender que
la cadena de bloques no busca producir ’monedas’ sino simplemente conectar
al usuario con el proveedor del servicio, en esta relación puede (o no) mediar
un pago, que puede realizarse tanto dentro como fuera de la aplicación de BC.
Finck (2018) propone 4 enfoques principales para los marcos regulatorios:
1. Esperar y Observar: Un posible enfoque para los reguladores es esperar y
ver cómo se desarrolla la tecnoloǵıa mientras continúa aplicando los mar-
cos legales existentes. Bajo este modelo se le permite el desarrollo antes
46 4 Marco Juŕıdico-Regulatorio
de que se diseñen pautas y reglas concretas. Esto parece ser la corrien-
te principal del enfoque regulatorio en este momento, ya que permite a
los reguladores observar cómo las cadenas de bloques se desarrollan sin
la necesidad de hacer compromisos. Este enfoque ha sido ampliamente
adoptado en el contexto del rápido cambio tecnológico asociado al BC.
Es importante enfatizar qué: Esperar y Observar, no implican pasivi-
dad. Si bien no se emite una nueva regulación y los antiguos principios
legales continúan aplicando, el regulador debe reunir información acti-
vamente y en paralelo adquirir conocimiento a través de experiencias
internacionales, consultoŕıas y criterio experto, mientras también evalúa
sus propios desarrollos. El proceso de recolección de información puede
posteriormente dar paso a diferentes