MECANISMO DE CONSENSO PROOF-OF-
REPUTATION PARA SISTEMAS DE
BLOCKCHAIN
PROOF-OF-REPUTATION CONSENSUS
MECHANISM FOR BLOCKCHAIN SYSTEMS
TRABAJO FIN DE GRADO
CURSO 2022-2023
AUTOR
DANIEL LÓPEZ MARQUÉS
DIRECTOR
JESÚS CORREAS FERNÁNDEZ
GRADO EN INGENIERÍA INFORMÁTICA
FACULTAD DE INFORMÁTICA
UNIVERSIDAD COMPLUTENSE DE MADRID
MECANISMO DE CONSENSO PROOF-OF-
REPUTATION PARA SISTEMAS DE
BLOCKCHAIN
PROOF-OF-REPUTATION CONSENSUS
MECHANISM FOR BLOCKCHAIN SYSTEMS
TRABAJO DE FIN DE GRADO EN INGENIERÍA INFORMÁTICA
AUTOR
DANIEL LÓPEZ MARQUÉS
DIRECTOR
JESÚS CORREAS FERNÁNDEZ
CONVOCATORIA: FEBRERO/JUNIO/SEPTIEMBRE 2023
GRADO EN INGENIERÍA INFORMÁTICA
FACULTAD DE INFORMÁTICA
UNIVERSIDAD COMPLUTENSE DE MADRID
05 DE JUNIO DE 2023
III
RESUMEN
Blockchain es una ecnología de egis os dis ibuida y descen alizada que
pe mi e la c eación de egis os públicos e inmu ables de ansacciones y da os, sin
necesidad de in e media ios, almacenándolos en “bloques” que o man una cadena
que es á asegu ada median e écnicas c ip og á icas. Es descen alizada po que se
basa en la idea de que odos los nodos de la ed ienen una copia de la cadena de
bloques comple a. Todos los nodos e i ican los bloques que se an añadiendo a la
cadena. Pa a p oduci es os bloques, odos los nodos deben llega a un acue do pa a
decidi cuál de ellos p oduce el siguien e bloque. Es e p ocedimien o es lo que se
conoce como “mecanismo de consenso”. En la ac ualidad hay a ios mecanismos de
consenso, los más popula es son P oo o Wo k (Bi coin), P oo o S ake (E he eum) y
P oo o Au ho i y ( edes p i adas).
Exis en di e sos a ículos académicos que hablan sob e un mecanismo
al e na i o llamado “P oo o Repu a ion”, que se basa ía en la epu ación de los
di e en es nodos en la ed pa a ealiza la selección de alidado es de bloques.
El obje i o de es e T abajo de Fin de G ado es diseña e implemen a un
mecanismo de consenso basado en epu ación pa iendo de una implemen ación de
E he eum ya exis en e.
Palab as cla e
Blockchain, Mecanismos de consenso, Sis emas de epu ación, E he eum,
Hype ledge Besu, Mecanismo de consenso Clique

V
ABSTRACT
PROOF-OF-REPUTATION CONSENSUS MECHANISM FOR BLOCKCHAIN SYSTEMS
Blockchain is a dis ibu ed and decen alized eco d-keeping echnology ha
allows he c ea ion o public and immu able eco ds o ansac ions and da a, wi hou
he need o in e media ies, by s o ing hem in "blocks" ha o m a chain ha is secu ed
by c yp og aphic echniques. I is decen alized because i is based on he idea ha all
nodes in he ne wo k ha e a copy o he comple e blockchain. All nodes e i y he blocks
ha a e added o he chain. To p oduce hese blocks, all nodes mus each an
ag eemen o decide which o hem p oduces he nex block. This p ocedu e is known
as a "consensus mechanism". The e a e cu en ly se e al consensus mechanisms, he
mos popula being P oo o Wo k (Bi coin), P oo o S ake (E he eum) and P oo o
Au ho i y (p i a e ne wo ks).
The e a e se e al academic a icles ha alk abou an al e na i e mechanism
called "P oo o Repu a ion", which would be based on he epu a ion o he di e en
nodes in he ne wo k o make he selec ion o block alida o s.
The aim o his hesis is o design and implemen a epu a ion-based consensus
mechanism based on an exis ing E he eum implemen a ion.
Keywo ds
Blockchain, Consensus Mechanisms, Repu a ion Sys ems, E he eum, Hype ledge
Besu, Clique Consensus Mechanism
VI
VII
ÍNDICE DE CONTENIDOS
Capí ulo 1 - In oducción ........................................................................................................ 1
1.1 An eceden es ................................................................................................................ 1
1.2 Obje i os ......................................................................................................................... 2
1.3 Plan de abajo .............................................................................................................. 3
Capí ulo 2 - In oducción a la ecnología Blockchain ......................................................... 5
Capí ulo 3 - Es ado del a e .................................................................................................... 9
3.1 Mecanismos de consenso ............................................................................................ 9
3.2 In oducción a los sis emas de epu ación.................................................................12
Capí ulo 4 - A qui ec u a de Hype ledge Besu ..................................................................17
Capí ulo 5 - Diseño del p o o ipo ..........................................................................................23
5.1 Esquema gene al ..........................................................................................................23
5.2 A qui ec u a del p o o ipo ...........................................................................................25
5.3 Esquema de epu ación u ilizado ...............................................................................26
5.4 Mecanismo de consenso basado en epu ación .....................................................29
Capí ulo 6 - Implemen ación ................................................................................................33
6.1 In aes uc u a y he amien as u ilizadas ....................................................................33
6.2 Componen es más ele an es ....................................................................................34
6.2.1 Implemen ación del mecanismo de consenso basado en un Sma Con ac
..........................................................................................................................................34
6.2.2 Implemen ación del nue o mecanismo de consenso en el clien e Hype ledge
Besu ..................................................................................................................................41
6.3 Implemen ación del sis ema de o ación .................................................................47
6.4 Ins alación de Hype ledge Besu.................................................................................50
VIII
Capí ulo 7 - E aluación y compa a i a ...............................................................................55
7.1 Escalabilidad .................................................................................................................55
7.2 Segu idad ......................................................................................................................57
7.3 Compa a i a .................................................................................................................59
Capí ulo 8 - Conclusiones y abajo u u o ...........................................................................63
In oduc ion .............................................................................................................................67
Conclusions and u u e wo k .................................................................................................71

5
Capí ulo 2 - In oducción a la ecnología Blockchain
En es e capí ulo se incluye una b e e in oducción a los concep os más
impo an es de la ecnología blockchain y la cadena de bloques.
Blockchain es una ecnología de egis o dis ibuido que pe mi e la c eación de
un egis o público y segu o de ansacciones y da os, sin necesidad de in e media ios.
Las ansacciones y los da os se almacenan en bloques que an o mando una
cadena denominada blockchain (1) Es a ecnología se ha popula izado en los úl imos
años g acias a sus ca ac e ís icas, que apo an anspa encia, segu idad y
descen alización a di e sas indus ias.
La p incipal ca ac e ís ica de Blockchain es la inmu abilidad de los da os
almacenados en sus bloques, g acias al uso de unciones de hash c ip og á icas. Cada
bloque con iene una e e encia al bloque an e io a a és de un hash c ip og á ico,
que es una ep esen ación única y i mada digi almen e de los da os con enidos en el
bloque, como se mues a en la igu a 2-1. Si se ealiza a cualquie cambio en los da os
de uno de los bloques, el hash gene ado ambién cambia ía, y po lo an o la
e e encia almacenada en el siguien e bloque no coincidi ía, y se in alida ía la
cadena.
G acias a es a ca ac e ís ica, cualquie in en o audulen o de modi ica un
bloque ya exis en e en la cadena se ía de ec ado ácilmen e, po que el hash del
bloque al e ado no coincidi ía con el hash almacenado en el siguien e bloque. Es a
ca ac e ís ica de inmu abilidad ga an iza la in eg idad de los da os almacenados en
la blockchain y es la base de la con ianza de odos los pa icipan es de la ed.
Figu a 2-1 Rep esen ación g á ica de la cadena de bloques. Fuen e: E he eum Whi epape (2)
6
Además de la inmu abilidad de los da os ya almacenados en la cadena de
bloques, exis e o a capa de segu idad que consis e en la i ma c ip og á ica de las
ansacciones. En cada ansacción que se ealiza en la blockchain, los emiso es
u ilizan cla es c ip og á icas asimé icas pa a i ma digi almen e la ansacción. Po lo
an o, cada ansacción es á asociada a una cla e pública única y su
co espondien e cla e p i ada, de o ma que solo el i ula de es a puede gene a una
i ma álida. La i ma c ip og á ica de las ansacciones asegu a que no se pueda
suplan a al emiso ni al e a las una ez que se han emi ido y, po lo an o, ga an iza la
au en icidad de los da os en la cadena de bloques. (2) (3)
La cadena de bloques que almacena da os es compa ida po cada uno de
los nodos de la ed, es deci , cada nodo que se conec e a la blockchain end á una
copia de la cadena comple a en su equipo local, y cada ez que un nue o bloque es
añadido po un nodo especial (un “mine o”, o “ alidado ”), se edis ibuye al es o de
los nodos de la ed pa a que odos comple en su copia de la cadena de bloques.
De es a o ma, es ácil de ec a si ha habido alguna manipulación en los da os
an e io es de la cadena, pues odos los nodos ienen una copia.
Pa a asegu a la segu idad e in eg idad de las edes blockchain, se u ilizan los
llamados mecanismo de consenso, que son p ocedimien os que si en pa a que odos
Figu a 2-2 Rep esen ación g á ica de la i ma de ansacciones en la
blockchain. Fuen e: Bi coin Whi epape (3)
7
los nodos de la ed se pongan de acue do pa a c ea nue os bloques y alida los
ac uales, sin necesidad de ningún e ce o (descen alización).
El p ime mecanismo de consenso, y más conocido, ue P oo o Wo k (P ueba de
T abajo), ac ualmen e u ilizado po Bi coin y edes mino i a ias. O o mecanismo popula
es P oo o S ake (P ueba de Pa icipación), que la u iliza E he eum, la segunda
blockchain más conocida. Y el e ce mecanismo más conocido, aunque es e se u iliza
mayo i a iamen e en edes p i adas, es P oo o Au ho i y (P ueba de Au o idad).
8
9
Capí ulo 3 - Es ado del a e
Es e capí ulo se compone de dos secciones p incipales. P ime o se in oduce la
noción de mecanismo de consenso en los sis emas de blockchain y se desc iben los
sis emas más ele an es. A con inuación, en la sección 3.2, se in oducen los aspec os
más impo an es de las p opues as exis en es de sis emas de epu ación u ilizados en
mecanismos de consenso de sis emas de blockchain.
3.1 Mecanismos de consenso
Como se ha in oducido en el apa ado an e io , Blockchain unciona median e
di e en es mecanismos de consenso, que se basan en llega a un consenso en e odos
los nodos de la ed pa a p oduci un nue o bloque, y añadi lo a la cadena de bloques.
Llega a un consenso signi ica que al menos el 66% de los nodos de la ed coinciden en
el siguien e es ado gene al de la ed (9).
Es impo an e des aca que es os mecanismos de consenso son undamen ales
pa a las edes Blockchain, po se sis emas descen alizados y dis ibuidos en las que no
exis e un nodo cen al o se ido que enga el con ol de la in o mación y las decisiones
de la ed. Los mecanismos de consenso pe mi en a es os sis emas colabo a en e los
di e en es nodos y man ene se segu os. (9)
En edes descen alizadas odos los nodos ienen el mismo peso e impo ancia
pa a la oma de decisiones, po lo an o, odos ellos deben pone se de acue do sob e
el es ado ac ual y las modi icaciones de la cadena de bloques, y, si un nodo ac úa de
o ma maliciosa se ía ácilmen e de ec ado po los demás y se ía expulsado. Si no
exis iese un mecanismo de consenso pa a ga an iza es o, cada nodo pod ía oma
decisiones p opias, posiblemen e maliciosas, y modi ica la in o mación almacenada en
la cadena de bloques, causando g a es p oblemas de segu idad e in eg idad en la ed.
Se plan eó inicialmen e el uso de “algo i mos” de consenso ole an es a allos
bizan inos (P oblema de los gene ales bizan inos (10)), algo i mos muy complejos. Sin
emba go, inalmen e se desca a on y se c ea on los ac uales mecanismos de
consenso.

