Verificación y validación de un modelo PIM de la tecnología
blockchain especificado con Alloy
Accattoli, Mario Luis
Argañaraz, Mauro César
Abstract
En este trabajo planteamos la creación de un
modelo PIM de la tecnología blockchain que reúne
las características esenciales y sienta las bases para
futuras implementaciones (PSM). El modelo se
refina con una serie de requisitos formales
especificados en el lenguaje Alloy, donde se
destacan los aspectos estáticos y estructurales y los
aspectos dinámicos de la tecnología considerando la
propiedad de integridad, uno de los tres principios
rectores de la seguridad de la información. También
se incluye un caso de test que se depuró con las
técnicas de chequeo y simulación de la herramienta
SAT.
Palabras Clave
MDA, PIM, Alloy, formal verification,
cryptocurrency, blockchain, block, transaction,
bitcoin.
Introducción
En el marco de la Arquitectura Dirigida por
Modelos (MDA) presentamos un caso de
estudio basado en la tecnología blockchain.
La cadena de bloques (blockchain) es uno
de los pilares sobre los que se fundaron las
criptomonedas en un primer momento y
que ahora se ha extendido a otros ámbitos.
La blockchain nació con el propósito de
resolver el problema del doble gasto en un
sistema descentralizado, que tanto había
desvelado a economistas y programadores.
Es la estructura subyacente que da soporte
al libro contable público donde se
encadenan las pruebas de trabajo requeridas
por los protocolos que implementan las
criptomonedas.
Cada criptomoneda tiene su propia
estructura de blockchain, dando origen a
distintas implementaciones dependientes de
los ambientes donde se despliegan. Nuestra
propuesta consiste en construir un modelo
PIM de la tecnología blockchain que reúna
los conceptos y características básicas
deseadas con el objetivo de que sea
utilizado en futuras referencias para la
construcción e implementación de modelos
PSM y código. Además del modelo PIM, el
trabajo incluye una serie de requisitos
formales que se especifican con el lenguaje
Alloy, donde destacamos los aspectos
estáticos y estructurales y los aspectos
dinámicos del modelo construido sobre la
propiedad de integridad de los datos.
Este documento se organiza de la siguiente
manera: en la Sección 1 se introducen los
conceptos relacionados a la tecnología
blockchain y se propone un modelo básico
PIM. En la segunda y tercera sección se
presentan los aspectos estáticos y
estructurales y los aspectos dinámicos
especificados en Alloy, respectivamente. En
la Sección 4 se incluye el caso de test
analizado. La Sección 5 replantea el caso de
estudio especificado con la inclusión de
estructuras avanzadas de Alloy. Por último,
en las conclusiones, se esbozan los
resultados obtenidos.
Modelo PIM Blockchain
En una cadena de bloques las principales
estructuras son los bloques, las
transacciones y las cuentas. En la Figura 1
se muestra un diagrama de clases que
representa estos conceptos junto con los
atributos y asociaciones que las relacionan.

