Tema3 1

Tema 3
Introducción a Blockchain
Bitcoin y Ethereum
Índice
© Universidad Internacional de La Rioja (UNIR)
Ideas clave 3
3.1. Bitcoin 3
3.2. Ethereum y su Virtual Machine EVM 24
3.3. Las criptomonedas como usuario: wallets y
exchanges 39
Ideas clave
3.1. Bitcoin
Origen de Bitcoin
En 2009, surge un documento publicado por un desconocido Satoshi Nakamoto

(Nakamoto, S. (2009). Bitcoin: A Peer-to-Peer Electronic Cash System.
https://bitcoin.org/bitcoin.pdf) en donde se plantean las bases de un sistema
descentralizado con una criptomoneda digital (el Bitcoin o BTC) para evitar el control
financiero por parte de entidades centrales en plena crisis financiera. En esencia, es
como un gigantesco libro de cuentas distribuido (distributed ledger) donde se anotan
todas las operaciones que se realizan.
Este sistema combina varios elementos tecnológicos ya existentes que sumados

dotan al sistema de una gran fiabilidad. Por un lado, está la criptografía. Por otro lado,
las redes distribuidas p2p. Por otro, la Teoría de Juegos. Y, finalmente, la cadena de
bloques o Blockchain que fue descrita originalmente en 1991 bajo el nombre de
Digital Timestamps (Haber, S., Schoot Stornetta, W. (2009). How to Time-Stamp a
Digital Document. https://crl.anf.es/pdf/Haber_Stornetta.pdf). En este documento
se describe un mecanismo para marcar documentos digitales de modo tal que su
manipulación no fuese posible, eliminando la necesidad de un tercero para dar fe.
Tras estos años, Bitcoin se ha convertido en la criptomoneda por excelencia. Veamos

cómo funciona en más detalle.
3
Tema 3. Ideas clave
Bloque de datos
La estructura básica de una red Blockchain es el bloque. Y estos bloques se replican

en todos los nodos de la red.
Un bloque consta de tres elementos principales, de modo esquemático:
 Datos (donde se guardan las transacciones con básicamente tres datos, aunque
luego veremos que hay más información: emisor, receptor y cantidad) incluyendo
un dato especial denominado Merkle Root (que explicaremos después).
 Hash del bloque en curso.
 Hash del bloque anterior.
El primer bloque tiene una estructura especial dado que no tiene bloque anterior y
se denomina con un nombre especial: Bloque Génesis.
Con esta estructura de bloque, si se modifican los datos que forman parte de él, se
modificará su hash. Este es un modo de asegurar si se han modificado o no los datos
del bloque. Y si se cambiaran los bloques anteriores de la cadena, se modificaría el
hash del bloque anterior, con lo que, de facto, se crea una cadena de bloques
haciendo el sistema seguro.
Veamos un ejemplo simplificado, dado que los hashes son de una longitud mucho
mayor:
Tenemos tres bloques:

 Bloque 0. Hash: 3EF3, Hash anterior: 0000, Data: w4AaQxXG5GNN.

 Bloque 1. Hash: BCA3, Hash anterior: 3EF3, Data: 1EUUsg5cKc11hbE.
 Bloque 2. Hash: J6DA, Hash anterior: BCA3, Data: dcdde3EdvmTY.
4
Tema 3. Ideas clave
Si se modificaran los datos del bloque 2 por un atacante, su Hash se recalcularía y
sería:
 Bloque 1’: Hash: CD7f, Hash anterior: 3EF3, Data: 2EuTsg5cKc11hRTA.
Y, por tanto, en el bloque 2 ya no coincidiría el campo Hash Anterior (BCA3) con lo

que la cadena es invalida.
El uso de los hashes permite detectar la manipulación de los bloques, pero no

permite prevenir dicha manipulación, dado que los ordenadores pueden calcular
miles de hashes por segundo y rápidamente podría calcular el hash del bloque actual
y de todos los de los bloques posteriores en su copia de la cadena.
Con objeto de evitar esta manipulación, es necesario introducir un nuevo

mecanismo: el consenso con prueba de trabajo (PoW).
Proof-of-work (prueba de trabajo)
Uno de los problemas principales a los que se enfrenta un sistema descentralizado

como Bitcoin es garantizar, en todo momento, que todos aquellos conectados a la
red compartan un mismo estado de la información (qué transacciones se han
confirmado), sin que existan terceras partes en las que delegar este proceso de
validación.
Adicionalmente, el sistema debe asegurar que el coste necesario para alterar

cualquier información de las transacciones una vez confirmadas por la red sea tan
elevado que la probabilidad de que se plantee este escenario sea prácticamente
imposible.
Con el objetivo de conseguir ambas propiedades, Bitcoin utiliza una combinación de

criptografía y Teoría de Juegos, implementando un mecanismo de consenso en redes
descentralizadas denominado prueba de trabajo (proof of work).
5
Tema 3. Ideas clave
Para que un bloque nuevo sea aceptado por la red y se incorpore a la cadena de
bloques debe incluir el hash del bloque anterior y, además, el hash de la cabecera del
bloque (que se obtiene calculando el hash SHA256 de los datos que la componen) y
debe cumplir una condición: ser inferior a la dificultad establecida por la red (que
depende de la capacidad de computacional global).
Una vez establecidos los valores de la cabecera del bloque y calculado el Merkle Tree
correspondiente a las transacciones, se itera sucesivamente el valor del campo nonce
(32 bits) del bloque para obtener distintos hashes hasta encontrar un resultado que
empiece por el número de ceros requerido con base en la dificultad establecida.
Puesto que cualquier cambio en los datos de la cabecera genera un hash diferente y
es imposible predecir qué combinación de los datos de la cabecera generarán una
salida válida, los mineros necesitan probar muchos nonce diferentes hasta encontrar
una solución válida (puede suceder, incluso, que ningún nonce ofrezca un resultado
válido, en cuyo caso es necesario modificar algún campo de las transacciones para
empezar nuevamente el proceso de iteración del nonce).
El cálculo de la dificultad se ajusta de forma automática para garantizar que este

proceso dure, de media, diez minutos, por lo que la creación de bloques se ralentiza,
no es inmediata. El valor se establece en función del tiempo que se ha tardado en
generar los últimos 2016 bloques: si la media ha sido inferior a diez minutos (porque
la capacidad computacional de la red se ha incrementado) la dificultad aumenta,
mientras que si ha sido superior a diez minutos (porque la capacidad de la red ha
bajado) la dificultad disminuye. Cada 2016 bloques (dos semanas, aproximadamente)
los nodos de la red recalculan la dificultad de la prueba de trabajo para mantener las
condiciones establecidas y garantizar el funcionamiento de este mecanismo de
consenso.
Puesto que el proceso de PoW requiere un consumo de recursos proporcional a la

capacidad global de la red, un minero malicioso que quiera alterar la información
previamente registrada en la cadena de bloques (eliminando una transacción, por
ejemplo) deberá disponer de una capacidad computacional superior al resto de la red
6
Tema 3. Ideas clave
para recalcular el hash de dicho bloque pasado (ya que al eliminar la transacción el
Merkle Tree se ve modificado y el hash original del bloque se invalida), así como de
los hashes de todos los bloques posteriores (puesto que el hash de cada bloque
previo se incluye como parámetro en la cabecera y, por tanto, modificar el hash de
un bloque pasado invalida los hashes de los bloques sucesivos) y, además, debe
contar con todo esto antes de que otro minero genere un nuevo bloque que sea
aceptado por la red. Es por ello por lo que este mecanismo trata de prevenir la
manipulación.
Dado que los mineros obtienen un rendimiento económico cuando encuentran un

bloque válido y lo distribuyen a la red (la primera transacción que un minero incluye
en el bloque, denominada coinbase, así como las comisiones de las transacciones
incluidas en el bloque), quien tuviera la capacidad computacional suficiente para
poder alterar algún bloque en el pasado se vería incentivado a seguir las reglas y a
generar bloques válidos porque obtendría mayor rendimiento.
La mayoría de las criptomonedas implementan mecanismos de consenso de tipo PoW

(modificando el cálculo a realizar con distintos algoritmos, en lugar de utilizar
SHA256, como en el caso de Bitcoin) aunque existen otros mecanismos de consenso,
entre los que destaca proof of stake (prueba de posesión) que veremos más adelante.
Funcionamiento de Bitcoin
Para enviar una cantidad determinada de Bitcoins de un usuario a otro, el usuario

dispone de una billetera (o wallet) que debe generar una transacción que contendrá
un conjunto de entradas correspondientes a transacciones previamente generadas
hacia direcciones gestionadas por dicho wallet y que no se han gastado todavía
(Unspent Transaction Outputs o UTXOs), y un conjunto de transacciones de salida

(típicamente, una hacia la dirección del wallet que recibirá la transferencia y otra
hacia una dirección del wallet que genera la transacción).
7
Tema 3. Ideas clave
Un ejemplo de este tipo de transacciones simples es el siguiente, con txid
1119a54199934b788945dfa0004b1e317d5c333419017591a8caf70676473984 en la
que se observa una transacción de entrada de la dirección
1EUUsg5cKc11hbEZNDd61BzE9ffEQJQ9Mj (por valor de 0.00616874 BTC) y dos
transacciones de salida, una por valor de 0,00001 BTC hacia la dirección
1NUsMt7jFCzw7ewKcKh5mww4AaQxXG5GNN y otra de 0.00515874 BTC hacia la
dirección de origen, 1EUUsg5cKc11hbEZNDd61BzE9ffEQJQ9Mj (el «cambio» de esta
transacción, ya que el importe de una transacción de entrada no se puede fraccionar).
La diferencia entre el importe de las transacciones de entrada (una en este caso, pero
pueden ser más) y la suma de los importes de las transacciones de salida, 0.001 BTC
en esta transacción en particular, se contempla como comisión para los mineros que
incorporan esta transacción en un nuevo bloque.
Figura 1. Ejemplo de transacción con una entrada y dos salidas (incluyendo la dirección de cambio).
Fuente: Blockchain.info
En el caso de que las direcciones gestionadas por el wallet no resulten suficientes de

modo individual para componer el importe enviado, la aplicación seleccionará varias
entradas cuyas sumas alcancen la cantidad requerida.
Además de esta información, la transacción incluye información adicional, en forma

de scripts (que comentaremos en la próxima sección):
 Entrada: las pruebas de que el wallet que genera la transacción posee la clave
privada que permite a la red verificar que es el legítimo propietario de los bitcoins
correspondientes a cada una de las transacciones de entrada (y, por tanto, se le
permite utilizarlas para componer una nueva transacción)
 Salida: los retos que únicamente el propietario de la clave privada correspondiente
a cada una de las transacciones de salida podrá resolver para garantizar que
8
Tema 3. Ideas clave
únicamente los destinatarios de estas transacciones puedan disponer de los
fondos enviados para generar nuevas transacciones.
El siguiente diagrama representa el encadenamiento de transacciones que se realiza

en bitcoin, donde los outputs no gastados (UTXO) se convierten en inputs de nuevas
transacciones.
Figura 2. Encadenamiento de outputs como inputs de nuevas transacciones Fuente: bitcoin.org
Para que las transacciones generadas por los wallets sean aceptadas y se permita al
destinatario utilizar los bitcoins recibidos como entrada de una nueva transacción,
deben haber sido incorporadas en una estructura de datos (en forma de cadena de
bloques) replicada en todos los nodos que componen la red. Estos bloques,
generados por los mineros, deben cumplir una serie de condiciones para ser
considerados válidos.
9
Tema 3. Ideas clave
En un bloque en construcción los mineros añadirán aquellas transacciones
pendientes de confirmación, priorizando habitualmente por comisión (puesto que el
minero que consiga generar el bloque se apuntará, además de una cantidad fija de
12,5BTC en la actualidad, la suma de todas las comisiones de las transacciones
incluidas).
Además de esta información, los bloques contienen una cabecera que incluye el
merkle root de las transacciones incluidas en dicho bloque (la raíz de un árbol que
contiene los hashes de todas las transacciones, de forma que cualquier modificación
en cualquiera de las transacciones provoca una alteración del merkle root), así como
el hash del bloque previo y una serie de valores (versión, timestamp, dificultad y
nonce).
Figura 3. Relación de cada bloque con el hash del bloque anterior en Bitcoin. Fuente: bitcoin.org
BIP o cómo evoluciona el Bitcoin
Bitcoin no es una red estática, sino que ha tenido varias evoluciones y rupturas en su
cadena. Para poder gestionar las mejoras que la comunidad va necesitando se

estableció un mecanismo de trabajo. El documento inicial que describe dicho
procedimiento es el Bitcoin Improvement Proposal (BIP), creado inicialmente por
10
Tema 3. Ideas clave
Amir Taaki el 19 de agosto de 2011 basándose en los Python Enhancement Proposals
(PEP), siendo posible elevar BIP de tres tipos diferentes:
 Standards track (o normativos): se usan para describir cambios que afectan a todas
o a la mayoría de las diferentes implementaciones de Bitcoin tales como
protocolo, consenso, etc. Ejemplo reciente es el BIP-141 (SegWit) que veremos
más en detalle posteriormente.
 Informativos: se usan para describir pautas, recomendaciones para la resolución
de problemas de diseño de la red. Su implementación es opcional.
 Proceso: igualmente opcional, se usan para definir procedimientos de uso de las
herramientas de la comunidad.
Los BIP para implementar deben incluir no solo la documentación técnica detallada
(que servirá inicialmente de base para la discusión en la comunidad), sino también
los códigos de prueba y toda la documentación que permita a los desarrolladores
realizar las modificaciones necesarias en el código cliente de la red.
Dado que deben ser consensuados por una amplia mayoría de miembros de la
comunidad, el proceso consta de diversas fases y estados:
 Presentación a la comunidad (con los estados Draft).

 Propuesta a la comunidad (con los estados Proposed, Withdrawn y Deferred).
 Aceptación (con el estado final).
Fruto de estos BIP, han surgido mejoras reseñables que veremos a continuación,
como los SegWit blocks (Segregate Witness) o el Lightning Network.
Funcionamiento del Bitcoin Scripting
Las transacciones en Bitcoin incorporan un lenguaje denominado script que permite

programar las condiciones que deben cumplirse para poder hacer uso de los inputs.
11
Tema 3. Ideas clave
Este lenguaje es limitado (no turing completo), lo cual evita la posibilidad de que se
establezcan bucles con el fin de asegurar que no sea posible generar transacciones
maliciosas que puedan provocar ataques de denegación de servicio en la red. La
simplicidad del lenguaje permite, además, el procesamiento eficiente de las
transacciones en cualquier tipo de dispositivo.
Interpretar el código de un script implica ir introduciendo en una pila los valores que
se definan en el código y ejecutar operaciones para actuar sobre los datos existentes
en la pila, meter o sacar uno o más valores de la pila o introducir nuevos valores
generados tras realizar una operación. Al finalizar la ejecución del script, este se
considera válido si el contenido final en la pila es TRUE (y no válido en cualquier otro
escenario).
El lenguaje ofrece un conjunto de operaciones, cada una de las cuales se representa

por un identificador OP_<nombre_operacion>. El listado puede consultarse en
https://en.bitcoin.it/wiki/Script.
Como ejemplo, el siguiente script utiliza el operador OP_ADD para sumar los dos
valores situados en las posiciones superiores de la pila y verificar, posteriormente, si
el resultado es igual a 7 con el operaor OP_EQUAL, devolviendo TRUE al final de la
ejecución (y, por tanto, resultando un script válido).
2 5 OP_ADD 7 OP_EQUAL
12
Tema 3. Ideas clave
La secuencia sería la siguiente e indica a la izquierda el estado de procesamiento del
script, el detalle de la acción a realizar y el contenido de la pila tras la acción:
SCRIPT DESCRIPCIÓN PILA
2 5 OP_ADD 7 OP_EQUAL Se añade el valor 2 a la pila. 2
5 OP_ADD 7 OP_EQUAL Se añade el valor 5 a la pila. 25

Se sacan los dos valores superiores de la
OP_ADD 7 OP_EQUAL pila, se suman y se inserta el resultado. 7
7 OP_EQUAL Se añade el valor 7 a la pila. 77

Se sacan los dos valores superiores de la
pila, se comparan y se inserta OP_TRUE en
OP_EQUAL caso de que sean iguales. True
Tabla 1. Secuencia de ejecución del script, indicando el contenido de la pila.
El mecanismo de validación de las transacciones en Bitcoin se basa en dos tipos de

script:
 Script de bloqueo (históricamente denominado scriptPubKey): establece las

condiciones requeridas para gastar un output.
 Script de desbloqueo (históricamente denominado scriptSig): satisface las
condiciones establecidas en el locking script y permite, por tanto, gastar el output.
Para validar una transacción los nodos de la red evaluarán secuencialmente ambos
scripts. Si el resultado final es TRUE, la transacción será considerada válida. Esta
operación se realizará para cada uno de los inputs que formen parte de la transacción.
Los scripts más habituales en Bitcoin (que no los únicos) son los siguientes:
P2PKH (pay-to-public-key-hash)
El script de bloqueo asigna el output a una dirección generada a partir de una clave
pública. El script de desbloqueo contiene la clave pública y una firma digital creada
13
Tema 3. Ideas clave
por la correspondiente clave privada, de forma que solo el poseedor de dicha clave
podrá aportar la información necesaria para validar la transacción.
 Script de bloqueo (scriptPubKey)

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
 Script de desbloqueo (scriptSig)
<sig> <pubkey>
SCRIPT DESCRIPCIÓN PILA

<sig> <pubKey> OP_DUP OP_HASH160 scriptSig y
<pubKeyHash> OP_EQUALVERIFY scriptPubKey
OP_CHECKSIG combinados
OP_DUP OP_HASH160 <pubKeyHash> Se añaden los valores
OP_EQUALVERIFY OP_CHECKSIG a la pila <sig> <pubKey>
OP_HASH160 <pubKeyHash> Se duplica el valor
OP_EQUALVERIFY OP_CHECKSIG superior <sig> <pubKey> <pubKey>
Se calcula el hash del
<pubKeyHash> OP_EQUALVERIFY elemento superior de
OP_CHECKSIG la pila <sig> <pubKey> <pubHashA>
Se añade el valor <sig> <pubKey> <pubHashA>
OP_EQUALVERIFY OP_CHECKSIG pubKeyHash a la pila <pubKeyHash>
Se comprueba si los
dos valores
superiores son
OP_CHECKSIG iguales <sig> <pubKey>
Se verifica la firma de
los valores
superiores,
obteniendo true, por
lo que la transacción
es válida true
Tabla 2. Secuencia de ejecución del script, indicando el contenido de la pila.
14
Tema 3. Ideas clave
P2PK (pay-to-public-key)
Es una forma obsoleta del script anterior, donde se especifica la clave pública (en
lugar del hash). Actualmente se utiliza P2PKH en su lugar.

<K_pub> OP_CHECKSIG
<firma_k>
P2M (pay-to-multisig)
Los scripts de multifirma permiten condicionar el bloqueo a la presentación de un

conjunto mínimo de N firmas en el script de desbloqueo, que estén relacionadas con
M claves públicas establecidas en el script de bloqueo (con M>=N) y sean presentadas
en el mismo orden. El límite está establecido en 16 claves públicas.
<M> <KA_pub> [KB_pub] ... [KM_pub] <N> OP_CHECKMULTISIG
OP_0 <firmaA_k> <firmaB_k> ...
P2SH (Pay-to-script-hash)
Este tipo de scripts permiten simplificar y reducir el tamaño de transacciones

complejas, como el caso de P2M (lo que evita errores y reduce el coste). El script se
sustituye por su hash, generándose una dirección que empieza por 3 (en lugar de
empezar por 1, como es el caso de las direcciones estándar).
Para desbloquear el output se requiere presentar el script de bloqueo que genera ese
hash y el correspondiente script de desbloqueo.

OP_HASH160 <RIPEMD-160(SHA 256(script de bloqueo))> <OP_EQUAL>
15
Tema 3. Ideas clave
<script de desbloqueo> <script de bloqueo>
SegWit
SegWit es la contracción de Segregated Witness o testigo segregado, y es un cambio

técnico de protocolo desarrollado en 2015 y especificado en el BIP-141 sobre el
formato de transacciones del Bitcoin. Se basa en la segregación de las firmas de los
testigos intervinientes de las transacciones convirtiéndolos en opcionales y no
necesarios para la firma del bloque. Se ha implementado como un Soft Fork en 2017
por lo que hay nodos con y sin esta funcionalidad y funcionando conjuntamente sin
afectar a la red en su conjunto.
Es una de las grandes mejoras que ha sufrido Bitcoin desde sus inicios y, tal vez, la
más transformadora. Con ella, se buscaba resolver dos problemas: por un lado,
resolver el problema de maleabilidad de las transacciones y, por otro, mejorar la
escalabilidad y rendimiento de la red. Aquí debemos tener en cuenta que, en los
últimos años, el número de transacciones en bitcoin ha crecido exponencialmente y
Bitcoin tan solo era capaz de manejar siete u ocho transacciones por segundo por lo
que era incapaz de manejar ese número en un tiempo adecuado.
El funcionamiento es simple: se separan las firmas y los códigos de ejecución (los

Bitcoin Script) en un bloque separado, pero manteniendo la integridad de todo el
conjunto con los árboles Merkle Root.
16
Tema 3. Ideas clave
Figura 4. Funcionamiento de Segwit. Fuente: https://coingeek.com/what-the-fork-happened-to-bitcoin/
El problema de maleabilidad está relacionado con que los hashes de firma de Bitcoin
no protegen el script de firma (scriptSIg). Este script incluye un tipo de firma especial
(secp256k1) que no se puede autofirmar. Además, el TxID de las transacciones no
confirmadas puede ser modificado, por lo que un tercero malicioso podría
sobrescribirlo. Veremos un apartado posterior la estructura más en detalle.
En relación con la escalabilidad, en la mejora SegWit se aumenta el tamaño del

bloque de 1MB a 1,8MB lo que redunda en un mayor número de transacciones por
bloque y, por tanto, mayor escalabilidad. En el documento del diseño, incluso se
permite subir a 4MB.
Otro punto importante de SegWit es la creación de nuevas direcciones que empiezan

por «bc1» para SegWit nativo o «3».
También habilita que un usuario con un wallet SegWit pueda mandar moneda a un
monedero legacy, lo que resulta en una confirmación más rápida y a menor coste.
Por último, SegWit abre la puerta a la creación de la Lightning Network que habilita
un mayor rendimiento de la red Bitcoin.
17
Tema 3. Ideas clave
Progresivamente, se ha incrementado el número de transacciones SegWit en la red
de Bitcoin, superando el 80 % en julio de 2021.
Figura 5. Porcentaje de transacciones SegWit. Fuente: transactionfee.info
P2WPKH (pay to witness public key hash)
La introducción de SegWit (segregated witness) ha modificado el formato tradicional

de una transacción. Para ello, como veíamos antes, la transacción se divide en dos
segmentos, eliminando el script de desbloqueo (que habitualmente incluye la firma,
que supone el dato de mayor tamaño) de su ubicación original y añadiéndola como
una estructura separada, al final.
Es decir, sustituye la información que se recogía en el scriptSig para demostrar la

posesión de la transacción de entrada a un nuevo espacio denominado witness.
18
Tema 3. Ideas clave
La firma contiene la misma información que en el caso de una transacción P2PKH,
pero ubicada en esta parte de la transacción, en lugar del scriptSig:
Elemento Script
Script de bloqueo 0 <pubKeyHash>
Script de desbloqueo Vacío
DUP HASH160 [20-byte

Script Code
hash160(<pubkey>] EQUALVERIFYCHECKSIG
Witness <sig> <pubkey>
Tabla 3. Características de una transacción P2WPKH.
Las transacciones así generadas son compatibles hacia atrás, por lo que la
implementación de este cambio pudo ser abordada como un soft fork. Los nodos que
no han actualizado todavía para soportar Segwit aceptarán la transacción como
válida, mientras que los nodos que sí soportan segregated witness interpretarán el
primer valor como la versión de Segwit y el segundo valor como el script a validar.
Estos nuevos nodos necesitan también la firma para verificar la transacción (de forma
similar a una transacción tradicional P2PKH). Esta información está contenida en la
sección witness en lugar de en el scriptSig (que está vacío).
LIghtning Network y los canales de pago
Con la introducción de SegWit se habilitaba la posibilidad de tener protocolos de

segunda capa sobre una Blockchain. Lightning Network es un protocolo de estos
protocolos de segunda capa que opera sobre Bitcoin. Su misión es permitir

confirmar más transacciones en menos tiempo. Estas transacciones se agrupan en un
proceso off-chain y se almacenan para que la red principal las procese
posteriormente.
19
Tema 3. Ideas clave
La Lightning Network consta de más de 20.000 nodos en mayo de 2021 y sigue
creciendo a un ritmo superior al 10 % mensual. Y no es exclusiva de Bitcoin.
Los canales de pago o payment channels son el elemento clave de la Lightning

Network. Un canal de pago es, dicho en otras palabras, una transacción multifirma
grabado en la Blockchain con una de las transacciones, al menos, realizando un envío
de fondos. Para asegurar la integridad, se implementa un doble control de seguridad
denominado Hash Timelock Contract (HTLC).
La primera parte, HashLock, es una condición aplicada a la transacción. En dicho

canal, cada persona tiene una clave privada y cada transacción futura podrá realizarse
únicamente si las claves de las dos partes firman. Esto como un medio de consenso
de que la transacción ha sido aprobada para ejecutarse por ambas partes.
La segunda parte, TimeLock, se implementa como un control de tiempo en el que el

canal puede estar abierto, normalmente diez minutos o hasta siguiente minado de
bloque. Pero ninguno puede disponer de los fondos hasta que el control de tiempo
se cumpla.
Cuando el canal se abre, los participantes pueden intercambiar activos entre ellos de
forma instantánea utilizando los fondos almacenados en dicho canal. Cuando el canal
se cierra, el balance final de las transacciones realizadas se emite a la red, se realiza
la verificación y se incluyen en un bloque Bitcoin, lo que denominamos transacciones
multifirma.
Durante el tiempo que el canal está abierto, todas las transacciones que se realizan
dentro de dicho canal son inmediatas, se pueden hacer por un único Satoshi
(0.00000001 BTC) y no llevan coste de comisión de transacción, siendo únicamente

necesario posteriormente realizar un pago de BTC como comisión por crear por la
creación del canal y por el cierre, y por una única transacción final sobre la Blockchain
principal.
20
Tema 3. Ideas clave
Figura 6. Los nodos ACFKLQ construyen un canal que habilita el pago de A a Q de modo seguro en la red.
Fuente: https://en.wikipedia.org/wiki/Lightning_Network
Visto esto, está claro que la Lightning Network es muy útil para realizar micropagos
y para mantener privacidad adicional, ya que solo los participantes en el canal saben
las transacciones que se han producido internamente. Aunque como inconveniente,
solo se pueden hacer dichos pagos a personas conectadas (no existe el concepto
similar a una transferencia bancaria tradicional).
Es importante mencionar que, para abrir un canal, los participantes deben dejar
fondos bloqueados en depósito con un esquema en el que se necesitan dos firmas
para poder firmar y mover los fondos.
Taproot
Taproot es el primer gran cambio a Bitcoin después de cuatro años tras la activación
de SegWit en 2017. Esta propuesta fue formulada en enero de 2018 y su activación
se realiza en el bloque 709.632 a finales de 2021 como un soft fork. Con su

introducción se mejoran dos cosas: privacidad y escalabilidad. En privacidad, porque
enmascara las transacciones complejas multifirma como si fueran transacciones
sencillas, y en escalabilidad, porque se simplifica el proceso de validación de
21
Tema 3. Ideas clave
transacciones y permite añadir más transacciones por bloque. Y para hacer todo esto,
Taproot modifica el funcionamiento de los scripts de Bitcoin.
Para conseguir este propósito se han realizado dos Mejoras: BIP-114 (Merklelized
Abstract Syntax Tree o MAST) y BIP-340 (Firmas Schnorr). Y la implementación se ha
basado en tres BIP: BIP-340, BIP-341 (Taproot) y BIP-342 (TapScript).
BIP-114 Merklelized Abstract Syntax Tree
Combina los Merkle Tree para ofrecer seguridad de no modificación de las

transacciones dentro de su estructura sin cambiar el estado final, pudiendo detectar
manipulaciones de modo sencillo y, por tanto, reduciendo el espacio necesario para
almacenamiento; y los árboles de sintaxis abstracta (AST) es un proceso que
mediante un algoritmo aumenta la ocultación de información, mediante un proceso
de división en múltiples secciones de información permitiendo al mismo tiempo
mejorar su clasificación sin necesidad de hacer públicos todos los datos que
contienen y, por tanto, haciendo más rápido su acceso. Los datos solo se revelan
cuando son necesarios para la condición que se cumple cuando se hace una
transacción.
Al unir estos dos elementos, se puede incluir información compleja en Bitcoin sin
tener que revelar públicamente los datos y disminuyendo el espacio necesario,
abriendo la puerta al diseño de smart contracts más complejos, seguros y eficientes.
BIP-340 Firmas Schnorr
Es un esquema de firma criptográfica que genera firmas más cortas que el actual de
firma elíptica (ECDSA) y que es código abierto desde 2018. Permite incorporar varias
claves dentro de una única transacción compleja y generar una única firma Schnorr,
por lo que se mejora la privacidad por un lado y reduce el coste de la transacción.
22
Tema 3. Ideas clave
Figura 7. Esquema de firmas ECDSA. Fuente: elaboración propia.
Figura 8. Esquema de firmas Schnorr. Fuente: elaboración propia.
BIP-342 Tapscript
Con este BIP, se incorpora un nuevo tipo de programación que habilita, por un lado,
un pago único denominado Pay-to-Taproot (P2TR) que permite al usuario realizar
bien pago con firma pública Schnorr o con múltiples firmas, o bien permite al usuario
realizar transacciones públicas o privadas según su caso de uso.
23
Tema 3. Ideas clave
BIP-341 Taproot
Es el cambio que determina la funcionalidad y que contiene los scripts que los
mineros han ido adoptando durante los meses anteriores a su entrada en
funcionamiento en la red global para habilitar tanto TapScripts como Firma Schnorr.
3.2. Ethereum y su Virtual Machine EVM
Origen de Ethereum
Ethereum es la segunda plataforma Blockchain más conocida. Fue creada por Vitalik
Buterin a finales de 2014 y se convirtió en operativa en 2015.
El objetivo inicial de Buterin fue permitir a los programadores crear y ejecutar

aplicaciones descentralizadas con smart contracts sobre una cadena de bloques. La
realidad es que se ha convertido de facto en la red Blockchain programable más
grande a nivel mundial.
Para poder ejecutar estos smart contracts, la red Ethereum cuenta una
criptomoneda propia, el Ether (ETH), que también puede servir para realizar pagos
entre individuos como Bitcoin. Por tanto, el Ether tiene la doble función de
recompensa para los mineros y de incentivo a los programadores para hacer
programas de calidad que no consuman demasiado.
Smart contract
Ethereum permite, como hemos comentado, la ejecución de programas

denominados smart contracts (en lenguajes como Solidity) que, tras ser compilados,
son desplegados en la red generando una transacción que contiene el bytecode
correspondiente. Una vez minada esta transacción, es posible interactuar con el
24
Tema 3. Ideas clave
smart contract generando transacciones a la dirección asignada por el minero que
registra el contrato en la cadena de bloques de Ethereum, en las que se identifican
las funciones a invocar y los parámetros que se pasan como argumentos
(https://github.com/ethereumbook/ethereumbook/blob/develop/evm.asciidoc).
El término «smart contract» fue usado por primera vez en: Szabo, N. (1997).
Formalizing and Securing Relations on Public Networks. First Monday.
http://firstmonday.org/ojs/index.php/fm/article/view/548/469
Ethereum Virtual Machine
Los nodos de la red utilizan una máquina virtual (EVM o Ethereum Virtual Machine)
para ejecutar el bytecode existente y generar el resultado correspondiente. Desde un
punto de vista práctico, la EVM puede entenderse como un enorme ordenador
descentralizado que contiene millones de objetos.
Podríamos comparar su funcionamiento con la JVM (Java Virtual Machine), diseñada

para disponer de un entorno de ejecución independiente del sistema operativo que
permite desarrollar programas en Java independientes del entorno en que se
ejecutarán. Estos programas, una vez compilados, generan un bytecode que puede
ser interpretado mediante la JVM en cualquier entorno, sin tener que realizar
cambios en el programa.
El lenguaje de la EVM se divide en distintos grupos de instrucciones (operaciones

aritméticas, lógicas, de control, de acceso a memoria, etc.). Además de estas
instrucciones, la EVM permite gestionar información de las cuentas en Ethereum
(dirección, balance, etc.), así como otros parámetros de la red (como el precio del
gas, información de los bloques, entre otros).
El listado de Opcodes disponible puede consultarse en el Yellow Paper de Ethereum:

https://ethereum.github.io/yellowpaper/paper.pdf
25
Tema 3. Ideas clave
De la misma forma que en un ordenador la CPU gestiona el estado de los procesos en
ejecución, la EVM gestiona el estado de distintos componentes para procesar una
transacción. El estado de esos componentes determina el nivel de cambios que se
realizarán en la cadena de bloques.
Funcionamiento básico de Ethereum 1.0
Más adelante se verá con más detalle el funcionamiento de esta red, pero podemos
entender Ethereum como una máquina de estados con los siguientes elementos:
 Estado del mundo (world state): relaciona direcciones con el estado de las cuentas,
manteniendo la información en una estructura de datos de tipo Merkle Patricia
Tree que garantiza la imposibilidad de alterar la información.
 Estado de las cuentas (account state): cada cuenta contiene los parámetros
mencionados a continuación.
• Nonce: valor que representa el número de transacciones enviadas desde la
cuenta.
• Balance: número de wei que posee la cuenta.
• StorageRoot: un hash del nodo raíz del Merkle Patricia Tree.
• CodeHash: un hash inmutable del código de la EVM para esa cuenta.
 Estado de almacenamiento (storage state): información específica sobre el estado

de la cuenta mantenida en tiempo real por la EVM.
 Información de bloque: los parámetros que incluye son enumerados a

continuación.
• Hash del último bloque completado.

• Timestamp del bloque.
• Número de bloque.
• Dificultad actual.
• Límite de gas.
26
Tema 3. Ideas clave
 Información de runtime para gestionar las transacciones:
• Precio del gas, especificado por quien origina la transacción.
• Tamaño de la transacción.
• Dirección correspondiente a la cuenta ejecutando la transacción.
• Dirección de origen de la transacción.
Los cambios de estado se calculan mediante las siguientes funciones:
 Ethereum State Transition Function: utilizada para calcular un estado válido de la

transacción.
 Block Finalization State Transition Function: utilizada para determinar el estado de
un bloque finalizado, como parte del proceso de minería (incluyendo la
recompensa del bloque).
 Block Level State Transition Function: el estado resultante de la función anterior
aplicado al estado de la transacción.
Merkle Tree en Ethereum
En las cabeceras de los bloques de Ethereum se incluyen varios Merkle Tree para
distintos tipos de objetos:
 Transacciones.
 Recibos (receipts): que reflejan el efecto de cada transacción.
 Estados.
El tipo de Merkle Tree utilizado en Ethereum (denominado Merkle Patricia Tree) es

más complejo que el utilizado en Bitcoin y está diseñado para optimizar el espacio
consumido y facilitar las operaciones de inserción y borrado (PATRICIA es la sigla de
Practical Algorithm To Retrieve Information Coded In Alphanumeric).
Una estructura del tipo Patricia Tree permite almacenar cualquier par clave-valor y
garantizar mediante la utilización de hashes la autenticidad de la información, pero a
27
Tema 3. Ideas clave
diferencia de los Merkle Tree binarios existen varios tipos de nodos (lo que permite
reducir el espacio necesario, a costa de una mayor complejidad en la navegación por
el árbol):
 Extensión (extension): utilizado cuando existe un prefijo común.

 Hoja (leaf): utilizado cuando existe un sufijo único.
 Rama (branch): el mismo tipo de nodo que en un Merkle Tree binario.
Compilación de código en Solidity a bytecode
Para compilar código en Solidity y obtener el bytecode que puede ser interpretado
por la EVM se utiliza la línea de comandos. Por ejemplo, para compilar el fichero
“Example.sol” generando el bytecode resultante en el directorio
“BytecodeOutputDir” se ejecutaría la siguiente sentencia:
$ solc -o BytecodeOutputDir --opcodes Example.sol
La siguiente sentencia generaría el binario del bytecode para el programa de ejemplo:
$ solc -o BytecodeOutputDir --bin Example.sol
El resultado generado depende de los parámetros especificados en el código de

Solidity, donde la primera línea establece la versión que deberá contemplarse en la
compilación (para garantizar que el funcionamiento se mantenga invariante en el
tiempo, independientemente de los cambios que puedan realizarse sobre la versión
de Solidity). Por ejemplo, la siguiente línea indicará al compilador que el código se ha
definido para la versión 0.4.19 (y deberá compilarse siguiendo dicha versión).
pragma solidity ^0.4.19;
28
Tema 3. Ideas clave
Una vez compilado, es posible observar el bytecode generado correspondiente al
contrato en Solidity. Abriendo el fichero correspondiente con un editor
observaremos algo similar a lo siguiente:
PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH1 0xE JUMPI PUSH1 0x0
DUP1 REVERT JUMPDEST CALLER PUSH1 0x0 DUP1 PUSH2 0x100 EXP DUP2 SLOAD
DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND
SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR
SWAP1 SSTORE POP PUSH1 0x35 DUP1 PUSH1 0x5B PUSH1 0x0 CODECOPY PUSH1
0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE PUSH1 0x0 DUP1 REVERT STOP
LOG1 PUSH6 0x627A7A723058 KECCAK256 JUMP 0xb9 SWAP14 0xcb 0x1e 0xdd
RETURNDATACOPY 0xec 0xe0 0x1f 0x27 0xc9 PUSH5 0x9C5ABCC14A NUMBER 0x5e
INVALID EXTCODESIZE 0xdb 0xcf EXTCODESIZE 0x27 EXTCODESIZE 0xe2 0xb8 SWAP10
0xed 0x
Gas en Ethereum: ejecución del bytecode en la EVM
Uno de los aspectos más relevantes a entender en Ethereum es el concepto del gas.
Cada transacción tiene asociado un gas limit y un gas price que condiciona las
comisiones que resultarán de la ejecución en la EVM. Estas comisiones permiten
compensar a los mineros por el coste computacional de ejecutar el código. El gas
permite también la creación de cuentas y smart contracts.
A diferencia de Bitcoin, Ethereum es Turing completo, lo que, entre otros aspectos,

permite la generación de bucles. El mecanismo que permite evitar bucles infinitos en
Ethereum es el gas, que aplica en varios aspectos:
 Los bloques minados en Ethereum tienen un gas límite asociado, de forma que el
gas total utilizado por las transacciones en el bloque no puede superar dicho
límite.
29
Tema 3. Ideas clave
 Puesto que existe un coste asociado al gas, a mayor complejidad en una
transacción, mayor será su coste (lo que limita económicamente la posibilidad de
ataques).
Herramientas para análisis del bytecode
Desensamblar el bytecode es una buena forma de entender cómo la EVM interpreta

el código desarrollado con Solidity. Existen distintos desensambladores que permiten
hacerlo:
 Porosity: https://github.com/comaeio/porosity
 Ethersplay (plugin para el desensamblador Binary Ninja):
https://github.com/trailofbits/ethersplay
 IDA-Evm (plugin para IDA, otro desensamblador):
https://github.com/trailofbits/ida-evm
EIP o cómo evoluciona Ethereum
Ethereum no fue creado como una plataforma final terminada y cerrada. Al contrario,
se basa desde sus inicios en ser un código abierto con aportaciones de la comunidad,
aunque controlado en última instancia por un grupo reducido que vela por su
integridad.
La comunidad de programadores, cualquier programador, realiza estas aportaciones

mediante la solicitud de un Ethereum Improvement Proposal (EIP), o propuesta de
mejora de Ethereum en castellano, a través de un mecanismo definido en el
repositorio de Ethereum y que fue inicialmente especificado en la EIP-1 el 27 de
octubre de 2015. Estos EIP son discutidos por la comunidad y, una vez debatidos y
aceptados por la comunidad, se incorporan a la plataforma asegurando de este
modo que se van adoptando mejoras al uso y funcionamiento de la red y son uno de
los elementos clave de asegurar que los cambios ocurran en la red y que sean
aceptados por una amplia mayoría de usuarios.
30
Tema 3. Ideas clave
Un EIP es, formalmente, un documento técnico de diseño para proporcionar
información al resto de la comunidad, describiendo características y procesos, y
estructurado según las reglas definidas en el ya mencionado EIP-1. El proponente es
el responsable de crear consenso en la comunidad para su admisión. La
documentación técnica debe ser muy concisa para asegurar que es bien entendida y
las opiniones en contra deben ser también incorporadas y bien documentadas.
Los EIP no son una idea original de Ethereum, sino que se basan en la experiencia de
las BIP (Bitcoin Improvement Proposals) que a su vez se basan en las Python
Improvement Proposals.
Cada nueva actualización de la red incorpora un conjunto de EIP que deben ser
implementados en todos los clientes Ethereum de la red siendo pues la unidad
mínima de gobernanza.
Los EIP se agrupan en categorías:
 Estándar (Standar Track EIP): que son los usados para los cambios globales en el
protocolo de red o en el consenso o en los estándares. Se subdividen en:
• Básico (core): que buscan mejorar el consenso dentro de Ethereum como los
EIP-5 y EIP-101, así como otras mejoras varias al sistema como el EIP-86 o EIP-
90.
• Redes (networking): que buscan mejorar el protocolo de red bien el devp2p
(EIP-8) o el Light Ethereum Subprotocol, Whisper o Swarm.
• Interfaz (interface): relativos a las especificaciones y estándares de API/RPC del
cliente Ethereum, como puede ser el EIP-6.
• ERC (Ethereum request for comments): relativos a los estándares y
convenciones de nivel aplicación, y que se incluyen en los contratos, como

pueden ser los ERC-20 (Token Standard), ERC-721 (Token NFT), ERC-1155
(MultiToken) de creación de tókenes; los ERC-26 de nombres, el ERC-67 de
esquema de URI; los de billetera EIP-75 o EIP-85; y los de biblioteca como el
EIP-82.
31
Tema 3. Ideas clave
 MetaEIP: son los usados para describir procesos generales, como el propio EIP-1
que definía la composición y uso de un EIP.
 Informativos: dan pautas generales de uso a la comunidad Ethereum y son los
únicos que no tienen necesariamente el consenso de la comunidad, por lo que no
son de obligado cumplimiento.
El proceso que se sigue para la aceptación de un EIP es el siguiente:
Figura 9. Fuente: https://github.com/ethereum/EIPs/blob/master/assets/eip-1/EIP-process.png
Básicamente, este ciclo consta de cinco fases:
 La primera etapa es la presentación de la idea (idea) a la comunidad para obtener

un primer feedback de ella y seguir o no con su desarrollo.
 La segunda etapa es el desarrollo de la propuesta. En esta parte, tenemos una
primera etapa de borrador (draft) donde las propuestas se generan ya en un
formato más conciso según la plantilla de EIP y están aún en proceso de creación
por los autores sin visibilidad a la comunidad y, al alcanzar una madurez aceptable,
se muestran visibles para la comunidad (review) donde se puede seguir
incorporando cambios por la comunidad que puede aportar ideas o sugerencias
de mejora a ese EIP.
 La tercera etapa es la última llamada de revisión (last call) para que la comunidad
tenga la última oportunidad de sugerir cambios. En este momento, la propuesta
se ubica en un lugar preferente en la web de EIP para que sea validada por el
32
Tema 3. Ideas clave
mayor número de personas de la comunidad Ethereum y así obtener el mayor
consenso con una implementación completamente funcional.
 La cuarta etapa es la aceptación de la propuesta pasando al estado final para que
los desarrolladores de los clientes Ethereum las incorporen a sus
implementaciones. Si el EIP va a ser una mejora continua entonces pasa al estado
living.
 La quinta etapa es la de mantenimiento, donde ya el EIP está en vida útil y solo se
debe modificar como consecuencia de identificación de errores.
Todos los EIP existentes que han llegado, al menos, al estado de borrador pueden
encontrarse en https://eips.ethereum.org/EIPS mientras que los que están aún como
idea inicial o abandonados se quedan en el directorio raíz https://eips.ethereum.org/
Como hemos dicho, EIP-1 es donde podemos encontrar en detalle las

especificaciones, proceso y pasos para crear, definir, probar y luego implementar los
diferentes EIP que se quieran incorporar a la comunidad Ethereum, por lo que
recomendamos su lectura para un conocimiento más en detalle de este mecanismo
de mejora.
Para cerrar este punto de los EIP, vamos a mencionar a continuación algunos de los
más importantes o famosos:
 EIP-20 (ERC-20) es el Token Standard y con su incorporación Ethereum empezó a

poder ser usada de manera general en multitud de casos de uso generalistas.
 EIP-137 determinó la especificación del Ethereum Name Service (ENS) que
permitió la creación de un sistema de gestión de nombres descentralizado
permitiendo la asignación de direcciones legibles a las direcciones Ethereum
criptográficas facilitando la legibilidad de los contratos.

 EIP-721 (ERC-721) es el Non-Fungible Token que se puede usar para asociar valor
a elementos no fungibles y que permitió proyectos como Criptokitties y,
recientemente, los del mercado del arte digital en general.
33
Tema 3. Ideas clave
 EIP-779 (Hard Fork Meta DAO) surge para poder resolver el problema del robo de
fondos ocurrido en TheDAO y devolver los fondos a sus dueños, pero que provocó
la escisión de la cadena Ethereum en dos comunidades: Ethereum (los que
aplicaron este EIP) y Ethereum Classic (los que no lo aplicaron). Esta escisión se
produjo porque este EIP realizaba una sobreescritura hacia atrás de la cadena
hasta el momento del robo.
 EIP-1559 (Cambio de comisiones) activada en agosto de 2021 en el bloque
12.965.000, mediante el Hard Fork London, incorpora el concepto de «propina» y
produce un mecanismo para quemar Ethers asociados a las comisiones para que
Ethereum se convierta en un futuro en un activo deflacionario atractivo para
inversionistas y que permite, además, una expansión o contracción del bloque de
datos para incluir más o menos transacciones por bloque y disminuir la congestión
de la red. Es importante reseñar que Ethereum sería deflacionista solo si el número
de ETH producidos en minería es inferior al número de ETH quemados en
comisiones, lo cual ahora no es así (se producen diez veces más de lo que se
quema). Este EIP es parte de la evolución a Ethereum 2.0.
Ethereum 2.0
Antes de hablar de Ethereum 2.0, hay que recordar que la red Blockchain Ethereum
1.0 ha pasado por varias fases desde su lanzamiento en 2015:
 1.ª etapa: FRONTIER. La primera versión desplegada fue lanzada en 2015 y fue,
básicamente, orientada a desarrolladores para empezar a generar Ether, diseñar
Dapps y experimentar.
 2. ª etapa: HOMESTEAD. La segunda versión surge en marzo de 2016 con mejoras

en protocolos.
34
Tema 3. Ideas clave
 3.ª etapa: METRÓPOLIS. Es la actual plataforma y se subdivide en dos subetapas:
Byzantium (octubre de 2017) y Constantinople (febrero de 2019). Con Byzantium
se introdujeron mejoras en muchos aspectos de la red:
• Ejecución más ágil y segura.
• Coste de gas más predecible.
• Verificación de conocimiento cero (zk-SNARK) que permite comprobar la
veracidad de una afirmación sin necesidad de revelar ningún dato sobre el
conocimiento a revelar.
• Se introdujo una «bomba de minería» como un ajuste del algoritmo de minado
para permitir la evolución de la siguiente fase. Este cambio básicamente viene
a permitir incrementar de formar exponencial la dificultad de la resolución de
la prueba de trabajo.
La versión Constantinople siguió trabajando sobre las mejoras introducidas con

Byzantium como base a la introducción de la cuarta (y actualmente última) etapa
de desarrollo de Ethereum, conocida como Ethereum 2.0 o Serenity.
Por ello, para reducir este consumo y ser más eficiente, se introduce el concepto de
Ethereum 2.0 que no es una única actualización, sino un conjunto de EIP que,
conjuntamente, transforman la red actual en otra. Básicamente constará de tres
mejoras:
• Fase 0. La cadena de balizas (o beacon chain) actualmente disponible en

formato restringido.
• Fase 1. El acoplamiento (Merge) de Ethereum 1.0 para usar la Beacon Chain.
• Fase 1.5. Las cadenas de fragmentos (o shard chains) donde las cadenas
Ethereum 1.0 dentro de la Ethereum 2.0 serán un fragmento más del total de
fragmentos y que, según la planificación actual, podrían estar disponibles

alrededor de 2022.
La fecha prevista para la activación del PoS (proof-of-stake) de modo genérico será el
desencadenante de la transformación y aún no está concretada, aunque se espera
35
Tema 3. Ideas clave
que sea entre finales de 2021 y mediados de 2022 (ahora mismo solo está disponible
dentro de su misma cadena). Para activarla, se necesitan 16.384 validadores (lo que
equivale a 524.288 ETH) que es la cantidad que ya se ha depositado en los contratos
existentes en la cadena principal de la nueva Ethereum 2.0 a mediados de agosto de
2021, por lo que el sistema ya está en condiciones de iniciar la activación. El primer
bloque de la cadena Ethereum 2.0 fue creado a primeros de diciembre 2020, pero no
ha sido hasta esta fecha cuando se ha logrado completar el número de ETH
bloqueados necesarios para el número de validadores requerido.
Otro de los hitos para alcanzar Eth2.0 ha sido la activación del EIP-1559 para la gestión
de comisiones.
Como pasos siguientes, Ethereum debería acometer mejoras en criptografía

poscuántica, el lanzamiento de las operaciones SNARK/STARK dentro de la segunda
capa, las mejoras de la EVM para dotar de mayor rapidez en la ejecución de contratos,
y el lanzamiento de una mejora del protocolo PoS Casper.
Proof-of-stake (prueba de participación)
Aunque Ethereum 1.0 usa proof-of-work (PoW) como Bitcoin, en Ethereum se quiere
usar otro mecanismo de consenso denominado proof-of-stake (PoS) o prueba de
participación (en algunos casos, incluso lo nombran prueba de posesión). La
primera pregunta que debemos hacernos es ¿por qué se quiere cambiar de un
sistema PoW ya existente a un nuevo esquema basado en PoS? Básicamente porque
en un sistema distribuido basado en el PoW, los mineros en su conjunto gastan
mucha energía como se puede ver en estudios como el existente en PowerCompare
de noviembre de 2017 donde muestra que una red como Bitcoin ya consumía en ese
momento más energía que 159 países juntos (https://powercompare.co.uk/bitcoin).
Para conseguir esta reducción de consumo de energía, PoS se basa en un sorteo.

Cuando un minero quiere participar en él para obtener recompensa por el minado de
36
Tema 3. Ideas clave
bloques, debe tener primeramente una cantidad estipulada de Ether en su cuenta y
debe bloquear una cierta cantidad de ellos. Esta es la cantidad que la red usará para
elegir al minero que se encargará de minar cada bloque. Por ello, cuanto más Ether
bloqueado, más posibilidades de ser elegido (como en un sorteo). Para escoger el
ganador, se usa una función aleatoria que usa valores aleatorios del bloque y el
minero escogido será el responsable de la incorporación a la cadena unos bloques
después. Más adelante veremos más de este proceso de stacking.
Vemos que, en este caso, la probabilidad de encontrar un bloque nuevo (y recibir la

recompensa correspondiente) es directamente proporcional al número de monedas
que se posee, siendo irrelevante la capacidad computacional. El razonamiento para
utilizar este mecanismo se basa en la suposición de que aquellos actores de la red
que poseen una mayor cantidad de monedas son los más interesados en mantener
el buen funcionamiento de la red y generar nuevos bloques de forma lícita.
Stacking
Hemos comentado antes, que en el proof-of-stake (PoS o prueba de participación)

los mineros se eligen mediante un proceso de sorteo basado en apuestas. Este
proceso de compra de apuestas es el stacking y se formaliza en el acto de bloquear
32 ETH mediante un depósito en un contrato inteligente en la Beacon Chain de la
Ethereum 2.0 para activar el software de validador.
El minero actual se convierte en un validador bajo este mecanismo de consenso, y

cómo tal, será responsable de almacenar información, procesar transacciones y
agregar nuevos bloques a la Blockchain (cadena de bloques). La idea es mantener
Ethereum seguro para todos y que los mineros, ahora validadores, ganen nuevos ETH
en el proceso.
Como no todas las cuentas pueden tener 32 ETH disponibles para bloquear, se
permite la creación de pools (stacking services).
37
Tema 3. Ideas clave
Además, se introduce el concepto de recompensas, que se otorgan a los validadores
por acciones que ayuden al resto de la red a alcanzar el consenso, de modo que
acciones como agrupar transacciones en un nuevo bloque o comprobar el trabajo de
otros validadores serán algunas de las que asignarán nuevos ethers.
Al mismo tiempo, se penaliza a aquellos validadores que hagan acciones maliciosas

o que no estén activos de modo habitual puesto que disminuyen la eficiencia de la
red.
Funcionamiento de la red fragmentada Ethereum 2.0
Una vez que se inicie el despliegue, la red estará constituida por sesenta y cuatro
fragmentos (o más si fuera necesario), siendo Ethereum 1.0 uno de estos fragmentos.
Cada uno de estos fragmentos será una Blockchain «independiente» y diferente del
resto, aunque todas supervisadas por la Beacon Chain como garantizadora de la
integridad global de Ethereum, como si fueran dos niveles.
Aunque las diferentes cadenas funcionaran de manera independiente se permite la

comunicación entre ellas. La comunicación es necesaria, ya que se podrían dar
transferencias entre estas pequeñas Blockchain.
La validación de las transacciones se realizará de manera aleatoria por las diferentes

Blockchain y añadidas en bloques. Tanto las transacciones como los bloques serán
reportados a las otras cadenas y a la Beacon Chain, aunque no serán distribuidas.
Se estima que, una vez implementado este nuevo sistema de manera completa, se
podrán validar hasta 100.000 transacciones por segundo (frente a los no más de
cuarenta transacciones por segundo actuales).
38
Tema 3. Ideas clave
3.3. Las criptomonedas como usuario: wallets y
exchanges
Desde el punto de vista del usuario existen dos conceptos fundamentales para la
utilización de criptomonedas:
 Cómo recibir y enviar criptomonedas.

 Cómo comprarlas o venderlas.
Aunque existen distintos proveedores de servicio que permiten integrar ambas

funciones, en líneas generales utilizaremos aplicaciones específicas denominadas
«monederos» o wallets para gestionar criptomonedas y «casas de cambio» o
exchanges para obtener criptomonedas.
Es importante reseñar que tanto en los monederos digitales (wallets) como en las
exchanges no se almacenan las criptomonedas, sino las claves que permiten el acceso
a la operación con las criptomonedas al verificar nuestra propiedad sobre ellas y por
tanto nuestro derecho a la operación.
Algunas veces se clasifican como «monederos calientes» (que tienen conexión a

Internet permanente, como son los monederos web, los de escritorio o los ligeros) y
«monederos fríos» (que no están conectados, como los de papel o los de hardware).
Monederos ligeros (light wallets)

Los monederos más utilizados, por su sencillez, son los denominados light wallets. La
principal característica de estas aplicaciones es la posibilidad de empezar a utilizar
criptomonedas desde el primer momento, sin necesidad de descargar toda la cadena
de bloques, que en realidad no necesitan (puesto que solo requieren para su
funcionamiento la información relacionada con las direcciones que gestionan).
39
Tema 3. Ideas clave
Para ello, estos monederos requieren de una funcionalidad ya descrita en el paper
original publicado por Satoshi Nakamoto, denominada Simplified Payment
Verification (SPV), por la cual obtienen de otros nodos de la red información sobre
las transacciones de entrada, que tienen como destino alguna de las direcciones
gestionadas, y transacciones de salida originadas en alguna de estas direcciones,
verificando que los bloques donde están incluidas estas transacciones existen y son
válidos. Esto permite evitar la descarga de la cadena de bloques en dispositivos
móviles, que no tienen espacio suficiente, y la necesidad de mantener actualizada la
información para poder operar en la red. Como contrapartida, los wallets que utilizan
SPV dependen de información externa para su funcionamiento y, potencialmente,
podrían ser susceptibles de ataques relacionados con esta dependencia.
Dirección del wallet (para

recibir transacciones)
trtransacciones)
Dirección del wallet (en
Saldo(*) en bitcoins y Wallet ligero (Jaxx) en Android
formato QR)
equivalente en euros (**)
Transacciones enviadas
Transacciones recibidas
Figura 10. Wallet ligero (Jaxx) en Android.

(*) En realidad, no existe el concepto de ‘saldo’. El total de bitcoins asociados a una dirección es la suma de las transacciones
de salida generadas con destino a dicha dirección que no han sido todavía utilizadas como entradas de nuevas transacciones.
(**) El equivalente en euros se calcula en tiempo real, en función de la cotización de bitcoin (cada monedero puede calcular un
valor distinto, en función del mercado de referencia que pueda utilizar, ya que la cotización varía).
40
Tema 3. Ideas clave
Para incrementar el anonimato, la mayoría de los monederos actuales implementan
direcciones HD (Hierarchical Deterministic), de forma que se origina
automáticamente una nueva dirección por cada transacción generada, impidiendo
de esta manera analizar los pagos realizados desde una misma aplicación con base
en la reutilización de una misma dirección.
Estos wallets utilizan una semilla (compuesta por un conjunto de 12 palabras) para
derivar, a partir de esta información, un conjunto ilimitado de claves privadas con su
correspondiente dirección pública.
Figura 11. Esquema de derivación de claves en wallets HD según el estándar BIP 32. Fuente:
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
Dicha semilla permite, además, restaurar el wallet en otro dispositivo, así como
disponer de distintas instancias de este wallet en múltiples dispositivos.
41
Tema 3. Ideas clave
Figura 12. Wallet ligero (Jaxx) en Windows (Nótese que es idéntico al wallet para Android. Al usar
la semilla para restaurarlo en PC, permite gestionar las mismas direcciones HD.)
Monederos fríos (cold wallets)
Cualquier dispositivo que contenga una clave privada correspondiente a una

dirección bitcoin es susceptible de sufrir algún ataque, que en caso de resultar exitoso
permitirá al atacante firmar transacciones y, por tanto, disponer de los bitcoins
asociados a dicha dirección.
Para evitar este riesgo es posible generar un cold wallet, un soporte no electrónico
donde se registra la clave privada. Uno de los formatos más habituales para este tipo
de monederos son los denominados paper wallets o monederos en papel, como el
que podemos ver en la siguiente imagen.
42
Tema 3. Ideas clave
Figura 13. Paper wallet generado en https://walletgenerator.net/
Distinguiremos dos códigos QR diferentes, uno corresponde a la dirección pública y

otro a la clave privada.
Figura 14. Clave privada 5J4dPcP1Wt2mZesmfbD2Aa8PhMtj9WTcWYqwbLBPQfGBZ5mc36D

Dirección pública 114MTWkUnGdDqfk39QywASX13yuXddNpXG
Podemos consultar la información asociada a la dirección pública generada en la

cadena de bloques de Bitcoin, con exploradores como Blockchain.info.
43
Tema 3. Ideas clave
https://blockchain.info/address/114MTWkUnGdDqfk39QywASX13yuXddNpXG
Para poder utilizar los fondos, basta con importar la clave privada escaneando el
código QR correspondiente en el paper wallet para incorporarla al conjunto de claves
privadas gestionadas por un monedero o bien “barrer” el paper wallet, desde el menú
correspondiente de la aplicación. De esta forma se genera una transacción utilizando
la clave privada para transferir los bitcoins a una dirección gestionada por el wallet,
de modo que el paper wallet, una vez procesado, ya no tiene valor y por tanto no hay
riesgo de que alguien pueda utilizar esa misma clave privada.
Hardware wallets
Otra alternativa para incrementar la seguridad en el uso de criptomonedas pasa por

utilizar dispositivos específicamente diseñados para almacenar de forma segura las
claves privadas que se utilizan para firmar transacciones. Este tipo de dispositivos se
denominan hardware wallets.
Figura 15. Ledger Nano S hardware wallet.
44
Tema 3. Ideas clave
Este tipo de artefactos se conectan mediante un cable USB al dispositivo donde reside
el monedero. En el momento en que se genera una transacción el wallet no tiene
acceso a la clave privada, sino que el proceso de firma se realiza en la aplicación que
reside en el propio dispositivo (para garantizar que nadie tenga acceso a esta
información). Realizada la transacción y retirado el dispositivo del puerto USB, no hay
posibilidad de que alguien pueda comprometer o utilizar la clave privada (salvo
teniendo acceso al HW wallet).
Figura 16. Ledger wallet (previo a introducir el HW wallet en el PC).
Figura 17. Ledger wallet (introducido el HW wallet en el PC).
Casas de cambio (exchanges)

Uno de los actores principales para dotar de liquidez al ecosistema de monedas

virtuales son las casas de cambio o exchanges, que facilitan a los usuarios el
intercambio de monedas de curso legal (FIAT) por criptomonedas, y viceversa, así
como la compraventa entre distintas monedas virtuales y/o tókenes.
45
Tema 3. Ideas clave
Debemos distinguir entre dos tipos de exchanges: CEX (centralizados) y DEX
(descentralizados).
Centralized exchange (CEX)
Las empresas que ofrecen este servicio facilitan a sus clientes una plataforma donde,
una vez registrados, pueden operar en el mercado. A cambio de este servicio, estas
empresas obtienen comisiones por cada operación que se realiza (compraventa,
depósito, retirada, etc.).
Una vez el cliente dispone de una cuenta validada, puede realizar una transferencia
desde su entidad financiera hacia la cuenta de la casa de cambio o bien transferir
criptomonedas para poder operar en el mercado. El tipo de órdenes que pueden
realizarse en los exchanges permite comprar o vender a precio de mercado (el valor
al que se intercambia en el momento en que se genera la orden), o bien establecer
otros criterios que dependen de cada casa de cambio (algunas posibilitan incluso
apalancamiento o ventas a corto, entre otras opciones).
Figura 18. Formulario para realizar distintos tipos de órdenes de compra/venta en Bitstamp.
A diferencia de un wallet, las casas de cambio tradicionales son quienes custodian los
fondos de sus clientes, estableciendo apuntes contables en su base de datos para
46
Tema 3. Ideas clave
reflejar la posición de estos en cada moneda y las transacciones que realizan, así
como el estado del mercado y el libro de órdenes existente (orders book). Cuando un
usuario deposita criptomonedas en su cuenta para operar en el mercado, en realidad
transfiere a la empresa el control de estos activos (realiza una transacción hacia una
dirección controlada por el exchange, que es quien posee la clave privada que
permite generar transacciones hacia la red).
Para incrementar la seguridad y minimizar las consecuencias del robo de estas claves
(que se ha producido en múltiples ocasiones) la mayoría de los exchanges utilizan
direcciones multifirma distribuyendo las claves entre varios actores (la propia casa de
cambio, el usuario y una tercera parte de confianza), de forma que en el caso de
compromiso de una de las partes sea imposible movilizar los fondos al requerir la
firma de varias partes para generar una transacción.
En todo momento los clientes de los exchanges puede retirar sus fondos hacia sus
propios wallets, generándose al finalizar el proceso de verificación (en el que el
cliente debe proporcionar típicamente una clave y un segundo factor de
autenticación, vía SMS, TOTP, etc.) una transacción desde las direcciones donde la
casa de cambio almacena los activos de sus usuarios hacia la aplicación del cliente,
momento en el que este pasa a controlar sus criptomonedas.
47
Tema 3. Ideas clave
Figura 19. Formulario para retirada (withdraw) de bitcoins en Bitstamp a la cartera del usuario.
Adicionalmente, las casas de cambio CEX solo disponen de una fracción de sus
reservas en criptomonedas online disponibles en el mercado. El grueso de los activos
se almacena en cold wallets custodiados con medidas de seguridad físicas y se activan
únicamente cuando es necesario para garantizar la liquidez, evitando que las claves
privadas puedan ser sustraídas por medios electrónicos.
A lo largo del tiempo, los controles exigidos por parte de distintos países (como es el
caso de EE. UU.) a las empresas que prestan estos servicios a sus ciudadanos se han
incrementado con el objetivo de cumplir la legislación y reducir el riesgo de
actividades fraudulentas. Las casas de cambio deben cumplir, en estos casos, las
normativas AML/KYC (Anti Monery Laundering / Know Your Customer) solicitando a
sus clientes en el proceso de registro la documentación necesaria para identificar de
forma fehaciente su identidad y domicilio, y registrando todas las operaciones que
realizan (información que podrá ser solicitada por las autoridades en los casos
contemplados por la ley).
Como resumen de las CEX, ofrecen gran liquidez, permiten adquirir diferentes tipos
de criptomonedas con dinero tradicional, ofrecen opciones de operación similares a
servicios de casas de cambio o de bolsa, pero tienen un control centralizado ofrecido
por un servicio de terceros, cobran comisión por el servicio (incluso, a veces,
considerable) y suponen una cierta pérdida de privacidad al usuario a cambio de esa
seguridad, aunque no están exentos de poder sufrir ataques.
Ejemplos de estos exchanges Centralizados son Coinbase o Binance a nivel

internacional, o 2gether y Bit2me en España entre otros.
48
Tema 3. Ideas clave
DeCentralized exchange (DEX)
Este tipo de exchanges se basan en Contratos Inteligentes, la mayor parte de los

cuales se despliegan sobre la Red Ethereum, y en donde no hay una tercera parte
confiable.
Dado que los intercambios se hacen directamente sobre la Blockchain, la privacidad

es total y no hay comisiones (o son casi nulas) realizándose, por ejemplo, a través de
herramientas como MetaMask.
A nivel de seguridad, se puede decir que es alta, dado que las claves de operación
están en todo momento bajo control del usuario y no hay delegación en un tercero,
pero no hay en ningún momento, un respaldo en caso de robo o engaño dado que en
un instante dado perdemos la posesión de las monedas durante la operación.
Sin embargo, en los DEX no hay opciones avanzadas de operación como en los CEX ni
se pueden realizar operaciones de cambio por moneda tradicional o con
criptomonedas fuera de la red Blockchain donde están desplegados los smart
contracts, aunque están apareciendo DEX de segunda generación que permiten el
uso de múltiples redes al no tener que almacenar las monedas fuera de la wallet.
Algunos ejemplos de este tipo de exchanges descentralizados son Bitsquare o

UniSwap.
49
Tema 3. Ideas clave

Tema3 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema3 1

Cargado por

Copyright:

Formatos disponibles

Tema 3

En 2009, surge un documento publicado por un desconocido Satoshi Nakamoto

Este sistema combina varios elementos tecnológicos ya existentes que sumados

Tras estos años, Bitcoin se ha convertido en la criptomoneda por excelencia. Veamos

La estructura básica de una red Blockchain es el bloque. Y estos bloques se replican

Un bloque consta de tres elementos principales, de modo esquemático:

Tenemos tres bloques:

 Bloque 0. Hash: 3EF3, Hash anterior: 0000, Data: w4AaQxXG5GNN.

 Bloque 1’: Hash: CD7f, Hash anterior: 3EF3, Data: 2EuTsg5cKc11hRTA.

Y, por tanto, en el bloque 2 ya no coincidiría el campo Hash Anterior (BCA3) con lo

El uso de los hashes permite detectar la manipulación de los bloques, pero no

Con objeto de evitar esta manipulación, es necesario introducir un nuevo

Proof-of-work (prueba de trabajo)

Uno de los problemas principales a los que se enfrenta un sistema descentralizado

Adicionalmente, el sistema debe asegurar que el coste necesario para alterar

Con el objetivo de conseguir ambas propiedades, Bitcoin utiliza una combinación de

El cálculo de la dificultad se ajusta de forma automática para garantizar que este

Puesto que el proceso de PoW requiere un consumo de recursos proporcional a la

Dado que los mineros obtienen un rendimiento económico cuando encuentran un

La mayoría de las criptomonedas implementan mecanismos de consenso de tipo PoW

Para enviar una cantidad determinada de Bitcoins de un usuario a otro, el usuario

(Unspent Transaction Outputs o UTXOs), y un conjunto de transacciones de salida

En el caso de que las direcciones gestionadas por el wallet no resulten suficientes de

Además de esta información, la transacción incluye información adicional, en forma

El siguiente diagrama representa el encadenamiento de transacciones que se realiza

Figura 2. Encadenamiento de outputs como inputs de nuevas transacciones Fuente: bitcoin.org

BIP o cómo evoluciona el Bitcoin

cadena. Para poder gestionar las mejoras que la comunidad va necesitando se

 Presentación a la comunidad (con los estados Draft).

Funcionamiento del Bitcoin Scripting

Las transacciones en Bitcoin incorporan un lenguaje denominado script que permite

El lenguaje ofrece un conjunto de operaciones, cada una de las cuales se representa

SCRIPT DESCRIPCIÓN PILA

2 5 OP_ADD 7 OP_EQUAL Se añade el valor 2 a la pila. 2

5 OP_ADD 7 OP_EQUAL Se añade el valor 5 a la pila. 25

7 OP_EQUAL Se añade el valor 7 a la pila. 77

Tabla 1. Secuencia de ejecución del script, indicando el contenido de la pila.

El mecanismo de validación de las transacciones en Bitcoin se basa en dos tipos de

 Script de bloqueo (históricamente denominado scriptPubKey): establece las

 Script de bloqueo (scriptPubKey)

SCRIPT DESCRIPCIÓN PILA

Tabla 2. Secuencia de ejecución del script, indicando el contenido de la pila.

 Script de bloqueo (scriptPubKey)

Los scripts de multifirma permiten condicionar el bloqueo a la presentación de un

Este tipo de scripts permiten simplificar y reducir el tamaño de transacciones

hash y el correspondiente script de desbloqueo.

 Script de bloqueo (scriptPubKey)

SegWit es la contracción de Segregated Witness o testigo segregado, y es un cambio

El funcionamiento es simple: se separan las firmas y los códigos de ejecución (los

En relación con la escalabilidad, en la mejora SegWit se aumenta el tamaño del

Otro punto importante de SegWit es la creación de nuevas direcciones que empiezan

Figura 5. Porcentaje de transacciones SegWit. Fuente: transactionfee.info

P2WPKH (pay to witness public key hash)

La introducción de SegWit (segregated witness) ha modificado el formato tradicional

Es decir, sustituye la información que se recogía en el scriptSig para demostrar la

Script de bloqueo 0 <pubKeyHash>

Script de desbloqueo Vacío

DUP HASH160 [20-byte

Witness <sig> <pubkey>

Tabla 3. Características de una transacción P2WPKH.

LIghtning Network y los canales de pago

Con la introducción de SegWit se habilitaba la posibilidad de tener protocolos de

protocolos de segunda capa que opera sobre Bitcoin. Su misión es permitir