10
Si bien los mecanismos de consenso son impo an es pa a e i a ulne abilidades
en los sis emas blockchain (po ejemplo, oma de decisiones unila e ales po pa e de
algún nodo), ambién pueden ocasiona p oblemas de segu idad en edes mino i a ias,
en las que hay pocos nodos. Es e es el caso del a aque del 51%, que puede ene luga
si un g upo de nodos malin encionados llegan a con ola más del 50% de los nodos de
la ed, y les pe mi i ía con ola la cadena y ealiza ansacciones audulen as. Es e ipo
de a aques han ocu idos en edes eales, como en la blockchain de Bi coin Gold en
2018 (11). Sin emba go, las edes mayo i a ias como Bi coin o E he eum no han su ido
a aques de es e ipo que hayan enido éxi o, ya que la magni ud de es as hace casi
imposible que se llegue a con ola el 51% de la ed.
Es os mecanismos de consenso e i an de e minadas ulne abilidades en es e ipo
de sis emas, ya que ga an izan que odos los nodos es án de acue do, y si un nodo
ac úa de o ma maliciosa se ía ácilmen e de ec ado po los demás y se ía expulsado.
En el caso de Bi coin, se u iliza P oo o Wo k. En es e mecanismo de consenso,
cada nodo de la ed debe p oba que ha in e ido ecu sos compu acionales pa a
p oduci el siguien e bloque de la cadena. Los nodos que ealizan es e abajo, ambién
llamado “minado”, se conocen como “mine os” (12). Pa a ealiza el minado, los mine os
deben esol e un algo i mo ma emá ico complejo, que consis e en encon a un alo
de nonce (se explica á a con inuación) pa a el cual el hash del bloque es más pequeño
que un alo especí ico. El nonce de un bloque es un núme o con enido den o del
mismo, que po su nomb e en inglés “nonce” signi ica “núme o usado solo una ez”. El
p ime o en esol e lo añadi á el bloque a la cadena y ecibi á una ecompensa. Como
puede habe más de un bloque que se p oduzca simul áneamen e, se puede p oduci
ami icaciones de la cadena. Pa a decidi cuál es la ama álida, es e mecanismo de
consenso de e mina que la subcadena más la ga es la seleccionada, ya que es la que
mayo es ecu sos ha u ilizado. ( e igu a 3-1)
11
Es e mecanismo ha sido ampliamen e c i icado po sus p oblemas
medioambien ales de consumo de ene gía excesi o, ya que la única o ma de esol e
el algo i mo es median e p ueba y e o . Se es ima que Bi coin consume más ene gía
que el país No uega en e o, un o al del 0.65% del consumo mundial de ene gía. (13)
A aíz de esa polémica, empeza on a su gi o os mecanismos de consenso, como
es el caso de P oo o S ake, ecien emen e inco po ado a E he eum, la segunda
c ip omoneda más popula . Es e mecanismo desecha la idea de esol e algo i mos
ma emá icos y o o ga la posibilidad de p oduci un bloque a un nodo en unción de la
can idad de dine o que haya apo ado como ianza (s ake) pa a la alidación de
bloques y ambién un ac o de alea o iedad. De es a o ma se esuel e el p oblema
medioambien al, ya que es e mecanismo de consenso iene un consumo de ene gía
ín imo.
También exis en o os mecanismos de consenso mino i a ios u ilizados, sob e odo,
en edes p i adas, como P oo O Au ho i y, que equie e que los nodos sean alidados
po en idades eales de con ianza pa a pode se elegidos alidado es de bloques.
Pa a el desa ollo de es e abajo se ha pa ido de Hype ledge Besu y de su
mecanismo de consenso Cliqué, habiendo enido en cuen a pa a es a decisión su
sencillez y documen ación en la página web de Hype ledge Besu. En la sección 4 se
indica án las azones po las que se ha elegido es a implemen ación.
Hype ledge Besu es un so wa e open-sou ce que pe mi e a un nodo o ma
pa e de una ed con ecnología E he eum. Exis en múl iples edes de blockchain que
Figu a 3-1 Rami icaciones de una cadena de Bi coin. Fuen e: (23)
12
u ilizan la ecnología E he eum, de las que des aca la mainne de E he eum, que es la
ed pública que sopo a la c ip omoneda E he , así como muchas o as monedas
basadas en okens que se ejecu an como con a os den o de es a ed. Además,
Hype ledge Besu se puede u iliza pa a c ea edes p i adas basadas en es a misma
ecnología u ilizando uno o a ios nodos que se comunican en e sí. Los mecanismos de
consenso que sopo a po de ec o, y que son seleccionables pa a c ea una ed
p i ada, son Cliqué, QBFT, e IBFT 2.0 (basados en P oo o Au ho i y), P oo o S ake, y
E ash (P oo o Wo k).
3.2 In oducción a los sis emas de epu ación
Casi desde el inicio de los sis emas de blockchain, se han plan eado p opues as
an o académicas como indus iales ela i as a nue os mecanismos de consenso, que
pe mi iesen ga an iza que los nodos elegidos como alidado es uesen iables y que
ambién la selección de es os uese jus a y anspa en e. Es e es el caso de los sis emas
basados en epu ación.
En pa icula , los mecanismos de consenso basados en sis emas de epu ación
han sido p opues os en a ias con ibuciones académicas. En e ellos, en es a sección
amos a analiza las p opues as publicadas po Aluko y Kolonin (4), Do e al. (5) y Zhuang
e al. (6). En el whi epape de E he eum en 2014 (2) ya se mencionaba ambién la
posibilidad de añadi sis emas de epu ación de o ma sencilla, u ilizando Sma
Con ac s.
Es os sis emas se basan en las epu aciones de los di e en es nodos de la ed
como ac o de selección pa a se elegidos como nue os alidado es o p oduc o es de
bloques, y plan ean di e en es sis emas de o ación. Sin emba go, La o ma de calcula
dicha epu ación y su uso a ía según el en oque, así como el sis ema de o ación.
En el a ículo de Zhuang e al. (6), el nodo con mayo epu ación de la ed es el
que p oduce un bloque, y el 20% de los nodos con mayo epu ación o an po ese
bloque pa a alida que es co ec o y añadi lo a la ed.
Pa a el cálculo de la epu ación u iliza es ac o es, como se mues a en la igu a
3-2: la an igüedad de su dine o, es deci , cuán o iempo lle a su dine o en la ca e a del
nodo; la ac i idad social del nodo, es deci , la can idad de ansacciones que ha
13
ealizado; y la con ibución al mecanismo de consenso, es deci , si ha sido alidado ,
cuan os bloques ha p oducido en o al.
El sis ema de o ación en es e caso solo es u ilizado pa a alida los bloques que
se an a p oduci , pe o no pa a selecciona el nodo con mayo epu ación.
Figu a 3-2 Esquema de epu ación desc i o en el a ículo de Zhuang e al. (6)
En el a ículo de Do e al. (5), la epu ación se calcula ambién en base a es
ac o es, como se mues a en la igu a 3-3: El s ake powe , es deci , la can idad de dine o
en s ake; el uso de ecu sos del nodo, es deci , la can idad de ecu sos (CPU, RAM,
banda ancha) que u iliza; y la can idad de ansacciones de la cuen a, es deci , a
mayo can idad de ansacciones enga ese nodo, an o de en ada como de salida,
mayo se á es e ac o .
Sin emba go, es e a ículo plan ea un Delega ed P oo o Repu a ion, basado en
Delega ed P oo o S ake, que es una modi icación del PoS básico, que se basa en o a
a un g upo de nodos que se enca guen de ela po el co ec o uncionamien o del
mecanismo de consenso, y en e ellos se selecciona alea o iamen e el p oduc o de
bloque en cada onda.
Es po es o po lo que en es e a ículo el sis ema de o ación es di e en e al
a ículo de Zhuang e al. (6), an o en o ma como en p opósi o. Es di e en e en o ma,
20
Además, Hype ledge Besu u iliza un sis ema de hilos concu en es, de o ma que,
cuando se comienza a mina un bloque, se c ea un h ead nue o, y es e no e mina
has a que, o bien ha minado el bloque, o bien se ha echazado po no se su u no.
Pasados 15 segundos ( iempo en e bloques, con igu able en el bloque génesis,
mencionado an e io men e) un nue o hilo despie a y comienza a in en a mina un
bloque.
En segundo plano se encuen an o os hilos que se enca gan de impo a los
bloques que se eciben de o os nodos, es deci , cuando un nodo p oduce un bloque
hay un hilo en el es o de los nodos que se enca ga de impo a ese bloque que se
acaba de p oduci y añadi lo a la cadena local de cada bloque, p e iamen e
haciendo una se ie de alidaciones pa a comp oba que ese bloque se ha alidado y
p oducido co ec amen e y no es malicioso.
Figu a 4-3 Con enido de un iche o de c eación de bloque génesis en Hype ledge Besu

