1. Introduction
Cryptocurrency protocols deal with virtual money, so they are a valuable target for highly skilled attackers. Several attacks have already been mounted against cryptocurrency systems, causing irreparable losses of money and credibility (e.g., [
1]). Furthermore, it is necessary to understand virtual money in the context of a global financial system which has deteriorated due to the COVID-19 pandemic [
2]. In this context, security and confidential properties have become even more crucial. For this reason the cryptocurrency community is seeking approaches, methods, techniques and development practices that can reduce the chances of successful attacks. One such approach is the application of formal methods to software implementation. In particular, the cryptocurrency community is showing interest in formal proofs and formally certified implementations [
3,
4]. However, that community is not an exception. For instance, in the field of service industries, formal and mathematical approaches are also carried out to analyze and propose a solution to a problem. An et al. [
5] model a network revenue management problem and propose a genetic algorithm to maximize revenue providing computational experiments. The reported results demonstrate the effectiveness of this approach.
Mimblewimble (MW) is a privacy-oriented cryptocurrency technology encompassing security and scalability properties that distinguish it from other technologies of its kind. MW was first proposed in 2016 [
6]. The idea was then further developed by Poelstra [
7]. In MW, unlike Bitcoin [
8], there is no concept of address and all the transactions are confidential. In this paper we outline an approach based on formal software verification aimed at formally verifying the basic mechanisms of MW and its implementations [
9,
10].
We put forward a model-driven verification approach where security issues that pertain to the realm of critical mechanisms of the MW protocol are explored on an idealized model of this system. This model abstracts away the specifics of any particular implementation, and yet provides a realistic setting. Verification is then performed on more concrete models, where low level mechanisms are specified. Finally the low level model is proved to be a correct implementation of the idealized model.
Security (idealized) models have played an important role in the design and evaluation of high assurance security systems. Their importance was already pointed out in the Anderson report [
11]. The paradigmatic Bell–LaPadula model [
12], conceived in 1973, constituted the first big effort on providing a formal setting in which to study and reason on confidentiality properties of data in time-sharing mainframe systems. In that work the authors provide a general descriptive model of a computer system involving formally precised security concepts like simple-security, discretionary-security and the star-property over State machines.
State machines can be employed as the building block of a security model. The basic features of a state machine model are the concepts of state and state change. A
state is a representation of the system under study at a given time, which should capture those aspects of the system that are relevant to the analyzed problem. State changes are modeled by a state transition function that defines the next state based on the current state and input. If one wants to analyze a specific safety property of a system using a state machine model, one must first specify what it means for a state to satisfy the property, and then check if all state transitions preserve it. Thus, state machines can be used to model the enforcement of a security policy.
The aim of the present work is to identify and analyze the main components of the MW protocol in order to build an idealized model. Then, relevant security properties are defined and verified over the model. This is key to address the verification of its implementations. Furthermore, since MW is built on top of a consensus protocol, we specify such protocol and present an executable model which allows us to analyze the behavior of the protocol without having to implement it.
1.1. Related Work
Developers of cryptocurrency software have already shown interest in using mathematics as a tool to describe software. In fact, both Nakamoto, in his seminal paper on Bitcoin [
8], and Wood, in his description of the Ethereum Virtual Machine (EVM) [
13], make use of mathematical constructs. In particular, in the latter work it is explained the Ethereum blockchain as a transaction-based state machine and the programs to be executed on the EVM are called smart contracts. However, those descriptions can not be understood as Formal Methods (FM) because they are neither based on standardized notations nor on clear mathematical theories.
Sestrem et al. [
14] have pointed out the importance of privacy and security over Smart grid systems. They propose a sidechain architecture which is built up of three different blockchains. They claim for that solution to ensure system privacy, security, and reliability. In particular, one of those blockchains is responsible for ensuring such properties in the system, which are verified performing several tests using the Loom Platform. We think that, in this kind of scenarios, a formal definition of those security properties would help to understand what is required to be proved, independently of any particular implementation.
On the other side the FM community has started to pay attention to cryptocurrency software. Idelberger et al. [
15] proposed to use defeasible logic frameworks such as Formal Contract Logic for the description of smart contracts. However, in that work the authors do not analyze cryptocurrency protocols nor the necessary conditions to guarantee security properties that those protocols should satisfy.
Bhargavan et al. [
16] compile
Solidity programs into a verification-oriented functional language where they can verify source code. Although the paper describes a framework to analyze and verify both the runtime security and the functional correctness of blockchain systems, the work only focuses on smart contracts. Luu et al. [
17] use the
Oyente tool to find and detect vulnerabilities in smart contracts. Hirai [
18] uses Lem to formally specify the EVM; Grishchenko, Maffei and Schneidewind [
19] also formalize the EVM but in F
∗; and Hildenbrandt et al. do the same but with the reachability logic system known as
. Pîrlea and Sergey [
20] present a Coq [
21,
22] formalization of a blockchain consensus protocol where some properties are formally verified.
More recently, Rosu [
3] presented academic and commercial results in developing blockchain languages and virtual machines that come directly equipped with formal analysis and verification tools. Hajdu et al. [
23] developed a source-level approach for the formal specification and verification of Solidity contracts with the primary focus on events. Santos Reis et al. [
24] introduced Tezla, an intermediate representation of Michelson smart contracts that eases the design of static smart contract analysers. In [
25], Boyd et al. presented a blockchain model in Tamarin, that is useful for analyzing certain blockchain based protocols. On the other hand, Garfatta et al. [
4] described a general overview of the different axes investigated actually by researchers towards the (formal) verification of Solidity smart contracts. Tolmach et al. [
26] investigated formal models and specifications of smart contracts and presented a systematic overview to understand common trends, although they did not specifically consider security in cryptocurrency protocols.
Additionally, Metere and Dong [
27] present a mechanised formal verification of the Pedersen commitment protocol using
EasyCrypt [
28] and Fuchsbaue et al. [
29] introduce an abstraction for the analysis of some security properties of MW. Our work assumes some of these results to formalize and analyze the MW protocol, to then propose a methodology to verify their implementations.
Finally, in Betarte et al. [
30] we outline some formal methods related techniques that we consider particularly useful for cryptocurrency software. We present some guidelines for the adoption of formal methods in cryptocurrency software projects. We argue that set-based formal modeling (or specification), simulation, prototyping and automated proof can be applied before considering more powerful approaches such as code formal verification. In particular, we show excerpts of a set-based formal specification of a consensus protocol and of the EVM. We also exhibit that prototypes can be generated from these formal models and simulations can be run on them. Finally, we show that test cases can be generated from the same models and how automated proofs can be used to evaluate the correctness of these models. The work we present here closely follows the approach of Betarte et al. [
30].
1.2. Contribution
This article builds upon and extends a previously published paper in AIBlock 2020 [
31]. In that paper, we present elements that comprise the essential steps towards the development of an exhaustive formalization of the MW cryptocurrency protocol and the analysis of some of its properties. The proposed idealized model constitutes the main contribution together with the analysis of the essential properties it is shown to verify. We have also introduced and discussed the basis of a model-driven verification approach to address the certification of the correctness of a protocol’s implementation.
In the present paper, we extend both the definition of the MW protocol and the idealized model. In particular, the formal definition and discussion of the notion of commitment scheme in
Section 2.3 is completely new. We have also extended the section where we study the security properties of MW, incorporating the discussion on the security properties of Pedersen commitments in
Section 4.3. We study the strength of the scheme regarding the main security properties a cryptocurrency protocol must have. The sections Model-driven verification and MW implementations are also new. In the first one, since MW is built on top of a consensus protocol, we develop a Z specification of one such protocol and present an excerpt of the {
log} prototype generated from the Z specification. This {
log} prototype can be used as an executable model where simulations can be run. This allows us to analyze the behavior of the protocol without having to implement it in a low level programming language. Finally, we compare two MW implementations,
Grin [
9] and
Beam [
10], with our model and we discuss some features that set them apart.
The rest of the paper is organized as follows:
Section 2 provides a brief description of MW.
Section 3 describes the building blocks of a formal idealized model (abstract state machine) of the computational behavior of MW.
Section 4 and
Section 5 provide an account of the verification activities we are putting in place in order to verify the protocol and its implementation. Then,
Section 6 analyzes the
Grin and
Beam implementations of MW in their current state of development. Final remarks and directions for future work are presented in
Section 7.
The list of abbreviations and acronyms can be found at the end of this manuscript.
Table A1 in
Appendix A provides the meaning ofprovides the meaning of the math symbols used throughout this work.
3. Idealized Model of Mimblewimble-Based Blockchain
The basic elements of our model are transactions, blocks and chains. Each node in the blockchain maintains a local state. The main components are the local copy of the chain and the set of transactions waiting to be validated and added to a new block. Moreover, each node keeps track of unspent transaction outputs (UTXOs). Properties such as zero-sum and the absence of double spending in blocks and chains must be proved for local states. The blockchain global state can be represented as a mapping from nodes to local states. For global states, we can state and prove properties for the entire system like, for instance, correctness of the consensus protocol.
3.1. Transactions
Given two fixed generator points G and H on the elliptic curve of prime order n (whose discrete logarithms relative to each other are unknown), we define a single transaction between two parties as follows:
Definition 3 (Transaction).
A single transaction t is a tuple of type:with representing the lists of elements of type X and where: and are the lists of inputs and outputs. Each input and output are points over the curve C and they are the result of computing the Pedersen commitment with r the blinding factor and v the transactional value in the finit field .
is the transaction kernel where:
- –
is a list of range proofs of the outputs.
- –
is the transaction excess represented by .
- –
σ is the kernel signature (for simplicity, fees are left aside).
is the transaction kernel offset.
The transaction kernel offset will be used in the construction of a block to satisfy security properties.
Definition 4 (Ownership). Given a transaction t, we say S owns the output o if S knows the opening for the Pedersen commitment .
The strength of this security definition is directly related to the difficulty of solving the logarithm problem. If the elliptic curve discrete logarithm problem in C is hard then given a multiple Q of G, it is computationally infeasible to find an integer r such that .
It is important to notice that during the construction of the transaction the sender and the receiver do not learn their respective blinding factors. Instead, they build a Schnorr signature that is used to guarantee the authenticity of the transaction excess value.
Definition 5 (Balanced Transaction).
A transaction , with transaction kernel , is balanced if the following holds: A balanced transaction guarantees no money is created from thin air and the transaction was honestly constructed.
Property 1 (Valid Transaction). A transaction t is valid () if t satisfies:
- i.
The range proofs of all the outputs are valid.
- ii.
The transaction is balanced.
- iii.
The kernel signature σ is valid for the excess.
These three properties have a straightforward interpretation in our model. Due to limitations of space, in this paper we only formalize and analyze some of the properties mentioned throughout the document.
3.2. Aggregate Transactions
Transactions can be aggregated into bigger transactions. A single transaction can be seen as the sending of money between two parties. The following definition represents multiple parties:
Definition 6 (Aggregate Transaction).
An aggregate transaction is a tuple of type:with representing the lists of X elements detailed in Definition 3. Transactions can be merged non-interactively to construct an aggregate transaction.
Definition 7 (Transaction Join).
Given a valid transaction and an aggregate transaction :a new aggregate transaction can be constructed as:where is the list concatenation operator and + is the scalar sum. This process can be applied recursively to add more transactions into one aggregate transaction. A single transaction (Definition 3) can be seen as a particular case where the transaction kernel list contains a single element. Besides, the ownership of the coins is between two parties.
The CoinJoin mechanism [
36] makes it possible to combine all inputs and outputs from separate transactions to form a single transaction and the signatures can be composed by the parties. A Transaction Join can be understood as a simple way to perform CoinJoin with no composite signatures.
The validity of an aggregate transaction is guaranteed by the validity of the transactional parties during the construction process.
Lemma 1 (Invariant: CoinJoin Validity). Given a valid transaction and a valid aggregate transaction as in Definition 6. Let be the result of aggregating into . Then, is valid.
In our model, aggregate transactions and blocks (Definition 9) are the same (without considering headers). We are interested in distinguishing them because the unconfirmed transaction pool will contain aggregate transactions.
Notice that, in an aggregate transaction, an adversary could find out which input cancel which output. They could try all possible permutations and verify if they summed to the transaction excess. The property of transaction unlinkability will be proved over blocks, as we will see in Property 3.
3.3. Unconfirmed Transaction Pool
The unconfirmed transaction pool (mempool) contains the transactions which have not been confirmed in a block yet.
Definition 8 (Mempool).
A mempool is a list of type: 3.4. Blocks and Chains
Genesis block is a special block since it is the first ever block recorded in the chain. Transactions can be merged into a block. We can see a block as a big transaction with aggregated inputs, outputs and transaction kernels.
Definition 9 (Block).
A Block b is either the genesis block Gen, or a tuple of type:where: and are the lists of inputs and outputs of the transactions.
is the list of t transaction kernels.
is the block kernel offset which covers all the transactions of the block.
We can say a block is balanced if each aggregated transaction is balanced.
Definition 10 (Balanced Block).
Let b be a block of the form with the list of transaction kernels and where the j-th item in is of the form . We say the block b is balanced if the following holds: We assume the genesis block is valid. We define the notion of block validity as follows:
Property 2 (Valid Block). A block b is valid () if b is the genesis block or it satisfies:
- i.
The block is balanced.
- ii.
For every transaction kernel, the range proofs of all the outputs are valid and the kernel signature σ is valid for the transaction excess.
Blocks can be constructed by aggregating transactions as follows:
Definition 11 (Block Aggregation).
Given a valid transaction and a valid block b as follows:a new block can be constructed as:where is the list concatenation operator and + is the scalar sum. Block aggregation preserves the validity of blocks; that is, block validity is invariant w.r.t. block aggregation.
Lemma 2 (Invariant: Block Validity). Given a valid transaction and a valid block b as in Definition 11. Let be the result of aggregating into b. Then, is valid.
Proof. Let be the transaction with . Let b be the block , with , the list of transaction kernels.
Applying Definition 11, we have that the resulting
is of the form:
According to Definition 10, we need to prove the following equality holds for the block
:
Each term can be written as follows:
Rearranging the equality and using algebraic properties on elliptic curves, we have:
Now, we apply the hypothesis concerning the validity of
and
b. In particular, applying Definition 5 for
and Definition 10 for
b, we have that the following equalities are true:
and
That is exactly what we wanted to prove. □
Notice that the proof above is analogous to the proof of CoinJoin Validity (Lemma 1).
Definition 12 (Chain).
A chain is a non-empty list of blocks: For a chain c and a valid block b, we can define a predicate representing the fact that is correct to add b to c. This relation must verify, for example, that all the inputs in b are present as outputs in c, in other words, they are UTXOs.
3.5. Validating a Chain
The model formalizes a notion of a valid state that captures several well-formedness conditions. In particular, every block in the blockchain must be valid. A predicate validChain can be defined for a chain by checking that:
is a valid genesis block
For every , .
The axiomatic semantics of the system are modeled by defining a set of transactions, and providing their semantics as state transformers. The behavior of transactions is specified by a precondition
and by a postcondition
:
This approach is valid when considering local (nodes) or global (blockchain) states (of type ) and transactions (of type ). Different sets of transactions, pre and postcondition are defined to cover local or global state transformations. At a general level, is .
3.6. Executions
There can be attempts to execute a transaction on a state that does not verify the precondition of that transaction. In the presence of such situation the system answers with a corresponding error code (of type
). Executing a transaction
t over a valid state
s (
) (when dealing with global states,
is
) produces a new state
and a corresponding answer
r (denoted
s
s′), where the relation between the former state and the new one is given by the postcondition relation
.
![Sensors 21 05951 i002]()
Whenever a transaction occurs for which the precondition holds, the valid state may change in such a way that the transaction postcondition is established. The notation
s
s′ may be read as
the execution of the transaction t in a valid state s results in a new state . However, if the precondition is not satisfied, then the valid state
s remains unchanged and the system answer is the error message determined by a relation
. (Given a state
s, a transaction
t and an error code
,
(
s,
t,
ec) holds iff
is an acceptable response when the execution of
t is requested on state
s). Formally, the possible answers of the system are defined by the type:
where
is the answer resulting from a successful execution of a transaction.
One-step execution with error management preserves valid states.
Lemma 3 (Validity is invariant).
∀ (s s′ : State)(t : Transaction)(r : Response),
valid_transaction(
t) →
s
s′ →
valid_state(
s′)
The proof follows by case analysis on
s
s′. When
does not hold,
. From this equality and
then
. Otherwise,
must hold and we proceed by case analysis on
t, considering that
t is a valid transaction and
s is a valid state.
System state invariants, such as state validity, are useful for analyzing other relevant properties of the model. In particular, the properties in this work are obtained from valid states of the system.
4. Verification of Mimblewimble
We now detail some relevant properties that can be verified in our model. In addition to some of the properties mentioned in previous sections, we include in our research other properties such as those formulated in [
20], and various security properties considered in [
29,
37,
38].
4.1. Protocol Properties
The property of no coin inflation or zero-sum guarantees that no new funds are produced from thin air in a valid transaction. The property can be stated as follows.
Lemma 4 (No Coin Inflation). Given a valid transaction with transaction kernel , then the transaction excess only contains the blinding factor and the kernel offset.
Proof. We know the transaction
t is valid, in particular, the transaction is balanced. Applying Definition 5, we know that:
Using Definition 3, we start to unfold the terms in the equality:
Applying algebraic properties on elliptic curves, we have:
This means that all the inputs and outputs add up to zero. In other words, they are summed to the commitment to the kernel offset plus the commitment to the excess blinding factor. □
Thus, we have proved that no money is created from thin air and the only ones who knew the blinding factors were the transacting parties when they created the transaction. This means the new outputs will be spendable only by them.
An important feature of MW is the cut-through process. The purpose of this process is to erase redundant outputs that are used as inputs within the same block. Let C be some coins that appear as an output in the block b. If the same coins appear as an input within the block, then C can be removed from the list of inputs and outputs after applying the cut-through process. In this way, the only remaining data are the block headers, transaction kernels and UTXOs. After applying cut-through to a valid block b it is important to ensure that the resulting block is still valid. We can say that the validity of a block should be invariant with respect to the cut-through process.
Lemma 5 (Invariant: Cut-through Block Validity). Let b be a block of the form with i and o the list of inputs and outputs, the list of transaction kernels and the block kernel offset. Let be the resulting block after applying the cut-through process to b where:
.
Hence, if b is a valid block, then is valid too.
Proof. Let b be the block , with the list of transaction kernels, where the j-th item in is of the form .
Let r be where we assume because otherwise the lemma holds trivially as .
Let be the block , with , the list of transaction kernels, and .
We want to prove that
is valid. In particular, that
is balanced. According to Definition 10, we need to prove:
By hypothesis, we know that
b is a valid block. Applying Property 2, we know that
b is balanced. According to Definition 10, the following equality holds for block
b:
Applying the definition of
r, we can rewrite the above equality as follows:
Rearranging the equality, we have:
Now, we can observe that we are substracting the sum of all the elements belonging to the same set r. Thus, the term is equal to zero.
Then, if we remove the term we have:
By hypothesis, we know that
and
; therefore we can rewrite the above equality as:
That is exactly what we wanted to prove. □
4.2. Privacy and Security Properties
In blockchain systems the notion of privacy is crucial: sensitive data should not be revealed over the network. In particular, it is desirable to ensure properties such as confidentiality, anonymity and unlinkability of transactions. Confidentiality refers to the property of preventing other participants from knowing certain information about the transaction, such as the amounts and addresses of the owners. Anonymity refers to the property of hiding the real identity from the one who is transacting, while unlinkability refers to the inability of linking different transactions of the same user within the blockchain.
In the case of MW no addresses or public keys are used; there are only encrypted inputs and outputs. Privacy concerns rely on confidential transactions, cut-through and CoinJoin. CoinJoin combines inputs and outputs from different transactions into a single unified transaction. It is important to ensure that the resulting transaction satisfies the validity defined in the model.
The security problem of double spending refers to spending a coin more than once. All the nodes keep track of the UTXO set, so before confirming a block to the chain, the node checks that the inputs come from it. If we refer to our model, that validation is performed in the predicate
validate mentioned in
Section 3.4.
4.3. Security Properties of Pedersen Commitments
In MW transactions, input and output amounts are hidden in Pedersen commitments. In
Section 2.3 we have introduced the definition of a commitment scheme (Definition 1).
A commitment scheme is expected to satisfy the following two security properties:
Hiding: the receiver, who received the commitment, does not learn anything about the original value.
Binding: after the commit stage, there is at most one value that the sender can successfully open.
In the cryptocurrencies world, these two properties should be understood this way:
Hiding: a commitment scheme is used to keep the transactions secure. The sender commits to an amount of coins and this should remain private for the rest of the network over time.
Binding: senders cannot change their commitments to a different transaction amount. If that were possible, it would mean that an adversary could spend coins which have already been committed to an UTXO, what would allow to create coins out of thin air.
There are two possible specifications for these properties. Computational hiding or binding is when for all polynomial time adversaries, they can break the security property with negligible probability. This asymptotic security is parameterized by a security parameter and adversaries run in polynomial time in and their other inputs. On the other hand, we talk about perfectly hiding or binding, when even with infinite computing power it would be not possible to break the security property.
Notice that a commitment scheme cannot be perfectly hiding and binding at the same time:
If the scheme is perfectly hiding, there must exist several inputs committing to the same value. Otherwise, an adversary with infinite computing power attempting to find out which input committed to a certain output, could try all possible inputs finding out the corresponding output. This shows that this scheme cannot be perfectly binding.
If the scheme is perfectly binding, it means that there is at most one input that committed to an output. Imagine an adversary with infinite computing power attempting to find out which input committed to a target output. It would be possible to try all inputs and find which one verifies the commitment. Thus, this scheme cannot be perfectly hiding.
So, for cryptocurrencies systems is better to provide stronger security in order to guarantee the hiding property. In other words, we prefer a commitment scheme with computational binding and perfectly hiding. We can understand this by first assuming adversaries break the binding property. It means that they could create money from thin air from a certain point in time but this would not affect the blockchain history. On the other hand, if the adversary breaks the hiding property, history could be inspected and all the transactions revealed. That breaks one of the main principles of a privacy-oriented cryptocurrency.
4.3.1. Pedersen Commitments Are Computational Binding
This property relies on the discrete logarithm assumption. In provable security, security is proved to hold against any probabilistic time adversary by showing an efficient way to break the cryptography protocol implies a way to break the underlying mathematical problem which is supposed to be hard (security reduction). The adversary is modeled as a procedure.
Definition 13 (Computational Binding Commitment).
Let be a Pedersen commitment scheme as in Definition 2. Let be a polynomial probabilistic time adversary against the binding property running in the context of the game as in Figure 1. We say that the Pedersen commitment scheme ζ is computational binding if the success probability of winning game is negligible. In game , firstly the scheme is set up by choosing two generator points, G and H, over the elliptic curve of prime order n. All these parameters are public. Secondly, the adversary performs the attack attempting to find out two different transactional values and that commit to the same commitment. Once the adversary finishes the attack, two pair of different opening values are returned. The adversary succeeds if both pairs commit to the same value and .
As we mentioned before, the computational binding property is based on a security reduction. In terms of Pedersen commitment, it means that if the adversary could perform the attack in the context of game and could win with non-negligible probability, an adversary attacking a game against the discrete logarithm problem on the group could use to win the game with non-negligible probability.
Recall that MW uses Pedersen commitment with elliptic curves (Definition 2). The discrete logarithm problem on this context means: given a point y over the elliptic curve with generator G, it is hard to find x such that .
The following lemma captures the semantics of that security reduction.
Lemma 6 (Computational Binding). Let be a Pedersen commitment scheme as in Definition 2. Let be an adversary against the computational binding commitment (Definition 13) in the commitment scheme ζ.
Let us assume that succeeds in finding two distinct pair of opening values that commit to the same commitment with ϵ probability. Therefore, there exists an inversor which can find out the discrete logarithm to the base G of a randomly chosen element y on the elliptic curve with probability using the adversary .
Hence, if is negligible then ϵ is negligible too.
In these cases, the contraposition is proved: if is non-negligible, then is non-negligible too. The goal of the proof is to show how to transform the efficient adversary that is able to break the computational binding commitment into an algorithm that efficiently solves the discrete logarithm assumption. The inversor will provide a simulation context in which the adversary will perform its attack. The attack of the inversor will be successful if is successful and the simulation does not fail.
According to game
, when the adversay
succeeds we have two identical commitments
and
such that (Definition 2):
So we can compute:
which means that we have computed the discrete logarithm of
H with respect to
G.
Figure 2 shows the game
, which captures the semantic of the reduction. The failure event captures when the adversary
fails and therefore, the adversary
fails too.
The probability of the success of is equal to the probability of the success of .
4.3.2. Pedersen Commitments Are Perfectly Hiding
Basically, it is because, given a commitment , there are many combinations of that satisfies . Despite the adversary have infinite computing power and could attempt all possible values, there would be no way to know which opening values were the original ones. Furthermore, r is a random value of the finite field so is a random element of .
Definition 14 (Perfectly Hiding Commitment).
Let be a Pedersen commitment scheme as in Definition 2. Let be a computationally unbounded adversary against the hiding property running in the context of the game as in Figure 3. We say that the Pedersen commitment scheme ζ is perfectly binding if the success probability of winning game holds: In the game described in
Figure 3, first the game is set up and then the adversary chooses two distinct transactional values
and
. Then, one of these values is randomly chosen as
, as well as with the blinding factor
r. The commitment of
is computed and the adversary
performs the attack attempting to find out which one of the values was committed.
4.3.3. Switch Commitments
As already mentioned, if an attacker succeeds in breaking the computational binding property of a commitment then money can be created from thin air. Switch commitments [
39] were introduced to enable the transition from
computational bindingness to
statistical bindingness, specially to the commitments stored in the blockchain. The notion of statistical security implies that a computationally unbounded adversary cannot violate the property except with negligible probability.
If in a certain moment we believe that the bindingness of the commitment scheme gets broken, we could make a soft fork on the chain and switch existing commitments to this new validation scheme which is backwards compatible.
Below, we show the changes that are needed for our model to also encompass Switch commitments. In Pedersen commitment definition (Definition 2) we add a third point generator
J of the elliptic curve
whose discrete logarithm relative to
G and
H is unknown. We define the new commitment algorithm as follows:
where
r is the blinding factor randomly chosen in the finite field
and
J is the third point generator.
Note that
r is still randomly distributed and the hash value of
ElGamal commitment is computed which is the combination of ElGamal encryption [
40] and a commitment scheme.
4.4. Zero-Knowledge Proof
The goal is to prove that a statement is true without revealing any information beyond the verification of the statement. In MW we need to ensure that in every transaction the amount is positive so that users cannot create coins. Here, the hard part is to prove that without revealing the amount. In our model, the output amounts are hidden in the form of a Pedersen commitment, and the transaction contains a list of range proofs of the outputs to prove that the amount is positive. MW uses Bulletproofs to achieve this goal. In our model, this verification is performed as the first step of the validation of the transaction.
4.5. Unlinkability and Untraceability
As we specified in our model, each node has a pool of unconfirmed transactions in the mempool. This transactions are waiting for the miners in order to be included in a block. We can distinguish two security properties of the transactions. Untraceability refers to the transactions in the mempool and unlinkability to the transactions in the block. In our model, this two notions are formalized as follows.
Property 3 (Transaction Unlinkability). Given a valid block b, it is computationally infeasible to know which input cancels which output.
The following lemma captures the semantics of this property in MW. Moreover, the operations cut-through and CoinJoin, which were described above, also contribute to this property.
Lemma 7 (Transaction Unlinkability). For any valid block b and for any polynomial probabilistic time adversary , the probability of in finding a balanced transaction within b is negligible.
Proof. Let be a valid block with the list of transaction kernels. The j-th item in is of the form .
The goal of the adversary
is to find a tuple of the form
where the list of inputs
is a subset of
i and the list of outputs
is a subset of
o, satisfying Definition 5 of a balanced transaction. It means that, the following equality must be true for the tuple:
where
is the transaction excess and
the transaction kernel offset.
If we refer to the construction process in Definition 11, the transaction kernel offsets were added to generate a single aggregate offset to cover all transactions in the block. It means that we do not store the individual kernel offset of the transaction in b once the transaction is aggregated to the block.
The challenge is trying to solve the adversary could be seen as the subset sum problem (NP-complete) but, in this case, is unrecoverable. So, although many transactions have few inputs and outputs, it is computationally infeasible, without knowing that value, to find the tuple. □
We can define:
Definition 15 (Transaction Unlinkable). We say block b is transaction-unlinkable, if the probability of any polynomial probabilistic time adversary in finding a balanced transaction within b is negligible.
Then, due to Lemma 7 we conclude that in MW all blocks are transaction-unlinkeable.
Property 4 (Transaction Untraceability). For every transaction in the mempool, it is not possible to relate the transaction to the IP address of the node which originated it.
Regarding this property, we should refer mainly, to the broadcast of the transactions. Once the transactions are created, they are broadcasted to the network and they are included in the mempool. Each node could track the IP address from the node which received the transaction. At that point nodes could record the transactions, allowing them to build a transaction graph.
We define that the broadcast of a transaction can be performed with or without confusion. Without confusion means that, once the transactions are created, they are broadcasted immediately to all the networks. However, if someone controls enough nodes on the network and discovers how the transaction moves, he could find out the IP address node from which the transaction comes from.
On the other hand, we define the broadcast with confusion as a way to obscure the IP address node.
Definition 16 (Broadcast with confusion). Let us say node A sends a transaction to node B. We say B receives the transaction with confusion if given the IP address of node A, the node B does not know if the transaction was originated by the node A or not.
In other words, it can be said that if some malicious nodes, working together, construct a graph of the pairs , the IP address node will not convey information about what node originated the transaction. Therefore, in our model, we require Property 16 to hold before the broadcast takes place. In order to achieve this, we can establish that the node broadcasting the transaction should be far enough from the one which originated it. Moreover, CoinJoin could be performed before the broadcast.
Dandelion, proposed by Bojja et al. [
41], is a protocol for transaction broadcasting intended to resist that deanonymization attack. Dandelion is not part of the MW protocol, however this kind of protocols should be implemented by each node to lower the risk of creating the transaction graph. In Dandelion, broadcasting is performed in two phases: the “steam” phase and the “fluff” phase. In the “steam” phase the transaction is broadcasted randomly to one node, which then randomly sends it to another, and so on. This process finishes when the “fluff” phase is reached, and the transaction is broadcasted to the network using a gossip protocol. The following routines capture the semantic of the phases:
Each node, besides having the local state, should implement these two routines. Once the transaction is created and is ready to be included in the mempool, its broadcasting start in the “steam” phase. When it reaches the “fluff” phase, it is broadcasted to the network and added in the mempool.
Dandelion relies on the following three rules: all nodes obey the protocol, each node generates exactly one transaction, and all nodes on the network run Dandelion. The problem is that an adversary can violate them. For that reason,
Grin implements a more advanced protocol called Dandelion++ [
42] which intends to prevent that [
43]. However, it is believed that Dandelion++ is not good enough to guarantee the privacy of a virtual coin [
44]. For instance, the flashlight attack [
45] is an open problem still under investigation [
46]. The scenario here is when an ‘activist’ want to accept donations but he cannot reveal his identity. At some point, he will deposit those payments to an exchange and his identity would be compromised. The adversary injects ‘tainted coins’ and could build a ‘taint tree’ looking through all deposits to the exchange. This way, he could link those deposits to the ‘activist’.
The combined use of the MW protocol with a Zerocash-style commitment-nullifier schema has been put forward in Lim [
47] as a countermeasure to the above attack. In the case of Zcash, every shielded transaction has a large anonymity set, namely, a set of transactions form which it is indistinguishable from. In the case of Spectrecoin (now Alias) [
48], the main idea is the use, only once, of public addresses (XSPEC) to receive the payments combined with an anonymous staking protocol.
5. Model-Driven Verification
MW is built on top of a consensus protocol. In that direction, we have developed a Z specification of one such protocol, part of which is included in what follows. Z specifications in turn can be easily translated into the {
log} language [
49], which can be used both as a (prototyping) programming language and a satisfiability solver for an expressive fragment of set theory and set relation algebra. We present an excerpt of the {
log} prototype after its Z specification. This {
log} prototype can be used as an executable model where simulations can be run. This allows us to analyze the behavior of the protocol without having to implement it in a low level programming language.
We also plan to use {
log} to prove some of the basic properties mentioned above, such as the invariance of
. However, for complex properties or for properties not expressible in the set theories supported by {
log} we plan to develop a complete and uniform formulation of several security properties of the protocol using the
Coq proof assistant [
21]. The
Coq environment supports advanced logical and computational notations, proof search and automation, and modular development of theories and code. It also provides program extraction towards languages like
Ocaml and
Haskell for execution of (certified) algorithms [
50]. Additionally,
Coq has an important set of libraries; for example [
51] contains a formalization of elliptic curves theory, which allows the verification of elliptic curve cryptographic algorithms.
The fact of first having a {
log} prototype over which some verification activities can be carried out without much effort helps with simplifying the process of writing a detailed
Coq specification. This is in accordance with proposals such as
QuickChick whose goal is to decrease the number of failed proof attempts in
Coq by generating counterexamples before a proof is attempted [
52].
By applying the program extraction mechanism provided by
Coq we would be able to derive a certified
Haskell prototype of the protocol. This prototype can be used as a testing oracle and also to conduct further verification activities on correct-by-construction implementations of the protocol. In particular, both the {
log} and
Coq approaches can be used as forms of model-based testing. That is, we can use either specification to automatically generate test cases with which protocol implementations can be tested [
52,
53].
5.1. Excerpt of a Z Model of a Consensus Protocol
The following is part of a Z model of a consensus protocol based on the model developed by Pîrlea and Sergey [
20]. For readers unfamiliar with the Z notation we have included some background in
Appendix B.
The time stamps used in the protocol are modeled as natural numbers. Then we have the type of addresses (
), the type of hashes (
), the type of proofs objects (
) and the type of transactions (
). Differently from Pîrlea and Sergey’s model (PS) footnote:From now on we will refer to Pîrlea and Sergey’s model s model (PS) we model addresses as a given type instead as natural numbers. In PS the only condition required for these types is that they come equipped with equality, which is the case in Z.
The block data structure is a record with three fields: , (usually) points to the parent block; , stores the sequence of transactions stored in the block; and is a proof object required to validate the block.
Next, we define the following parameters of the model: , a function computing the hash of a block; , a function computing the hash of a transaction; , a function computing a proof object of a node; , a relation used to validate proof objects; , a relation used to validate transactions; and , a relation used to modify a set of pending transactions stored in a node. is constrained to triplets where the block whose proof is being considered is not one of the blocks of the chain being considered.
Another parameter of our model is the genesis block, called , which should be provided by the client of the model. Clearly, is a block enjoining two particular properties: it has no parent and it contains no transactions.
The local state space of a participating network node is given by four state variables: , representing the address of the node; , are the addresses of the peers this node is aware of; , is a block forest which records the minted and received blocks; and , is a set of received transactions, which will eventually be included in minted blocks.
As nodes can send messages, we define their type. is used when, actually, the node does not send any message (think of it as the null statement in programming languages, that is, ). Note that some messages contain some data, for example, which communicates a set of peers by transmitting their addresses.
Packets are used to build so-called packet soups which are used later to define the system configuration (see schema ). A packet is a triple where the first component is the message sender, the second is the destination’s address and the third is the message content.
The model has twelve state transitions divided into two groups: local and global. Local transitions are those executed by network nodes, while global transitions promote local transitions to the network level. In turn, the local transitions are grouped into receiving and internal transitions. Receiving transitions model the nodes receiving messages from other nodes and, possibly, sending out new messages; internal transitions model the execution of instructions run by each node when some local condition is met.
With the model elements defined so far, we can give the specification of the local transitions. We start with which models a rather trivial operation of the protocol when actually the state of the node does not change because the has been received.
specifies the transition where the node receives a message making it to add the sender’s address as a new peer. In this transition we see that a node can output a set of packets (which in this particular case is a singleton set) as a side effect of receiving a message. In this case the packet says that node is sending the packet addressed to the node that just sent a packet to . In turn the payload of the packet is an message which informs the destination the transactions and blocks stored by .
![Sensors 21 05951 i009]()
The next transition is . As can be seen, it sends out a set of packets which can potentially have many elements. The node checks whether or not the packet’s destination address coincides with its own address. In that case, the node adds the received addresses to its local state and sends out a set of packets that are either of the form or . The former are packets generated from the received addresses and sent to the new peers the node now knows, while the latter are messages telling its already known peers that it has learned of new peers.
specifies the reception of a new transaction by a node. In this case the node adds the transaction to its local state and sends out an to its peers telling them that is now possessing the received transaction.
The next transition is which specifies a node receiving a block instead of a transaction. However, in order to specify we first need to introduce several elements in the form of parameters to the model. We start by introducing as an order relation on the set of block chains. Note that the axioms imply that is total, transitive and irreflexive. The fourth axiom states that extensions of a chain are “heavier” than the chain itself.
The function returns the maximum chain of a set of chains according to the order.
Function is one of the building blocks necessary to compute the ledger of a block forest. Block forests are represented as partial functions from hashes to blocks (formally ). Then, takes as inputs a block forest and a block returning a block chain. We will use to “iterate” over all the blocks of a given block forest.
Now, we define the ledger of a block forest as the longest block chain returned by for each block in the forest.
Finally, we can give the specification of .
As can be seen, adds the received block to the block forest without checking its validity. This is because the node might not have received the preceding blocks which determine the validity of the received block.
specifies the behavior of the node when it receives an message. Such a message is used to inform nodes of the transactions and blocks stored by a given node. Then, when receives an message it asks the system the transactions and the block it does not yet know, by means of a message.
The last receiving local transition is . This operation is divided into three cases: the node receiving a block (); the node receiving a transaction (); and the node receiving data it has not requested ().
The system configuration is represented by two state variables:
, which establishes a mapping between network addresses and the corresponding node (local) states (in PS this variable is referred to as the
global state); and
P, a set of packets (which represent the messages exchanged by nodes).
![Sensors 21 05951 i019]()
5.2. Excerpt of the {log} Prototype Generated from the Z Specification
In this section, we show part of the {
log} code corresponding to the Z model presented above. {
log} code can be seen as both a formula and a program [
49]. Thus, in this case we use the code as a prototype or executable specification of the Z model. The intention is twofold: to show that passing from a Z specification to a {
log} program is rather easy, and to show how a {
log} program can be used as a prototype or executable specification. The first point is achieved mainly because {
log} provides the usual Boolean connectives and most of the set and relational operators available in Z. Hence, it is quite natural to encode a Z specification as a {
log} program.
Given that {log} is based on Prolog its programs resemble Prolog programs. The {log} encoding of is the following:
rcvAddr(LocState,P,Ps,LocState_) :-
LocState = {[as,As], [this,This] / Rest} &
P = [_,This, addrMsg(Asm)] & un(As,Asm,As_) &
diff(Asm,As,D) &
Ps1 = ris(A in D,[],true,[This,A,connectMsg]) &
Ps2 = ris(A in As,[],true,[This,A,addrMsg(As_)]) &
un(Ps1,Ps2,Ps) &
LocState_ = {[as,As_], [this,This] / Rest}.
As can be seen, rcvAddr is a clause receiving the before state (LocState), the input variable (P), the output variable (Ps) and the after state (LocState_). As in Prolog, {log} programs are based on unification with the addition of set unification. In this sense, a statement such as LocState = {[as,As], [this,This] / Rest} (set) unifies the parameter received with a set term singling out the state variables needed in this case (As and This) and the rest of the variables (Rest). The same is done with packet P where _ means any value as first component and addrMsg(Asm) gets the set of addresses received in the packet without explicitly introducing an existential quantifier.
The set comprehensions used in the Z specification are implemented with {
log}’s so-called Restricted Intensional Sets (RIS) [
54]. A RIS is interpreted as a set comprehension where the control variable ranges over a finite set (
D and
As).
We can execute rcvAddr by calling it as part of a {log} query, as follows:
S = {[as,{}], [this,This] / R} &
rcvAddr(S,[_,This,addrMsg({a1,a2})],P1,S1) &
rcvAddr(S1,[_,This,addrMsg({a1,a3})],P2,S2).
in which case {log} returns:
P1 = ris(A in {a1,a2/_N2},[],true,[This,A,connectMsg],true),
S1 = {[as,{a1,a2}], [this,This] / R},
P2 = {[This,a3,connectMsg],[This,a1,addrMsg({a2,a1,a3})],
[This,a2,addrMsg({a2,a1,a3})] /
ris(A in _N1,[],true,[This,A,connectMsg],true)},
S2 = {[as,{a2,a1,a3}], [this,This] / R}
Constraint: subset(_N2,{a1,a2}), subset(_N1,{a1,a3}),
a1 nin _N1, a2 nin _N1
That is, {log} binds values for all the free variables in a way that the formula is satisfied (if it is satisfiable at all). In this way we can trace the execution of the protocol w.r.t. states and outputs by starting from a given state (e.g., S) and input values (e.g., [_,This,addrMsg({a1,a2})]), and chaining states throughout the execution of the state transitions included in the simulation (e.g., S1 and S2).
7. Final Remarks
MW constitutes an important step forward in the protection of anonymity and privacy in the domain of cryptocurrencies. Since it facilitates traceability and the validation process, both Grin and Beam adopted the MW protocol for their implementations.
We have highlighted elements that constitute essential steps towards the development of an exhaustive formalization of the MW cryptocurrency protocol, the analysis of its properties and the verification of its implementations. The proposed idealized model is key in the described verification process. First of all, we have defined the main components of our idealized model: transactions, blocks and chain. Then, we have provided validity conditions to guarantee the correctness of the blockchain. We have stated precise conditions for a valid transaction and a valid block. Furthermore, we have defined and proved that the validity of a block is invariant with respect to the cut-through process and CoinJoin.
The main difficulty we have faced during that process was the lack of “official” documentation, so we have made an exhaustive literature review in order to analyze and conceptualize the main components of MW. Furthermore, even when Grin and Beam have documentation available on-line, the main challenge was to build a model which abstracts away the specifics of their implementations.
We have also identified and precisely stated the conditions for our model to ensure the verification of relevant security properties of MW which is a important contribution of this work. Firstly, we have proved that no new funds are produced from thin air in a valid transaction. Secondly, since MW transactions are in the form of Pedersen commitments, we have analyzed the strength of the scheme regarding the main security properties a cryptocurrency protocol must have. In particular, we have defined the computational binding commitment property and we have shown a security reduction using a game-based cryptographic proof approach. Then, we have defined and analyzed two important security properties: unlinkability and untraceability. In particular, we have proved that the probability in finding a balanced transaction within a valid block is negligible. Moreover, we have defined what broadcast with confusion is in order to obscure the IP address from which the transaction comes from.
Since MW is built on top of a consensus protocol, we have developed a Z specification of a consensus protocol and presented an excerpt of the {log} prototype after its Z specification. This {log} prototype can be used as an executable specification where functional scenarios can be exercised. This allows us to analyze the behavior of the protocol without having to implement it in a low level programming language.
Finally, we analyze and compare the Grin and Beam implementations in their current state of development, considering our model and its properties as a reference base. We have presented detailed connections between our model and their implementations regarding the MW structure and its security properties. In particular, we have extended our steam routine abstraction to capture Beam’s behavior combining dummy transactions and incubation period in order to improve privacy.
The main challenge we have faced to address the comparison between our model and the implementations was reading the source code of Grin and Beam to identify the components of our model and analyze how they implement them.
With respect to our previous paper [
31], we have extended the definition of the MW protocol and the idealized model, incorporating in particular the discussion on the security properties of Pedersen commitments. Furthermore, we have studied the strength of the commitment scheme introduced regarding the main security properties a cryptocurrency protocol must have.
As future work, we plan to extend the formalization of our model to include new definitions and security properties. In particular, we will extend the definition of valid transaction to enable zero-knowledge proofs in order to prove that the transaction amount is in certain range without revealing the value.
In addition, since cryptographic proofs are becoming increasingly error-prone and difficult to check, we plan to carry out a specification of our MW model using an interactive prover, in order to provide an automated verification of our model. Security goals and hardness assumptions shall be modeled in order to verify the security properties we have stated. Firstly, we plan to evaluate tools for the verification of cryptographic protocols and implementations, such as
EasyCrypt [
28],
ProVerif [
60],
CryptoVerif [
61] and
Tamarin [
62]. In particular, we are especially interested in using
EasyCrypt, an interactive framework for verifying the security of cryptographic constructions in the computational model. Secondly, we will specify our model using the tool, according to all definitions we have stated in this work. Then, all the properties we have presented and proved should be verified using the interactive prover. Furthermore, we shall specify and verify the security properties. In prticular, the game-based cryptographic proof in Lemma 6 where the goal is to construct a security reduction as a sequence of games proving that any attack against the security of the system would lead to an efficient way to solve the discrete logarithm problem.
The results presented in this work constitute a relevant contribution in order to analyze the correctness of the MW protocol and its security properties over an idealized model beyond any particular implementation. Directions for future research are to verify that Grin and Beam are a correct implementation of the idealized model in order to guarantee security properties with a formal approach.