En términos simples, una cadena de bloques
está compuesta por una serie de bloques
encadenados de manera secuencial, y cada
uno de los bloques contiene n transacciones
y un enlace al bloque anterior.
Una transacción es una transferencia de
dinero de una cuenta remitente a un
destinatario.
«singleton»Blockchain
-block
+initTransaction()
+addBlock()
+addTransaction()
BitcoinAccount -sender Transaction
1 *
-available : decimal -amount : decimal
1 *
-recipient
Figura 1: Modelo PIM blockchain
En este primer acercamiento al modelado
PIM de la blockchain se priorizó la
propiedad de integridad de los datos, uno de
los principios rectores de seguridad de la
información. Las especificaciones que se
tuvieron en cuenta son:
1. Los datos solo se pueden insertar en
la cadena de bloques si son válidos.
2. Un bloque debe ser único y no una
duplicación de un bloque anterior.
3. Un bloque debe tener un
identificador único, así como un
enlace a un bloque válido anterior.
Aspectos estáticos y estructurales
Los aspectos estáticos y estructurales se
modelan en Alloy con signaturas y campos,
cada clase del diagrama de la Figura 1 se
representa con una signatura. Cada atributo
se mapea con un campo decorado con la
multiplicidad. En la Figura 2 podemos
apreciar las equivalencias especificadas con
Alloy.
one sig Blockchain {
blocks: one Block
}
sig Block {
transactions: some Transaction,
prevBlock: lone Block,
secuence: Int
}
sig Transaction {
sender: one BitcoinAccount,
recipient: one BitcoinAccount,
amount: Int
}
sig Saldo {
0..1 -prevBlock
saldo:Int
Block }
-secuence : int
1 * sig BitcoinAccount {
1 available: Saldo
}
*
Figura 2: Signaturas y campos en Alloy
-transactions
Las especificaciones también se componen
de hechos que representan restricciones o
invariantes que se deben cumplir en todo
momento. En la Figura 3 se detallan una
serie de hechos definidos para nuestro caso
de estudio.
fact { all tx: Transaction |
#tx.~transactions = 1 }
fact { no tx: Transaction | tx.sender =
tx.recipient }
fact { no b: Block | b.prevBlock = b }
fact { all tx: Transaction | tx.amount > 0 }
fact { all b: Block | b.secuence >
b.prevBlock.secuence }
fact { one b: Block | #b.prevBlock = 0 &&
Blockchain.blocks = b}
fact { all b: Block | (#b.prevBlock = 0 &&
Blockchain.blocks = b) || (#b.prevBlock =
1)}
fact { no disj b, c: Block | c.prevBlock =
b.prevBlock }
fact { all disj b,b': BitcoinAccount, a:
Saldo | a !in b.available & b'.available }
fact { all disj b,b': BitcoinAccount, a:
Saldo | a in b.available + b'.available }
Figura 3: Hechos
En el siguiente listado se enumeran con
lenguaje natural cada uno de estos hechos:
1. Cada una de las transacciones debe
pertenecer a un solo bloque.
2. No puede existir una transacción donde
la cuenta remitente y destinataria sean
iguales.
3. No puede existir un enlace a un bloque
previo que sea igual al mismo bloque.
4. Todas las transacciones deben ser de
importe mayor a 0.
5. Todos los bloques deben tener un valor
de secuencia mayor que el bloque
precedente.
6. El único bloque que no tiene predecesor
es el bloque inicial.
7. Todos los bloques deben tener un
predecesor o ser el bloque inicial.
8. Dado dos bloques disjuntos no pueden
tener el mismo bloque previo.
9. No puede existir un átomo Saldo que
pertenezca a dos cuentas.
10. No puede existir un átomo Saldo que no
pertenezca a ninguna cuenta.
Utilizando la especificación Alloy previa,
podemos ejecutar el analizador y obtener
una instancia del modelo realizado como
podemos observar en el grafo de la Figura
4.
Figura 4: Instancia del modelo propuesto
Aspectos dinámicos
Los aspectos dinámicos permiten el
modelado del cambio de estado a medida
que pasa el tiempo y en Alloy se
especifican con predicados.
Antes de pasar a los predicados definidos
en el caso de estudio, tenemos que remarcar
las adaptaciones que realizamos en el
modelo para incluir la signatura de Tiempo.
sig Time {}
sig BitcoinAccount {
available: Saldo one -> Time
}
Figura 5: Inclusión de la signatura Time
También se modificaron algunos de los
hechos planteados originalmente para
incluir la noción de tiempo, quedando de la
siguiente manera (ver Figura 6):
fact { no tx: Transaction, t:Time |
tx.amount > tx.sender.available.t.saldo }
fact { all disj b,b': BitcoinAccount, a:
Saldo, t: Time | a !in b.available.t &
b'.available.t }
fact { all disj b,b' :BitcoinAccount,
a:Saldo, t : Time | a in b.available.t +
b'.available.t }
Figura 6: Hechos refinados
En la Figura 7 se enumeran las 3
operaciones para la blockchain:
pred initTransaction [ disj mario, mauro:
BitcoinAccount, t,t':Time , tran1:
Transaction]
{
mario.available.t.saldo >= tran1.amount
mario.available.t'.saldo =
mario.available.t.saldo.minus[tran1.amount]
mauro.available.t'.saldo =
mauro.available.t.saldo.plus[tran1.amount]
}
pred addBlock [newBlock, lastBlock: Block,
t, t': Time]
{
#lastBlock.~(prevBlock.t) = 0
newBlock.prevBlock.t' = lastBlock
}
pred addTransaction [tx : Transaction, b :
Block, t, t' : Time]
{
#b.~(prevBlock.t) = 0
b.transactions.t' = b.transactions.t + tx
}
Figura 7: Operaciones de la blockchain

El primer predicado se refiere a la

operación mediante la cual se inicia una
transacción en la red blockchain, en la que
intervienen el remitente, el receptor y un
importe. En el segundo caso se trata de la
operación que permite añadir un bloque
adicional a la red blockchain, para lo cual
se debe ubicar el último bloque y agregar el
nuevo bloque al final, estableciendo un
vínculo con el bloque anterior. El último
predicado es para el momento en que una
transacción ya fue validada por la red
(mineros) y se tiene que sumar al último
bloque de la red. Figura 9: Instancia en el tiempo t0

Caso de test

Como parte de los chequeos y simulaciones

de ejecuciones que realizamos al refinar
nuestro caso de estudio, incluimos a
continuación un caso de test especificado
con su correspondiente grafo.

Con las variables de tiempo incluidas en las

operaciones se probó el modelo simulando
una instancia utilizando el siguiente
predicado:
pred Instancia { some disj mario, mauro:
BitcoinAccount, disj t,t': Time, tran1:
Transaction {
mario.available.t.saldo = 3
mauro.available.t.saldo = 2
mario.available.t'.saldo =2
mauro.available.t'.saldo = 3
tran1.amount = 1
Time = t + t'
BitcoinAccount = mario + mauro
Transaction = tran1
initTransaction[mario, mauro, t, t', tran1] Figura 10: Instancia en el tiempo t1
}
}
Figura 8: Caso de test Incorporación de estructura avanzadas
en Alloy
De la ejecución de este caso de test se
obtuvieron las siguientes instancias: A causa de que los bloques forman una
cadena ordenada (secuencial), se optó por
mejorar el modelo propuesto, reemplazando
el campo “secuence” por el uso del módulo
util/ordering que nos proporciona
funcionalidades como primero, siguiente y De la ejecución del modelo mejorado se
último, permitiéndonos representar el orden obtuvo la instancia de la Figura 12.
que deberían tener tanto los bloques como
las transacciones dentro de los bloques. Por
lo cual replanteamos el modelo inicial tanto
en sus definiciones, como sus hechos,
quedando de la siguiente manera:
open util/ordering [Block]
open util/ordering [Transaction]
sig Time {}
one sig Blockchain {
blocks : one Block
}
sig Block {
transactions : some Transaction,
prevBlock : lone Block,
}

sig Transaction {
sender : one BitcoinAccount,
recipient : one BitcoinAccount,
amount : Int
}
sig Saldo {
Figura 12: Instancia del modelo mejorado con
saldo: Int util/ordering
}
sig BitcoinAccount { Conclusión
available : Saldo one -> Time
}
En este ensayo se propuso la creación de un
modelo PIM para la tecnología blockchain
fact {all b:Block | ! next [b] = prev [b]}
donde se formalizaron una serie de
fact { all b:Block | b.prevBlock = prev
[b]} requisitos priorizando la propiedad de
fact {all disj a, b: Block, t: Transaction
integridad de los datos. Para la
| t !in (b.transactions & especificación, verificación y validación se
a.transactions)}
utilizó el lenguaje Alloy y el conjunto de
fact { all tx: Transaction | herramientas que permiten la simulación y
#tx.~transactions = 1 }
chequeo de las propiedades estáticas y
fact { all tx: Transaction | ! tx.sender =
tx.recipient } dinámicas. En una línea de investigación
fact { all t: Transaction | t.amount > 0} futura se debería extender y completar el
fact { all disj a,a' :Saldo | a & a' = none}
modelo PIM con los conceptos que no
fueron incluidos tales como el protocolo de
fact { all disj b,b' :BitcoinAccount,
a:Saldo, t : Time | a !in b.available.t & consenso, el número de mineros o las
b'.available.t }
fact { all disj b,b' :BitcoinAccount, restricciones de tiempo.
a:Saldo, t : Time | a in b.available.t +
b'.available.t }
Figura 11: Especificación Alloy incluyendo
util/ordering