21
En la igu a 4-4 se mues a en un diag ama los di e en es componen es de la
a qui ec u a de Hype ledge Besu. El componen e “Consensus” que es á en el cen o a
la de echa ep esen a la ca pe a consensus, con los di e en es mecanismos de
consenso disponibles en Hype ledge Besu po de ec o.
Figu a 4-4 A qui ec u a de Hype ledge Besu. Fuen e: (24)
22
23
Capí ulo 5 - Diseño del p o o ipo
Es e capí ulo es á di idido en es secciones. P ime o se a a desc ibi el esquema
gene al que se ha elegido pa a diseña el p o o ipo. A con inuación, se desc ibi á la
a qui ec u a que se ha diseñado, y po úl imo se desc ibi á el esquema de epu ación
elegido, es deci , qué ac o es se han decidido u iliza pa a el cálculo del alo de
epu ación de cada nodo, en base a las ideas ecopiladas de di e en es a ículos
académicos.
5.1 Esquema gene al
La idea que se plan eó al inicio del p oyec o pa a implemen a un mecanismo
de consenso basado en epu ación pa a Hype ledge Besu consis ía en u iliza como
pun o de pa ida uno de los mecanismos de consenso exis en es en la dis ibución de
Besu (en pa icula el mecanismo Clique) y c ea sob e es a es uc u a base el nue o
mecanismo implemen ado di ec amen e en Ja a y compila lo jun o con el es o de
Hype ledge Besu. El incon enien e p incipal de es e plan eamien o es que es di ícil
ac ualiza las ca ac e ís icas del sis ema de epu ación.
Po es e mo i o, inalmen e se decidió es udia la posibilidad de implemen a el
mecanismo de consenso median e un Sma Con ac que es á ins alado en la p opia
blockchain. Es e en oque p opo ciona una se ie de en ajas:
- Segu idad: El código ejecu able del mecanismo de consenso es á ins alado en
la p opia ed de blockchain, de o ma que la p opia blockchain ga an iza que no se ha
suplan ado el código de o ma audulen a, po ejemplo, a acando algunos nodos de
la ed.
- T anspa encia: El código ejecu able del mecanismo de consenso es á
disponible pa a cualquie a, que lo puede es udia y analiza . Además, cualquie usua io
de la ed de blockchain puede ejecu a algunas unciones del con a o pa a consul a
in o mación ace ca del mecanismo de consenso, como el siguien e alidado , la
epu ación ac ual de cada nodo, e c.
24
- T azabilidad: Una de las ca ac e ís icas más ele an es de la ecnología
Blockchain es que egis a odas las ope aciones ( ansacciones) ealizadas sob e la ed.
Si el sis ema de epu ación del mecanismo de consenso es á implemen ado en un
con a o, es posible ecupe a odas las acciones ealizadas po el mecanismo de
consenso.
- Posibilidad de ac ualización: Aunque los con a os ins alados en un sis ema de
blockchain son inmu ables y no se pueden ac ualiza , se puede implemen a un
mecanismo basado en un con a o p oxy que pe mi a ac ualiza ácilmen e el código
del con a o con el sis ema de epu ación. De es a o ma, sin necesidad de eins ala los
clien es Hype ledge Besu, se puede ac ualiza el mecanismo de epu ación con
cambios que a ec en no solo a la pa ame ización del sis ema, sino ambién a
modi icaciones más impo an es que supongan cambios en el código ejecu able que
implemen a el sis ema de epu ación (siemp e que se man enga el mismo in e az
público del con a o). Es e aspec o es especialmen e in e esan e pa a mejo as del
sis ema o co ección de e o es, aunque el diseño del sis ema debe o ece un ni el de
segu idad muy ele ado debido al eno me iesgo que supone una ac ualización
indebida del sis ema de epu ación.
A es e mecanismo de consenso basado en sis emas de epu ación e
implemen ado median e un con a o in eligen e se ha decidido llama le “Repu”,
basándose en los nomb es de los mecanismos de consenso exis en es en Hype ledge
Besu, que ienen nomb es co os.
En la siguien e sección se habla á sob e la a qui ec u a que se ha diseñado a
pa i de es e esquema gene al que se plan ea.
25
5.2 A qui ec u a del p o o ipo
En es a sección se desc ibi á la a qui ec u a del p o o ipo ( ep esen ada
g á icamen e en la igu a 5-1), así como el p oceso pa a diseña e implemen a es e.
La pa e de la de echa, o mada po cuad ados de colo e de, ep esen a una
cadena de bloques, siendo cada cuad ado un bloque, con su núme o co espondien e,
y las lechas que los unen ep esen an el o den en que se han gene ado.
En la pa e izquie da, el á ea supe io de colo e de ep esen a de o ma
ampliada el bloque núme o 3, así como los Sma Con ac s¸ ep esen ados en colo
mo ado, que son p og amados en lenguaje Solidi y.
El p ime o, P oxyCon ac , es un con a o sencillo que implemen e la posibilidad
de ac ualiza el con a o del mecanismo de epu ación, almacenando su add ess y
pe mi iendo ac ualiza la con cie as es icciones po segu idad.
El segundo, RepuCon ac , es el con a o que implemen a el mecanismo de
consenso basado en epu ación, ac ualizable median e el con a o P oxy, que
implemen a el sis ema de o ación pa a ac ualiza la lis a de nodos alidado es, que
Figu a 5-1 Diag ama gene al de la a qui ec u a del p o o ipo

26
pe mi e calcula la epu ación de cada nodo de o ma dinámica, y se enca ga de
decidi quién se á el siguien e nodo alidado .
Po su pa e, el á ea in e io de colo azul ep esen a el clien e Hype ledge Besu,
p og amado en Ja a. Cada elemen o den o del bloque azul ep esen a una clase de
Ja a. El clien e Hype ledge Besu es á o mado po un g an núme o de clases, en la
igu a 5-1 solo se ep esen an las clases necesa ias pa a comp ende la a qui ec u a del
p o o ipo. Los dos p ime os de la pa e de la pa e supe io , que ienen unas líneas
e icales en los la e ales, ep esen an las “APIs” de los Sma Con ac s, es deci , las
clases de Ja a que hacen de puen e en e el código uncional del clien e y los con a os
in eligen es de la blockchain. Es as clases u ilizan la lib e ía Web3j (16), que pe mi e
abaja con la cadena de bloques sin ene que implemen a un código de in eg ación
p opio, acili ando así es a a ea.
La clase P oxyCon ac implemen a la comunicación en e el clien e Hype ledge
Besu y el Sma Con ac P oxyCon ac , mien as que la clase RepuCon ac implemen a
la comunicación con el con a o RepuCon ac .
En cuan o a la clase RepuHelpe s, es la clase que implemen a la mayo pa e de
uncionalidad en Ja a, que hace de in e media ia en e la clase p oduc o a de bloques
(RepuBlockMine , que se á desc i a a con inuación) y los Sma Con ac s (las clases
Web3j, desc i as an e io men e).
Finalmen e, la clase RepuBlockMine se enca ga de p oduci bloques, así como
de llama a mé odos de RepuHelpe s elacionados con el mecanismo de consenso,
como comp oba si es u no de p oduci bloque pa a un cie o nodo, o comp oba si es
u no de o a .
Las lechas que se mues an en la igu a ep esen an las in e acciones que exis en en e
los di e en es elemen os del sis ema.
5.3 Esquema de epu ación u ilizado
El desa ollo de es e TFG se ha basado undamen almen e en el en oque de Do
e al. (5), aunque pa a el sis ema de o ación ambién se ha u ilizado uno de los ac o es
que se p oponen en el a ículo de Zhuang e al. (6).
27
El esquema de epu ación u ilizado se mues a en la igu a 5-2.
Figu a 5-2 Esquema de epu ación implemen ado en Repu
El p ime ac o B es á basado en el p ime o del a ículo de Do e al. (5), el s ake
powe ( éase igu a 3-3). Como en la p opues a de es e TFG no se dispone de un
con a o de s ake (aunque se ía posible ex ende es e sis ema pa a inclui lo), se ha
decidido u iliza el balance o al de la cuen a que co esponde a la di ección del nodo
en el sis ema de blockchain. De es a o ma, cuan o más dine o enga un nodo en su
ca e a, mayo con ianza es a á deposi ando en la ed, po lo an o, se conside a á más
iable y se le o o ga á mayo epu ación.
El segundo ac o N es á basado en el e ce ac o ambién del a ículo de Do e
al. (5), el ansac ion-based epu a ion a ing ( éase igu a 3-3), en es e caso sin
modi icación de concep o. Es la can idad de ansacciones ealizadas po el nodo,
denominado nonce en la comunidad de desa ollado es de blockchain, po que se
alo a que un nodo sea ac i o pa a que se conside e más iable, es deci , que enga
mayo epu ación.
El e ce ac o P se basa en el e ce o del a ículo de Zhuang e al. (6), que se
desc ibía como “la con ibución al consenso”, y se ha conside ado que la mejo o ma
de con ibui al consenso es habe p oducido bloques (si ha sido elegido alidado ), ya
Vo e weigh = Repu a ion = R = c1B + c2N + c3P
c1, c2 y c3 ep esen an los pesos (weigh s) de
cada ac o de epu ación.
B ep esen a el balance (can idad de dine o)
de un nodo
N ep esen a el nonce (núme o de
ansacciones) de un nodo
P ep esen a la pa icipación en el consenso
(núme o de bloques p oducidos)
28
que, si ya ha alidado bloques an e io men e, es más p obable que lo pueda ol e a
hace de o ma iable, y po ello se le o o ga una mayo epu ación.
Los pesos (weigh s) ci de cada ac o ienen los siguien es alo es po de ec o en
el Sma Con ac :
c1 = 1, c2 = 3 y c3 = 2
Es os pesos son modi icables a pos e io i po el dueño del con a o (el nodo que
desplegó inicialmen e el con a o, conocido como el owne ) pa a ealiza ajus es sob e
el sis ema de epu ación, y se pueden consul a po cualquie pe sona que llame a los
mé odos de consul a sin cos e de gas (po se mé odos ipo iew). En es e diseño se ha
decidido u iliza alo es en e os pa a los pesos, pe o se pod ían modi ica ácilmen e
pa a que se u ilicen ac o es decimales de coma lo an e, como es p ác ica común en
o os sis emas basados en con a os como el es ánda de okens ERC-20 o la p opia
c ip omoneda E he .
También se plan eó usa un ac o de alea o iedad, pe o inalmen e se desca ó
po la di icul ad de maneja núme os alea o ios en Solidi y, aunque se conside a como
posible abajo u u o.
El balance (B) se ecupe a di ec amen e en Solidi y, pues o que la clase add ess
iene un a ibu o pa a consul a lo.
Sin emba go, el nonce (N) ha sido más complicado de ecupe a , pues o que no
se puede consegui di ec amen e desde Solidi y. La solución que se ha alcanzado ha
sido en ia lo desde Ja a cada ez que un nodo en ía su o o, y almacena lo en una
es uc u a de da os mapping (pa es cla e- alo ) en el Sma Con ac . Po segu idad, el
nonce que se en ía con el o o pasa po una alidación: no puede se meno o igual
que el an e io que se hubiese en iado (en caso de no habe se en iado an es, debe se
mayo que ce o).
En cuan o al núme o de bloques p oducidos (P), se ha ecu ido a una solución
di ec amen e en Solidi y (es o ag ega segu idad, ya que la in o mación ecibida desde
los clien es no es iable, pues el código del clien e de E he eum puede se manipulado
po un a acan e). Cada ez que se alida un bloque y se pasa a la siguien e onda,
median e una llamada al mé odo nex Tu n() o nex Tu nAndVo e() (que se án desc i os
29
en la sección 6.3.3) se inc emen a el núme o de bloques p oducidos del nodo que
acaba de alida el bloque, man eniendo es a in o mación ambién en una es uc u a
de da os mapping en el con a o.
5.4 Mecanismo de consenso basado en epu ación
Después de habe desc i o en las secciones an e io es el esquema gene al del
p o o ipo, su a qui ec u a y el esquema de epu ación que se ha diseñado, en es a
sección se desc ibi á el p ocedimien o gene al que sigue el mecanismo de consenso
basado en epu ación, que es á ep esen ado g á icamen e en la igu a 5-3.
En p ime luga , p e iamen e a la c eación de la cadena de bloques con
mecanismo de consenso Repu, el clien e Hype ledge Besu que a a p oduci el p ime
bloque (bloque génesis) debe u iliza un iche o de con igu ación con las ca ac e ís icas
de es e p ime bloque. Es e iche o, como se desc ibió en de alle an e io men e,
con iene pa áme os de con igu ación como el iempo en e bloques, o una lis a de
di ecciones con un balance (can idad de dine o) inicial ese ado. Pa a c ea una
cadena de bloques con el mecanismo de consenso Repu, se debe indica en los
pa áme os que se a a u iliza el mecanismo basado en epu ación y los pa áme os de
con igu ación de es e mecanismo, que son los mismos que los de Clique ( éase línea 4
de la igu a 4-3): el iempo mínimo pa a p oduci el siguien e bloque y el núme o de
bloques has a la siguien e einiciación de o os. Es e úl imo pa áme o pe manece pa a
man ene la implemen ación basada en Clique, pe o es eemplazado po el sis ema de
o ación p opio del mecanismo Repu que se de alla en la sección 6.3.
El inicio de la ed de blockchain con es e mecanismo de consenso equie e que
los p ime os bloques se p oduzcan de una o ma pa icula (el p oceso de a anque de
la ed se explica á con más de alle en la sección 6.4). P ime o se debe inicia un solo
nodo en la ed, que es el c eado de la cadena de bloques. Es e nodo c ea á el bloque
Figu a 5-3 P ocedimien o gene al del mecanismo de consenso basado en epu ación
36
6.2.1.1 Con a o RepuCon ac
En la igu a 6-2 se mues an los componen es p incipales del con a o
RepuCon ac que implemen a el sis ema de epu ación: es uc u as de da os,
unciones públicas y modi icado es. Los modi icado es son componen es ca ac e ís icos
del lenguaje Solidi y de p og amación de con a os, que pe mi en es ablece
es icciones de segu idad sob e la ejecución de unciones públicas. Los modi icado es
se desc iben en de alle en la sección 7.2 de segu idad del sis ema. A con inuación, se
desc iben las es uc u as de da os y las unciones públicas del con a o RepuCon ac .
Figu a 6-2 Diag ama que ep esen a las es uc u as de da os, modi icado es y unciones públicas del Sma
Con ac de Repu pa a ges iona el mecanismo de consenso

37
Es uc u as de da os
alida o s_ epu a ion es un mapping (es uc u a de da os simila a una abla hash
que almacena pa es cla e- alo ) que con iene la epu ación de cada alidado .
candida es_ o es es un mapping que con iene los o os de cada candida o a
alidado . Se einicia al inal de cada onda de o ación.
nodes_nonces es un mapping que con iene el nonce de cada nodo que haya
o ado alguna ez.
nodes_blocks es un mapping que con iene el núme o de bloques alidados po
cada nodo.
alida o s es un a ay que con iene los add ess de los nodos alidado es en cada
momen o.
candida es es un a ay que con iene los candida os a se alidado en la onda
de o ación. Se einicia al inal de cada una.
o e s es un a ay que con iene la lis a de o an es en cada onda de o ación.
Se u iliza pa a alida que cada nodo no o e más de una ez. Se einicia al inal de
cada una.
blackLis es un a ay que con iene la lis a de nodos en la lis a neg a, que no
pod án o a ni se alidado es nunca más.
inishVo ingValida o es una a iable que con iene al alidado que ha ejecu ado
el mé odo inishVo ing(). Se almacena pa a el caso especial en que el alidado deja
de se lo en esa onda de o ación, y debe ejecu a el mé odo nex Tu n() pasando po
una alidación que comp ueba si el nodo que lo ejecu a es alidado .
index es el índice del a ay de alidado es (módulo amaño del a ay) en el que
se encuen a la ed. Se einicia a 0 al inal de cada onda de o ación.
p oxyAdd ess y p oxy son el add ess y la ins ancia del con a o P oxy,
espec i amen e.
maxValida o s es el núme o máximo de alidado es que puede habe al mismo
iempo. Es modi icable median e su mé odo se e .
38
o ingRound es el pe iodo de o ación, es deci , cada cuán os bloques es
momen o de o a . Es modi icable median e su mé odo se e .
weigh Balance, weigh Blocks, y weigh Nonce son los pesos de cada ac o de
epu ación. Son modi icables median e sus mé odos se e .
owne es el add ess del c eado del con a o, es deci , el nodo que lo desplegó.
Se u iliza pa a alida quien ejecu a algunos mé odos es ingidos al c eado del
con a o.
Mé odos ( unciones públicas)
ge Valida o s(), ge BlackLis (), ge Vo e s(), ge Candida es(), y ge P oxyAdd ess()
son mé odos ge e es ánda que de uel en el a ay o a iable co espondien e.
dele eValida o () y dele eF omValida o s() son dos mé odos que eliminan el
add ess indicado de la lis a de alidado es. El segundo ambién llama a
upda eRepu a ion() y solo el owne puede ejecu a lo.
bubleSo () es un mé odo que implemen a el algo i mo de o denación i e a i o
y o dena dos a ays (de igual amaño) po o den de mayo a meno según los alo es
del p ime a ay.
isValida o () es un mé odo que comp ueba si el add ess indicado es un nodo
alidado .
indAdd ess() es un mé odo que busca en el a ay el add ess indicado, de uel e
la posición en la que es á si lo ha encon ado, y la úl ima posición más uno en caso de
no encon a lo.
nex Valida o s() es un mé odo que de uel e la lis a de alidado es ac uales
empezando po la posición de la a iable index módulo el amaño del a ay.
nex Tu n() y nex Tu nAndVo e() son dos mé odos que inc emen an en uno el
índice de alidado es index, inc emen an en uno los bloques p oducidos po el alidado
ac ual, y, si se encuen an en el bloque siguien e al u no de o ación, ejecu an
inishVo ing() y einician el index. El segundo mé odo, si se encuen a en u no de
o ación, ejecu a o eValida o ().
39
addValida o () y addToBlackLis () son dos mé odos que añaden un add ess
indicado a la lis a de alidado es y a la lis a neg a, espec i amen e.
addValida o s() es un mé odo que añade una lis a de alidado es a la lis a de
alidado es has a llega al lími e máximo. Lle a a cabo una se ie de alidaciones en
cada add ess de la lis a, que son si su nonce es mayo que 0, si no es á en la black lis y
si su balance es mayo que 0.
ge Block() es un mé odo que de uel e el bloque ac ual.
upda eRepu a ion() es un mé odo que ac ualiza la epu ación de cada alidado
en el mapping alida o s_ epu a ion llamando a calcula eRepu a ion(). Después,
o dena la lis a de alidado es llamando a ge So edValida o s().
se MaxValida o s(), se Weigh Balance(), se Weigh Nonce(), y se Weigh Blocks()
son mé odos se e es ánda que ac ualizan el alo de la a iable co espondien e.
calcula eRepu a ion() es un mé odo que calcula y de uel e la epu ación de un
add ess indicado en base a los es ac o es y los es pesos.
ge Repu a ion() y ge Vo es() son dos mé odos que de uel en la epu ación y los
o os ecibidos (como candida o) de un add ess indicado, espec i amen e. En el caso
del p ime o, hace una llamada al mé odo calcula eRepu a ion(), el segundo
di ec amen e lee del mapping candida es_ o es;
o eValida o () es un mé odo que ealiza la o ación de un nodo o an e hacia
el add ess indicado, as lle a a cabo una se ie de alidaciones, que son que se
encuen e en pe iodo de o ación, que aún no haya o ado, que no se o e a sí mismo,
y que ni el nodo al que es á o ando ni él mismo se encuen en en la lis a neg a. También
ecibe el nonce ac ual del o an e, y comp ueba que sea mayo es ic o que el an e io
egis ado. Además, o dena la lis a de candida os po núme o de o os llamando a
ge So edCandida es().
inishVo ing() es un mé odo que cie a la onda de o ación en el siguien e
bloque al u no de o a . Reinicia las lis as de o e s, candida es y el mapping
candida es_ o es, añade los alidado es con addValida o s() y ac ualiza las
epu aciones con upda eRepu a ion().
40
ge So edValida o s() y ge So edCandida es() son dos mé odos que llaman a
bubbleSo () pa a o dena la lis a de alidado es po epu ación y la de candida os po
o os, espec i amen e, y las de uel en.
upda eCon ac Add ess() es un mé odo, que solo puede ejecu a el owne , que
ac ualiza el add ess del con a o (de sí mismo) llamando al mé odo ex e no
se ConsensusAdd ess() de la ins ancia del con a o P oxy. Realiza dos alidaciones, que
son que el nue o con a o (con el add ess indicado) con enga el mismo add ess del
con a o P oxy, y que el add ess indicado pe enezca e ec i amen e a un Sma
Con ac .
ge Balance() y ge P oducedBlocks() son dos mé odos que de uel en los ac o es
de epu ación de balance y núme o de bloques p oducidos, espec i amen e.
6.2.1.2 Con a o P oxyCon ac
Es e con a o si e de p oxy del con a o RepuCon ac , de o ma que pe mi e
ob ene y modi ica la di ección del con a o que implemen a el sis ema de o ación.
En la igu a 6-3 se mues an los dis in os componen es que o man es e con a o y que
se desc iben a con inuación:
consensusAdd ess es una a iable que con iene el add ess del con a o de
epu ación.
isAllowed es un modi ie que comp ueba que el emiso de la ansacción es igual
al ac ual consensusAdd ess.
Figu a 6-3 Diag ama que ep esen a las a iables, modi ie s y mé odos del Sma
Con ac P oxy
41
ge ConsensusAdd ess() y se ConsensusAdd ess() son mé odos se e y ge e
es ánda de la a iable consensusAdd ess. En el caso del se e , u iliza el modi ie
isAllowed pa a es ingi que solamen e el con a o RepuCon ac ac ual pueda
ejecu a lo.
6.2.2 Implemen ación del nue o mecanismo de consenso en el clien e
Hype ledge Besu
Como se ha mencionado an e io men e, Hype ledge Besu (8) es un clien e
E he eum esc i o en Ja a, que pe mi e c ea cadenas de bloques pa a edes p i adas,
y se ha seleccionado como base pa a la implemen ación del p o o ipo de mecanismo
de consenso basado en epu ación. Pa iendo del diseño desc i o en la sección 5, se
desc ibi á en es a sección la implemen ación que se ha lle ado a cabo.
En el siguien e enlace se puede accede al eposi o io Gi Hub que se ha u ilizado
pa a el con ol de e siones, a una compa ación en e la ama mas e (un clone del
p oyec o o iginal de Besu) y la ama “de ” en la que se han subido los commi s y
ealizados los cambios:
h ps://gi hub.com/Danniilpz/besuPoR/commi /d2b65de17ba502c2c 478ed918e
1c523 5586ecd
Se ha u ilizado dos clases que implemen an la comunicación en e el clien e
Hype ledge Besu y los Sma Con ac s con la lib e ía Web3j (16), P oxyCon ac y
RepuCon ac . La p ime a se enca ga de in e ac ua con el Sma Con ac
P oxyCon ac , y la segunda con RepuCon ac . Ambas con ienen un mé odo Ja a po
cada unción de Solidi y, haciendo la con e sión de ipos na i os de Solidi y (sopo ados
en la lib e ía Web3j) a ipos de Ja a.
Po o a pa e, la mayo pa e de la uncionalidad añadida sob e el código
o iginal de Hype ledge Besu se ha implemen ado en la clase RepuHelpe s, que con iene
los mé odos llamados desde la clase de p oducción de bloques RepuBlockMine , que
ambién ha sido modi icada espec o a la o iginal.

42
6.2.2.1 Clase RepuBlockMine
Como se acaba de indica , la clase RepuBlockMine se enca ga de p oduci el
siguien e bloque en la cadena de bloques cuando el nodo que ejecu a el clien e
Hype ledge Besu es el elegido po el sis ema de epu ación. En la igu a 6-4 se mues a
el con enido de es a clase.
En es a clase se ha modi icado el cons uc o pa a ob ene algunos a ibu os que
e an necesa ias pa a las clases que u ilizan Web3j. Es os son: el NodeKey, que con iene
la cla e p i ada y la cla e pública del nodo ac ual, y es necesa io pa a ob ene las
c edenciales pa a pode i ma ansacciones; y el pue o en el que se ha abie o el
nodo, que es necesa io pa a inicializa la ins ancia de Web3J. También se llama a un
mé odo de RepuHelpe s ge RepuCon ac (), cuya uncionalidad es ins ancia el
con a o cuando ya haya sido desplegado po el nodo c eado de la blockchain (a
pa i del bloque núme o 3).
Una di icul ad adicional que p esen a la implemen ación del sis ema de
epu ación en un con a o es la o ma de comunica a los dis in os nodos la di ección
del con a o P oxyCon ac una ez se ha desplegado en la cadena de bloques. Como
el add ess de un con a o desplegado po un cie o nodo con una cie a cla e p i ada
siemp e es el mismo, se ha decidido ija el add ess del con a o P oxy en una cons an e
en el código uen e de Hype ledge Besu, y el add ess del con a o de consenso
inicialmen e es á ijado en una a iable, pe o en cada bloque se comp ueba en el p oxy
si el add ess ha cambiado, po medio de llamadas al mé odo ge ConsensusAdd ess()
de P oxyCon ac pa a, en ese caso, ac ualiza lo. De es a o ma, se esuel e el p oblema
Figu a 6-4 Diag ama que ep esen a las cons an es y mé odos
de la clase RepuBlockMine en el nodo Besu
43
inicial de cómo in o ma al es o de nodos del add ess, pues siemp e es el mismo en el
caso del P oxy, y el del con a o de consenso se puede consul a en es e.
Además del cons uc o , en RepuBlockMine se ha modi icado el mé odo
mineBlock(), que es el que se ejecu a pa a mina un bloque. En el diag ama de la igu a
6-5 se mues a el uncionamien o de es e mé odo.
Los mé odos add essIsAllowedToP oduceNex Block(), o eValida o (),
checkCon ac sA eDeployed() y nex Tu nAndVo e() son mé odos s a ic de la clase
RepuHelpe s.
El mé odo add essIsAllowedToP oduceNex Block() que se llama en la condición
comp ueba si el nodo ac ual debe p oduci bloque en es a onda o no.
El mé odo checkCon ac sA eDeployed() se enca ga de desplega los con a os
P oxy y RepuCon ac si no es án desplegados.
El mé odo nex Tu nAndVo e() se enca ga de pasa al siguien e u no de alidado
y, si es á en la onda de o ación, de en ia el o o del nodo que es á p oduciendo
Figu a 6-5 Funcionamien o del mé odo mineBlock() de RepuBlockMine
en Hype ledge Besu
44
bloque (el cambio de u no y el o o deben i en la misma ansacción, pues no se
pueden en ia dos ansacciones del mismo nodo en el mismo bloque, po que el hilo
que lanza la ansacción se queda en espe a).
El mé odo o eValida o () es llamado po los nodos que no p oducen bloque en
es a onda, y se enca ga de en ia el o o en caso de es a en onda de o ación. En
caso con a io, no hace nada.
6.2.2.2 Clase RepuHelpe s
La clase RepuHelpe s es la que implemen a la mayo pa e de la uncionalidad
del mecanismo de consenso en el clien e Hype ledge Besu. Con iene los mé odos que
hacen de in e media ios en e la clase p oduc o a de bloques (RepuBlockMine , que se
ha desc i o en la sección an e io ), y los Sma Con ac s.
A con inuación, se desc iben los componen es de la clase RepuHelpe s,
ep esen ada g á icamen e en la igu a 6-6.
LOG es una cons an e u ilizada pa a imp imi mensajes log en la e minal.
GAS_PRICE y GAS_LIMIT son cons an es que indica el p ecios y lími e de gas.
Figu a 6-6 Diag ama que ep esen a las cons an es, a iables y mé odos de la clase RepuHelpe s
en el nodo Besu
45
VOTE_FILE es una cons an e que indica el nomb e del iche o local en el que el nodo
con igu a su o o pa a se en iado.
VOTING_ROUND es una cons an e que indica cada cuán os bloques p oducidos debe
habe una onda de o ación.
web3j, nodeKey, p oxyCon ac y epuCon ac son a iables que con ienen ins ancias
de sus espec i as clases.
con ac Deployed y con ac Deploying son a iables booleanas que indican si los
con a os ya han sido desplegados y si los con a os es án siendo desplegados en es e
momen o, espec i amen e. Se u ilizan pa a la sinc onización en e hilos del nodo que
se es á ejecu ando, e i ando que dos hilos ejecu en el mismo mé odo, que solo debe
ejecu a se una ez.
o ing es una a iable que indica si el nodo es á ac ualmen e o ando. Se u iliza
ambién pa a la sinc onización en e los hilos del p opio nodo.
alida ions es una a iable que con iene una es uc u a map con pa ejas cla e- alo
que con ienen núme o de bloque y alidado . Se u iliza pa a la sinc onización de los hilos
de un nodo, así como pa a la sinc onización de los di e en es nodos, ya que cada
alidado se ob iene a pa i del Sma Con ac .
ge Valida o O Block(), ge Valida o Fo BlockA e (), ge Valida o s() y isValida o () son
mé odos que comp ueban el alidado de un bloque, el siguien e alidado , la lis a de
alidado es, y si el nodo con el add ess indicado es alidado , espec i amen e. Pa a
ello se usan las llamadas a los mé odos nex Valida o s() y isValida o () del Sma
Con ac .
add essIsAllowedToP oduceNex Block() es un mé odo que comp ueba si el nodo ac ual
es un alidado y si es su u no de p oduci bloque.
nex Tu nAndVo e() y o eValida o () son mé odos que, en caso se u no de o ación, y
de que el nodo enga con igu ado su o o ( enga en su ca pe a local el iche o
“ alida o Vo e” no acío y con el o ma o co ec o), en ían el o o. Además, el p ime
mé odo es llamado po los alidado es en el momen o inmedia amen e pos e io a
52
Pos e io men e, c ea el iche o génesis en la ca pe a aíz de la es uc u a de
ca pe as, con el o ma o indicado en la documen ación. Sin emba go, pa a adap a el
iche o al nue o mecanismo de consenso Repu, hay algunos pa áme os que deben se
di e en es. ( e igu a 6-12). Se puede oma como ejemplo el iche o
“ epuGenesis_demo.json” si uado en el di ec o io /demo.
Además, se debe añadi en la lis a “alloc” una en ada pa a el add ess del nodo
owne (que se puede consul a en “Node-1/da a/node1Add ess”), ese ando un
balance inicial su icien e pa a pode a on a el cos e de gas que supone desplega los
con a os P oxyCon ac y RepuCon ac .
En ex aDa a se debe eemplaza “<Node 1 Add ess>” po el add ess del nodo
owne excluyendo el p e ijo 0x.
Po úl imo, pa a ejecu a el nodo owne se debe ab i una e mina en su di ec o io
(Node-1), y ejecu a el siguien e comando, modi icando
“<nomb eFiche oGenesis.json>” po el nomb e elegido pa a es e.
"con ig":{
"chainId":1337,
"be linBlock": 0,
" epu":{
"blockpe iodseconds":10,
"epochleng h":30000
}
}
…
"gasLimi ":"0xa00000000000",
Figu a 6-12 Pa áme os de con igu ación de Repu en el a chi o del bloque génesis

53
besu --da a-pa h=da a --genesis- ile=../<nomb eFiche oGenesis.json> --
ne wo k-id 123 -- pc-h p-enabled -- pc-h p-api=ETH,NET,REPU --hos -
allowlis ="*" -- pc-h p-co s-o igins="all"
Pa a ejecu a o os nodos se ejecu a á el siguien e comando desde la ca pe a
aíz de cada nodo, sus i uyendo <Node-1 Enode URL> po el enode del node-1 (se copia
en la e minal del Nodo owne ), así como “<nomb eFiche oGenesis.json>”. También se
debe á cambia el p2p-po y el – pc-h p-po po cada nue o nodo que se ejecu e,
ya que no puede epe i se el pue o.
besu --da a-pa h=da a --genesis- ile=../ <nomb eFiche oGenesis.json> --
boo nodes=<Node-1 Enode URL> --ne wo k-id 123 --p2p-po =30304 -- pc-h p-
enabled -- pc-h p-api=ETH,NET,REPU --hos -allowlis ="*" -- pc-h p-co s-
o igins="all" -- pc-h p-po =8546
Opcionalmen e, se puede con igu a el o o de cada nodo pa a la onda de
o ación de alidado es, c eando un iche o con nomb e “ alida o Vo e” en su
di ec o io, y esc ibiendo den o el add ess del nodo al que quie e o a , sin espacios ni
an es ni después.
Una ez ejecu ados los nodos, ya se puede e a a és de las di e en es
e minales el uncionamien o de la cadena de bloques.
Pa a ol e a ejecu a desde el p incipio la ed, se deben p ime o acia las
ca pe as de los nodos (a excepción de los a chi os de add ess, p i a eKey y
alida o Vo e). Realiza es a a ea de o ma manual es edioso, po ello se c eó un sc ip
bash pa a au oma iza la ( e igu a 6-1).
54
Es e sc ip se debe copia en un a chi o con ex ensión .ba y epe i lo po cada
ca pe a de nodo (sus i uyendo “Node-1” po el nomb e del es o de nodos), y ejecu a
odos jun os, de o ma que en menos de 1 segundo la a ea de elimina esos a chi os
es a á esuel a.
i exis ". Node-1 da a caches" d /s /q ". Node-1 da a caches"
i exis ". Node-1 da a da abase" d /s /q ". Node-1 da a da abase"
i exis ". Node-1 da a DATABASE_METADATA.json" del /q ". Node-
1 da a DATABASE_METADATA.json"
Figu a 6-13 Sc ip bash pa a la au oma ización de la a ea de einicia la ed de nodos local
55
Capí ulo 7 - E aluación y compa a i a
En es e capí ulo se desc ibi á la e aluación de escalabilidad que se ha ealizado,
así como una compa a i a con mecanismos de consenso ya exis en es. Se ha e aluado
el p o o ipo con un núme o limi ado de nodos, pe o se indican posibles p oblemas de
escalabilidad en el caso de que el sis ema es u iese o mado po un núme o mucho
mayo .
7.1 Escalabilidad
La p ueba ealizada consis ió en la c eación de una ed o mada po 10 nodos,
con una onda de o ación cada 5 bloques, y un máximo de 5 alidado es, uncionando
co ec amen e la sinc onización de es os y el sis ema de o ación.
A con inuación, se mues a un ejemplo de p oceso de o ación. En un p oceso
de o ación pa icipan odos los nodos de la ed, y cada uno emi e un o o pa a
selecciona aquellos nodos que pasa án a o ma pa e de la lis a de alidado es, que
son los nodos que pueden gene a nue os bloques en la cadena de bloques. En es e
ejemplo pa icula , los 10 nodos que o man la ed pueden selecciona has a 5
alidado es. En la Tabla 3 se mues an, pa a cada nodo, el núme o de nodo al que o a.
Po ejemplo, en la p ime a columna, el nodo 1 o a po el nodo 4, y en la segunda, el
nodo 2 no ha emi ido ningún o o. La e ce a ila con iene el alo de epu ación de
cada uno de los nodos de la ed.
Tabla 3 – Esquema de o ación de la p ueba con 10 nodos
Nodos
1
2
3
4
5
6
7
8
9
10
Nodo
o ado
4
-
8
8
3
2
2
3
4
1
Repu ación
56
100
12
22
22
22
22
42
22
32
56
Los esul ados de la o ación se mues an en la Tabla 4. Una ez emi idos los o os,
el con a o de epu ación ealiza el ecuen o de o os, que apa ece en la segunda ila
de la abla. Los o os se ponde an con el esul ado que se mues a en la e ce a ila.
Finalmen e, los nodos seleccionados son los que apa ecen en la úl ima ila, o denados
po el núme o indicado.
Tabla 4 – Resul ados de la o ación en la p ueba con 10 nodos
Nodos
1
2
3
4
5
6
7
8
9
10
Recuen o
o os
1
2
2
2
0
0
0
2
0
0
Vo os
ponde ados
22
44
64
77
0
0
0
34
0
0
Seleccionados
(max. 5)
1
4
3
2
Como se puede obse a , el nodo 2 no ue elegido como alidado , debido a
que nunca había o ado an e io men e (su nonce e a ce o). Además, como solo se
o a on 5 nodos di e en es, y el nodo 2 ue desca ado, solo 4 nodos esul a on
seleccionados (de un máximo de 5).
El p o o ipo desa ollado en es e abajo nos pe mi e es udia los posibles
p oblemas de escalabilidad que puede encon a un mecanismo de consenso basado
en epu ación en un escena io eal con un g an núme o de nodos.
El p incipal p oblema que se ha de ec ado que puede da se con un mayo
núme o de nodos es con el algo i mo de o denación del Sma Con ac , cuando se
u iliza pa a o dena la lis a de candida os po sus o os ecibidos. Se ha de ec ado que
Hype ledge Besu e ie e las ansacciones que ejecu an mé odos con al o consumo
de gas. Es o ha ocasionado p oblemas du an e el desa ollo, p ime o con cualquie
57
núme o de nodos, cuando se u ilizaba el algo i mo de o denación ecu si o QuickSo ,
y después, ya con el algo i mo i e a i o BubbleSo , cuando se hacían p uebas con un
núme o de nodos mayo que 8. Finalmen e, se encon ó una solución p o isional a es e
p oblema, que ue o dena la lis a de candida os en el mé odo o eValida o (de o ma
que se o dena au omá icamen e cada ez que un nodo en ía su o o), en luga de en
el mé odo inishVo ing(), que iene un consumo de gas mucho mayo po la ejecución
de o os mé odos, en compa ación al p ime mé odo mencionado.
En el caso de o denación de la lis a de alidado es po epu ación, en la e apa
de cie e de o ación, el algo i mo de o denación no se ía an p oblemá ico, po que la
can idad de alidado es siemp e es aco ada, mien as que la can idad de candida os
puede c ece de o ma inde inida.
7.2 Segu idad
Con espec o a la segu idad, se han enido en cuen a di e sos aspec os que se
de allan a con inuación.
En el con a o se han incluido múl iples alidaciones de ansacciones (con el uso
de modi ie s de Solidi y), que son las siguien es:
• Modi ie isOwne (): comp ueba que el add ess que ejecu a la ansacción
es el dueño del con a o (el nodo que lo desplegó). Se u iliza en el mé odo
dele eValida o () pa a solamen e pe mi i que el owne pueda elimina un
alidado de la lis a, y en los mé odos de ac ualización de los pesos y del
núme o máximo de alidado es: se Weigh Balance(), se Weigh Nonce(),
se Weigh Blocks() y se MaxValida o s().
• Modi ie isAllowed(): comp ueba que el nodo es alidado , o lo e a en el
momen o que llamó al mé odo (pa a el caso especial de que un nodo
p oduzca el bloque de cie e de o ación y en ese momen o deje de se
alidado ). Se u iliza en el mé odo nex Tu n(), que lo ejecu an los
alidado es jus o después de p oduci un bloque.
• Modi ie hasCo ec P oxyAdd ess(): comp ueba que el con a o con el
add ess indicado iene el mismo add ess de p oxy que el con a o ac ual.

58
Se u iliza en el mé odo upda eCon ac Add ess() pa a comp oba que el
con a o que hay en el add ess indicado no es malicioso.
• Modi ie isCon ac (): comp ueba que el add ess indicado es un con a o.
Se u iliza en el mé odo upda eCon ac Add ess() pa a comp oba que el
add ess es co ec o y pe enece a un Sma Con ac . Se ha usado la
lib e ía “Add ess” de Openzeppelin (21) pa a comp oba si un add ess es
un con a o, usando el mé odo isCon ac (), pa a e i a que se in en e
ac ualiza el add ess del con a o con uno que no sea álido.
• Modi ie no Vo edYe (): comp ueba que el add ess del nodo o an es no
es á en la lis a de o an es. Se u iliza en el mé odo o eValida o () pa a
asegu a que un nodo no pueda o a a ias eces y e i a o os
duplicados.
• Modi ie no Vo eHimsel (): comp ueba que el add ess indicado no
coincide con el nodo o an e. Se u iliza en el mé odo o eValida o () pa a
asegu a que un nodo no pueda o a se a sí mismo.
• Modi ie isVo ingRound(): comp ueba que el bloque ac ual coincide con
la onda de o ación. Se u iliza en el mé odo o eValida o () pa a e i a
que los nodos o en ue a de iempo.
• Modi ie no InBlackLis (): comp ueba que el add ess indicado no se
encuen a en la black lis . Se u iliza en el mé odo o eValida o () pa a
e i a que los nodos que es án en la lis a neg a puedan o a .
En el sis ema de o ación se ha incluido una lis a neg a de alidado es, a la cual
se añaden nodos que hayan en iado un nonce e óneo (meno o igual que el an e io ,
o ce o en el caso inicial), lo que signi ica que han modi icado el código uen e de
Hype ledge Besu pa a conec a se a la cadena de bloques. Es os nodos añadidos a la
lis a neg a no pod án ol e a o a ni se elegidos alidado es.
En el mé odo addValida o s(), que se enca ga de añadi los nue os alidado es
as el pe iodo de o ación, ambién se ealizan alidaciones po segu idad, como ya se
mencionó an e io men e. Es as son las siguien es: no se pod á nunca añadi un nodo
como alidado si el balance de es e es 0, ya que no pod ía no ejecu a ansacciones;
59
ampoco si su nonce es 0, lo que signi ica ía que nunca ha o ado, y no se pod ía
calcula su epu ación co ec amen e ( al a ía un ac o ); ni, po supues o, si su add ess
es á en la lis a neg a).
Po o a pa e, en Hype ledge Besu exis en una se ie de eglas de alidación a
las que se some en los nue os bloques impo ados, con el in de de ec a si un bloque
es malicioso o inco ec o, y no añadi lo a la blockchain.
En el código de Besu ambién se ha enido en cuen a el posible uso excesi o de
ecu sos del sis ema, ya que en el p oceso de p oduci un nue o bloque odos los nodos
se quedan en espe a po un iempo, y pa a e i a el consumo excesi o po espe a
ac i a, se due men los hilos du an e 0.1s con Th ead.sleep (100ms).
En cuan o al pe iodo de o ación, en p incipio no es modi icable una ez se ha
c eado la blockchain. Solo se ía posible modi ica lo desplegando un nue o con a o y
ac ualizando a una nue a e sión de Besu que con enga el mismo pe iodo de o ación,
po segu idad. Si se hubie a pe mi ido modi ica lo con un mé odo en el con a o, es o
pod ía lle a a incompa ibilidades con el clien e de Besu, en el caso de que la a iable
o ingRound no coincidiese en ambos.
En cuan o a la ac ualización del add ess del con a o en el con a o P oxy, solo
es posible median e una llamada desde el p opio con a o de consenso ac ual (el
mé odo se ConsensusAdd ess() es á es ingido a se llamado po la ac ual
consensusAdd ess). A su ez, el mé odo upda eCon ac (), que llama al mé odo de
P oxyCon ac , solo puede se ejecu ado po el owne del con a o, po segu idad.
7.3 Compa a i a
En es a sección se an a ealiza dos compa aciones del mecanismo de
epu ación implemen ado, Repu, con el sis ema de pa ida Clique, y con o o
mecanismo basado en P oo o Au ho i y con enido ambién en Hype ledge Besu, QBFT.
Compa ando Repu con el mecanismo Clique, del que se ealizó un clonado o al
y se modi icó su uncionalidad, pod íamos deci que se ha “desp endido” de la lógica
en Ja a pa a selecciona a los siguien es alidado es.
60
Si bien la lógica de sinc onización en e nodos (impo ación de bloques
p oducidos) es común en e ambos, la uncionalidad ela i a a la selección de
siguien es alidado es de bloques ha cambiado po comple o. En Repu se ha c eado
un Sma Con ac que se despliega en los p ime os es bloques y se u iliza pa a la
ges ión o al del mecanismo de consenso. Es el con a o el que decide quien debe
alida los siguien es bloques y en qué o den. Es a in o mación es pública pa a cualquie
que ealice una consul a a es e con a o. Es o apo a anspa encia, iabilidad y
elegancia al mecanismo de consenso.
También se ha implemen ado en Repu un sis ema de o ación basado en
epu ación, que ponde a los o os de cada nodo en unción de su epu ación en cada
momen o. Es e mecanismo ambién es á comple amen e implemen ado en el con a o,
si bien desde Hype ledge Besu en Ja a se hacen las llamadas necesa ias pa a que el
sis ema uncione.
Se pod ía deci que se ha sus i uido la lógica que exis ía en Clique pa a
selecciona alidado es a a és de clases implemen adas en Web3j que se conec an
con un Sma Con ac , y es dicho con a o quien con iene oda esa lógica (con las
no edades del sis ema basado en epu ación).
Si compa amos Repu con el mecanismo QBFT, se ap ecian mayo es simili udes.
QBFT es un mecanismo basado en P oo o Au ho i y que iene un sis ema de o ación
pa a alida los bloques p e iamen e a se añadidos a la blockchain. Cada bloque
debe se ap obado po 2/3 de los alidado es exis en es.
Además, iene dos sis emas pa a selecciona alidado es, uno p og amado en
Ja a (al es ilo de Clique) y o o implemen ado en un Sma Con ac p e-desplegado en
la blockchain en el bloque génesis, que ambién unciona median e un sis ema de
o ación.
Aunque Repu no u iliza su sis ema de o ación pa a ap oba cada bloque (ya
que el sis ema de pa ida, Clique, ca ecía de esa uncionalidad), sí que se u iliza ambién
un Sma Con ac con un sis ema de o ación pa a selecciona a los alidado es, al
igual que en QBFT.
61
Sin emba go, en Repu no se log ó p e-desplega los con a os, y se u ilizan es
bloques iniciales “génesis” pa a ello. Po o a pa e, en Repu se ha implemen ado la
posibilidad de ac ualiza el con a o de epu ación, g acias a con a o P oxy. Es o úl imo
es una en aja en e a QBFT, cuyo con a o no es modi icable una ez c eada la
blockchain.
Si compa amos el Sma Con ac de Repu con el con a o u ilizado po QBFT (22),
encon amos a iables y mé odos simila es.
También ienen un núme o máximo de alidado es (en su caso no es modi icable,
a di e encia de Repu), u ilizan mappings y a ays pa a ges iona los alidado es y los
o os, y ienen mé odos pa a ob ene los alidado es y ges iona el sis ema de o ación.
Lo más des acable de Repu espec o a QBFT es que inco po a la no edad de un
mecanismo de consenso basado en epu ación u ilizando un Sma Con ac , algo que
has a el momen o no se ha desa ollado en ningún p oyec o conocido.
68
This wo k is based on he idea o c ea ing a p o o ype o an inno a i e Blockchain
ne wo k consensus mechanism, aking as a cen al idea he epu a ion-based sys ems
p oposed in se e al academic a icles (4) (5) (6). A consensus mechanism based on
epu a ion sys ems would allow he c i e ia used o choose he nex alida o (node ha
will p oduce he nex block) o be adjus ed mo e dynamically han o he mechanisms. I
could be used in p i a e o pe missioned ne wo ks, o e en in majo i y ne wo ks such as
Bi coin o E he eum.
As a s a ing poin , one can ake an exis ing E he eum node, such as Ge h (7),
p og ammed in Go, o Hype ledge Besu (8), p og ammed in Ja a, which allow he
c ea ion o p i a e Blockchain ne wo ks, ideal o es ing his ype o consensus
mechanism.
Goals
The main objec i e o his wo k is o s udy he cha ac e is ics o a blockchain
sys em ha uses a consensus mechanism based on P oo o Repu a ion (PoR). To his end,
we will implemen a p o o ype ha will allow us o e alua e he mos ele an aspec s o
he sys em, using an exis ing open-sou ce implemen a ion o E he eum as a s a ing poin .
Speci ically, he speci ic objec i es o his wo k a e he ollowing:
• To s udy al e na i e consensus mechanisms o he mos popula ones, ocusing
especially on P oo o Repu a ion.
• To s udy he possibili y o implemen ing a consensus mechanism p og ammed
in a Sma Con ac , delega ing all he managemen o he mechanism o i
and eeing he nodes om his unc ionali y. This would make i possible o
ha e a secu e, anspa en , aceable and upda able consensus mechanism.
• S udy he applicabili y o epu a ion sys ems o he consensus mechanisms o
blockchain sys ems. Design a PoR (P oo o Repu a ion) consensus mechanism.
• S udy he cu en implemen a ions o E he eum blockchain sys ems o choose
he mos sui able one o he implemen a ion o a PoR consensus p o o ype.
• Once he p o o ype is implemen ed, es i by se ing up a local ne wo k o
nodes, and see o wha ex en i would be scalable in a eal ne wo k.

69
Wo k plan
Du ing he de elopmen o his wo k, weekly mee ings ha e been held be ween
u o and s uden o he moni o ing and planning o he ollowing asks:
1.S udy he exis ing E he eum implemen a ions and decide which one is he mos
sui able o use as he basis o his wo k.
2.S udy he exis ing consensus mechanisms in he node and see which one would
be mos simila o P oo o Repu a ion.
3.S udy in de ail he consensus p oposals based on P oo o Repu a ion (PoR)
published in academic a icles.
4.Se up a es blockchain ne wo k wi h one o wo nodes o lea n how he chosen
E he eum implemen a ion wo ks and compile and un he sou ce code o ha
implemen a ion.
5.Design a basic PoR scheme based on he academic p oposals s udied in poin
3. E alua e he easibili y o using sma con ac s o implemen he PoR consensus
mechanism.
6.Implemen he design, ei he wi h a Sma Con ac o in he node's own
managemen p og am, as designed in he p e ious s ep.
7.Tes he implemen ed p o o ype in o de o compa e i wi h exis ing mechanisms
and es scalabili y.
8.Documen he p ojec by aming he al e na i e mechanism chosen in he
exis ing algo i hms.
71
Conclusions and u u e wo k
This sec ion will ake s ock o he objec i es se a he beginning and wha has
been achie ed, by way o conclusion, and will also men ion possible imp o emen s/new
unc ionali ies ha could be de eloped as u u e wo k on he p ojec .
The i s objec i e, " o s udy al e na i e consensus mechanisms", has been ul illed
by s udying di e en academic a icles on P oo o Repu a ion, as desc ibed in he "S a e
o he A " sec ion.
The second objec i e, " o s udy he possibili y o implemen ing a p og ammed
consensus mechanism in a Sma Con ac ", has also been success ully achie ed,
al hough limi a ions ela ed o he so ing algo i hm ha e a isen.
The hi d objec i e, "To implemen a p o o ype", has been achie ed and i s
scalabili y has also been s udied.
The ou h objec i e, " o s udy which E he eum node o use", has also been a
success, as he Hype ledge Besu node has been used and he p o o ype has been
implemen ed based on i .
The i h and las objec i e, "To es wi h a local node ne wo k and s udy
scalabili y", has also been achie ed. As desc ibed in he scalabili y sec ion abo e, es s
ha e been success ully ca ied ou wi h 10 nodes.
Possible u u e wo k will be desc ibed below.
I emains o implemen a ime-ou unc ionali y so ha , in he case whe e a node
does no espond, he nex node is allowed o alida e. Howe e , his is no easy o
implemen , because he node synch onisa ion mechanism is in eg a ed in he co e o
Hype ledge Besu, and changing his would imply modi ying he unc ioning o o he
consensus mechanisms, which is p oblema ic. The ideal solu ion would be o c ea e a
speci ic class o his unc ionali y wi hin Repu.
An a emp was made o implemen he ime-ou , eaching a p imi i e e sion,
bu i was inally disca ded due o lack o ime. This implemen a ion wo ked in he case
ha he alida o ha does no espond does no econnec , and he es o he
72
alida o s wai 30 seconds om he p oduc ion ime o he las block o pass o he nex
alida o in he lis i he nex block has no been p oduced. This code is commen ed ou
in he RepuHelpe s class, as shown in Figu e 8-1.
As a possible secu i y imp o emen , nodes could be eed om calling he
con ac 's "nex Tu n()" me hod, which is cu en ly equi ed o he blockchain o p og ess,
and could be a secu i y hole i someone we e o modi y he sou ce code. To imp o e his
aspec , one could y o execu e au oma ically in he con ac .
Fu u e wo k also emains o be done o implemen he es s o he Repu
mechanism co ec ly, which o he momen a e a clone o hose o Clique.
As explained in p e ious sec ions, in heo y i is possible o p e-deploy Sma
Con ac s in he genesis block ( i s block), as his is desc ibed in he Hype ledge Besu
documen a ion (15). Howe e , due o he poo documen a ion and lack o ime, i was
no possible o co ec ly deploy e en a simple con ac . Wi h he es s pe o med, i was
possible o deploy a con ac , bu i did no espond co ec ly, bu e u ned da a in
unknown hexadecimal.
Figu a 8-2 Anno a ed code o he ime-ou p o o ype implemen ed in Besu
73
A possible u u e imp o emen would be o in es iga e his aspec u he , in o de
o p e-deploy a leas he p oxy con ac , and i possible, also he consensus con ac
RepuCon ac . This would educe he cu en h ee "genesis blocks" o wo, o a bes one.
Ano he possible imp o emen would be o c ea e a s ake con ac , in he s yle o
he E he eum ne wo k, in o de o eplace he cu en epu a ion ac o "balance" wi h a
ai e and mo e eliable one, which would be he amoun o money in s ake, i.e. he
amoun o money be by a node, as in ne wo ks ha use P oo o S ake.
Ano he possible imp o emen would be o implemen a andomiza ion ac o in
epu a ion, in o de o a oid one pa o he ne wo k always being in con ol. Howe e ,
his op ion was ini ially uled ou because o he secu i y p oblems caused by andom
numbe s in Solidi y (ope a ions wi hin he blockchain mus be de e minis ic, i.e. p oduce
he same esul ega dless o who makes he call). A mechanism simila o E he eum,
which uses a andomness ac o in i s P oo o S ake consensus mechanism, can be used.
As u u e wo k, one could in es iga e how hey handle his issue in E he eum and y o
implemen hei solu ion in Repu.
Ano he aspec ha could be imp o ed in he u u e is he decen aliza ion o
con ol powe o e he Sma Con ac . A he momen , ce ain ac ions on he con ac
can only be ca ied ou by he owne , i.e. he node ha ini ially deployed i , and his is,
in a way, a secu i y p oblem, aking in o accoun ha he owne can s op being a
alida o as jus ano he node and could e alia e by modi ying con ac alues. Fo
example, upda ing he add ess o he con ac i sel , emo ing alida o s, upda ing he
maximum numbe o alida o s o upda ing he weigh s o he epu a ion ac o s. One
possibili y o ully decen alized con ac managemen would be o use a DAO
(Decen alized Au onomous O ganiza ion), so ha he e a e se e al owne nodes and
o ing akes place o con ac decisions.
Ano he possible imp o emen would be o send mo e eedback o he nodes
om he con ac on he esul o he execu ion o he di e en me hods. Fo example, i
a candida e alida o has been ejec ed in he alida ion p ocess, speci y he eason o
his.

74
As men ioned abo e, as u u e wo k necessa y o he scalabili y o he p o o ype,
i would be necessa y o in es iga e an e icien and secu e solu ion o so he Sma
Con ac a ays, o a oid excessi e gas consump ion by he execu ion o me hods in i ,
no o comp omise he secu i y o he ne wo k by pe o ming he so ing in he sou ce
code o he nodes, which is manipulable.
75
BIBLIOGRAFÍA
1. Bi 2me Academy. Bi 2me Academy. ¿Qué es Blockchain, la ecnología de la Cadena
de Bloques? [En línea] h ps://academy.bi 2me.com/que-es-cadena-de-bloques-
blockchain/.
2. Bu e in, Vi alik. E he eum Whi e Pape : A Nex Gene a ion Sma Con ac &
Decen alized Applica ion Pla o m. [En línea] 2014.
h ps://e he eum.o g/669c9e2e2027310b6b3cdce6e1c52962/E he eum_Whi epape _-
_Bu e in_2014.pd .
3. Nakamo o, Sa oshi. Bi coin: A Pee - o-Pee Elec onic Cash Sys em. [En línea] 2009.
h ps://bi coin.o g/bi coin.pd .
4. P oo -o -Repu a ion: An Al e na i e Consensus Mechanism o Blockchain Sys ems.
Aluko, Olado un and Kolonin, An on. 2021.
5. Delega ed P oo o Repu a ion: A No el Blockchain Consensus. Thua Do e al.
10.1145/3343147.3343160 : Associa ion o Compu ing Machine y, 2019. IECC '19:
P oceedings o he 1s In e na ional Elec onics Communica ion Con e ence. pág. 9.
6. P oo o Repu a ion: A Repu a ion-based Consensus P o ocol o Blockchain Based
Sys ems. Zhuang, Qianwei, e al. New Yo k, NY, USA : Associa ion o Compu ing
Machine y, 2019. IECC '19: P oceedings o he 1s In e na ional Elec onics
Communica ion Con e ence. pág. 8.
7. Go-E he eum. Ge ing s a ed wi h Ge h. [En línea]
h ps://ge h.e he eum.o g/docs/ge ing-s a ed.
8. Hype ledge Founda ion. Hype ledge Besu. [En línea]
h ps://www.hype ledge .o g/use/besu.
9. e he eum.o g. Consensus. [En línea]
h ps://e he eum.o g/en/de elope s/docs/consensus-mechanisms/.
10. The Bizan ine Gene als P oblem. Lampo , Leslie e al. 1982. ACM TOPLAS.
76
11. Bi coin Gold Blockchain Hi by 51% A ack Leading o $70K Double Spend. [En línea]
2018. Ma in, Jack. h ps://coin eleg aph.com/news/bi coin-gold-blockchain-hi -by-51-
a ack-leading- o-70k-double-spend.
12. e he eum.o g. P oo o Wo k (PoW). [En línea]
h ps://e he eum.o g/es/de elope s/docs/consensus-mechanisms/pow/.
13. Mena Roa, Mónica. Bi coin consume más elec icidad que países en e os. [En línea]
2021. h ps://es.s a is a.com/g a ico/18630/consumo-de-elec icidad-anual-de-bi coin/.
14. Linux Founda ion. [En línea] h ps://www.linux ounda ion.o g/.
15. Hype ledge Besu. P e-deploy con ac s in he genesis ile. [En línea]
h ps://besu.hype ledge .o g/en/s able/p i a e-ne wo ks/how-
o/con igu e/con ac s/?h=genesis+s o age.
16. Web3j. [En línea] h ps://docs.web3j.io/4.10.0/.
17. Solidi y. Ins alling he Solidi y Compile . [En línea]
h ps://docs.solidi ylang.o g/en/ 0.8.17/ins alling-solidi y.h ml#ins alling- he-solidi y-
compile .
18. Wikipedia. O denamien o de bu buja. [En línea]
h ps://es.wikipedia.o g/wiki/O denamien o_de_bu buja.
19. Hype ledge Besu. C ea e a p i a e ne wo k using Clique. [En línea]
h ps://besu.hype ledge .o g/en/s able/p i a e-ne wo ks/ u o ials/clique/.
20. Hype ledge Besu. Con igu e Clique consensus. [En línea]
h ps://besu.hype ledge .o g/en/s able/p i a e-ne wo ks/how-
o/con igu e/consensus/clique/.
21. Openzeppelin. [En línea] h ps://gi hub.com/OpenZeppelin/openzeppelin-
con ac s/blob/mas e /con ac s/u ils/Add ess.sol.
22. ConsenSys. Gi hub. Valida o Sma Con ac AllowLis .sol. [En línea]
h ps://gi hub.com/ConsenSys/ alida o -sma -
con ac s/blob/main/con ac s/allowlis /Valida o Sma Con ac AllowLis .sol.
23. Razo bliss o a ion. Theymos om Bi coin wiki ec o iza ion. [En línea]
77
24. Hype ledge Besu. Hype ledge Besu a chi ec u e. [En línea]
h ps://besu.hype ledge .o g/en/22.1.3/Concep s/A chi ec u eO e iew/.